Multi-Zone Proxies with Kubernetes

Overview

By default, a Kubernetes deployment routes all session traffic through the cluster where the Kasm Helm chart runs. When you define additional zones, those zones receive only the App role from the Helm chart, so you provision the proxy and agent components externally. This guide deploys the external proxy components for an additional zone, which lets you serve users across geographic regions or isolate workload types across separate pools of compute. As a result, session traffic stays within the zone instead of routing back through the primary zone, which reduces latency for distant users.

Prerequisites

Before you begin, confirm the following:

• Administrator access to the Kasm Workspaces deployment, with permission to manage deployment zones.
• A working Kasm Workspaces deployment on Kubernetes, installed with the Kasm Helm chart.
• The ability to edit your my-values.yaml Helm values and to install or upgrade the chart.
• A DNS hostname for each proxy VM, separate from the zone proxyAddress and sharing the same parent domain.
• Network connectivity from each proxy to the zone resources it serves, as described in Provision the proxy infrastructure.

To confirm which roles the Helm chart covers and which you provision externally for your session types, see Kubernetes Deployment Options.

Which components do you need?

The Connection Proxy is required if the zone supports RDP or VNC sessions. The Dedicated Proxy is optional for Docker sessions. The Dedicated Proxy routes Docker traffic locally within the zone rather than through the App role, which reduces latency when the zone is geographically distant from the primary zone.

Solution approach

This guide progresses through the following phases:

1. Provision the proxy infrastructure.
2. Define the zones in the Helm chart.
3. Install the Dedicated Proxy.
4. Install the Connection Proxy.
5. Configure the zone in the Kasm UI.

Detailed steps

Provision the proxy infrastructure

Plan the VMs, DNS hostnames, and network paths before you change the Helm values. The components you provision depend on the session types the zone supports.

The following table shows which VMs each session type requires.

Session type	Required VMs	Optional VMs
Docker only	None	Dedicated Proxy (reduces latency)
Docker + RDP/VNC	Connection Proxy	Dedicated Proxy (reduces Docker session latency)

Each proxy VM needs its own DNS hostname, separate from the zone proxyAddress and sharing the same parent domain. For example, given this zone proxyAddress:

proxyAddress: zone-b.kasm.contoso.com

The following table shows example hostnames and where you configure each one in the Kasm UI.

VM	Example hostname	Configured in Kasm UI as
Dedicated Proxy	proxy.zone-b.kasm.contoso.com	Proxy Hostname
Connection Proxy (RDP/VNC)	rdp.zone-b.kasm.contoso.com	RDP HTTPS Proxy Hostname

Provide each proxy with the network connectivity it requires:

• Dedicated Proxy: network connectivity to all Kasm Agents in the zone, and bidirectional connectivity to the zone proxyAddress.
• Connection Proxy: network connectivity to all RDP and VNC targets in the zone that users access, and bidirectional connectivity to the zone proxyAddress.

note

For best performance, deploy Kasm Agents and their zone's Dedicated Proxy on infrastructure that is close to each other and to the users they serve. This keeps session traffic within the zone rather than routing it back through the primary zone.

Define the zones in the Helm chart

Configure the kasmZones section to define multiple zones. In your my-values.yaml, add each zone with its name and proxyAddress:

publicAddr: kasm.contoso.com
kasmZones:
   - name: primary
     proxyAddress: kasm.contoso.com
   - name: zone-b
     proxyAddress: zone-b.kasm.contoso.com

Install or upgrade the Kasm Helm chart with these values. For instructions, see Install Kasm on Kubernetes or Upgrade Kasm on Kubernetes.

note

The first zone in the list is treated as the primary zone and receives the full set of proxy roles from the Helm chart. External proxies are needed only for additional zones. Traffic to the configured publicAddr in the ingress rule routes to the primary zone.

Install the Dedicated Proxy

The Dedicated Proxy is optional. Install it when you want zone-local routing for Docker session traffic.

note

Skip this step if latency through the primary zone is acceptable. Without a Dedicated Proxy, Docker session traffic routes through the App role's built-in proxy rather than a zone-local relay.

Follow the proxy installation steps (--role proxy) in the Multi-Server Installation guide. Set --api-hostname to the zone's proxyAddress from my-values.yaml, for example zone-b.kasm.contoso.com. This setting tells the Dedicated Proxy where to forward upstream authentication requests.

Install the Connection Proxy

The Connection Proxy is required when the zone supports RDP or VNC sessions.

note

Skip this step if you are proxying only Docker sessions.

Follow the connection proxy installation steps (--role guac) in the Multi-Server Installation guide. Use the following flag values, which are specific to this zone:

• --api-hostname: the zone's proxyAddress from my-values.yaml, for example zone-b.kasm.contoso.com.
• --public-hostname: the DNS hostname of this Connection Proxy VM. See Provision the proxy infrastructure.
• --server-zone: the zone name from my-values.yaml, for example zone-b.
• --registration-token: retrieve your token with the following command.

kubectl get secret --namespace {NAMESPACE} {RELEASE_NAME}-secrets -o jsonpath="{.data.service-token}" | base64 -d; echo

Configure the zone in the Kasm UI

Log in to your Kasm UI to map the zone to the proxies you provisioned. Retrieve the admin@kasm.local password with the following command.

kubectl get secret --namespace {NAMESPACE} {RELEASE_NAME}-secrets \
  -o jsonpath="{.data.admin-password}" | base64 -d; echo

In the Kasm Admin UI, go to Infrastructure > Deployment Zones, then Edit your additional zone and set the following fields:

1. Upstream Auth Address: set to the zone's proxyAddress from my-values.yaml, for example zone-b.kasm.contoso.com.
2. Proxy Hostname: set to your Dedicated Proxy hostname, for example proxy.zone-b.kasm.contoso.com.
3. RDP HTTPS Proxy Hostname (RDP and VNC sessions): set to your Connection Proxy hostname, for example rdp.zone-b.kasm.contoso.com.

Common troubleshooting steps

• Sessions fail to start in the additional zone. Confirm that the zone proxyAddress resolves in DNS and that the proxy VMs have bidirectional connectivity to it. Confirm that the Upstream Auth Address matches the zone proxyAddress in my-values.yaml.
• RDP or VNC sessions do not connect. Confirm that you installed the Connection Proxy with --role guac and that the RDP HTTPS Proxy Hostname matches the Connection Proxy DNS hostname. Confirm that the proxy reaches the RDP and VNC targets in the zone.
• The Connection Proxy fails to register. Confirm that --registration-token matches the current service-token secret and that --server-zone matches the zone name in my-values.yaml.
• Docker session latency stays high for distant users. Without a Dedicated Proxy, Docker traffic routes through the App role in the primary zone. Install the Dedicated Proxy and set the Proxy Hostname field to route traffic locally within the zone.
• External proxies appear on the primary zone. The first zone in kasmZones is the primary zone and receives the full set of proxy roles from the Helm chart. Provision external proxies only for additional zones.