Lab: Enable vSphere Supervisor on VVF Cluster with HAProxy Load Balancer

VCF 9.0Advancedadminkubernetes⏱ 120 min

Supervisor on vDS networking (VVF mode — no NSX). Requires HAProxy as load balancer.

Objectives

Deploy and configure HAProxy load balancer for Supervisor API endpoint
Enable vSphere Supervisor on a VVF cluster using vDS networking
Create and configure a Supervisor namespace with resource quotas
Authenticate to Supervisor via kubectl vsphere login
Understand Supervisor architecture — 3 control plane VMs, namespaces, storage policies

Prerequisites

Holodeck pod with VVF management domain (vCenter + 3 ESXi + vSAN). Minimum 64GB total RAM across hosts (Supervisor control plane needs ~48GB).

Prior labs: vvf-admin-01, vvf-admin-07

Required skills:

Kubernetes basics (kubectl, namespaces, YAML)
vDS networking
OVA deployment
DNS management

Lab Environment

Holodeck VVF pod with vDS. HAProxy deployed as separate VM for K8s API load balancing. Supervisor creates 3 control plane VMs automatically.

IP Addressing

Network	Purpose	VLAN
`192.168.10.0/24`	Management	10
`192.168.10.90`	HAProxy management IP	10
`192.168.20.0/24`	Workload network (Supervisor pods/VMs)	20
`192.168.20.128-192.168.20.191`	HAProxy virtual IP range (load balancer VIPs)	20

Credentials

System	Username	Password
vCenter	`administrator@vsphere.local`	Set during VCSA deployment
HAProxy	`admin`	Set during OVA deployment

Tasks

Task 1 Deploy HAProxy Load Balancer

availability

VVF uses vDS networking for Supervisor — no NSX means no built-in load balancer. HAProxy provides the L4 load balancing required for Kubernetes API endpoint and services.

Step 1

Download HAProxy OVA for vSphere from the VMware GitHub repository (haproxy.ova). This is the VMware-maintained HAProxy appliance for Supervisor on vDS.

Step 2

Deploy OVA: vCenter → Deploy OVF Template. Name='haproxy-01'. Select management cluster, vSAN datastore.

Step 3

Network configuration:

Management Network: Management port group (VLAN 10), IP=192.168.10.90
Workload Network: Workload port group (VLAN 20)
Load Balancer IP range: 192.168.20.128/26 (64 VIPs)
HAProxy Data Plane API port: 5556

The workload port group must exist on the vDS before HAProxy deployment. Create it first if not present: vDS → New Distributed Port Group → Name='Workload-PG', VLAN=20.

Step 4

Set root password and Data Plane API credentials during OVA deployment wizard.

Step 5

Power on HAProxy VM. Verify: SSH to 192.168.10.90, run 'systemctl status haproxy' — should show active.

haproxy.service - HAProxy Load Balancer Active: active (running)

Step 6

Verify Data Plane API: curl -k https://192.168.10.90:5556/v2/info

JSON response with HAProxy version and API version.

Step 7

Export HAProxy CA certificate — needed for Supervisor configuration:
cat /etc/haproxy/ca.crt
Copy the PEM-encoded certificate content.

Save this certificate — you'll paste it into the Supervisor enablement wizard in Task 2.

Validation Gate

Check: curl -k https://192.168.10.90:5556/v2/info returns valid JSON

Expected: HAProxy Data Plane API responds with version info. haproxy service is active.

Common Errors

HAProxy VM boots but no IP on management interface

Cause: Incorrect port group mapping during OVA deployment

Fix: Power off VM → Edit Settings → verify Network adapter 1 = Management port group (VLAN 10). Re-deploy if OVA network mapping was wrong.

Data Plane API returns connection refused on port 5556

Cause: API service not started or firewall blocking

Fix: SSH to HAProxy → systemctl restart dataplaneapi → verify port: ss -tlnp | grep 5556

Task 2 Enable vSphere Supervisor

manageability

Supervisor is the Kubernetes control plane in vSphere. Enabling it on a VVF cluster with vDS networking (not NSX) is a key differentiator from VCF. Exam objective 4.1.

Step 1

Verify prerequisites: vCenter → Cluster → DRS must be 'Fully Automated'. HA must be enabled. vSAN datastore must be healthy (green).

All three prerequisites are hard requirements. Supervisor enablement will fail without DRS, HA, and shared storage.

Step 2

vCenter → Menu → Workload Management → Enable Supervisor.
Select cluster → Choose 'vSphere Distributed Switch' as network stack (NOT NSX).

Step 3

Storage settings: Select vSAN storage policy for control plane VMs and persistent volumes.

Step 4

Management network: Select management port group (VLAN 10). Enter 5 static IPs for Supervisor (3 control plane + 2 for rolling upgrades). Example: 192.168.10.91-192.168.10.95.

Step 5

Workload network: Select workload port group (VLAN 20). Enter IP range for workload nodes: 192.168.20.10-192.168.20.50.

Step 6

Load balancer configuration:

Type: HAProxy
Management IP: 192.168.10.90
Data Plane API port: 5556
Username/password: (set during HAProxy OVA deploy)
Virtual IP range: 192.168.20.128/26
CA certificate: (paste the PEM cert from Task 1, Step 7)

Step 7

Review and Finish. Supervisor deployment takes 15-25 minutes. Monitor progress in Recent Tasks.

Three Supervisor control plane VMs (SupervisorControlPlaneVM-0/1/2) are created and powered on. Workload Management status shows 'Running (green)'.

Step 8

Verify: vCenter → Workload Management → Supervisors → Status should show 'Running'. Kubernetes API endpoint URL displayed.

Note the Kubernetes API URL — you'll need it for kubectl login.

Validation Gate

Check: vCenter → Workload Management → Supervisors

Expected: Supervisor status: Running (green). 3 control plane VMs visible in inventory. Kubernetes API endpoint displayed.

Common Errors

Supervisor enablement fails at 40% with 'unable to connect to load balancer'

Cause: HAProxy CA certificate incorrect or Data Plane API unreachable

Fix: Verify HAProxy API: curl -k https://192.168.10.90:5556/v2/info. Re-export CA cert. Ensure management network connectivity between vCenter and HAProxy.

Control plane VMs created but stuck in 'Configuring' state

Cause: DNS or NTP misconfiguration on management network

Fix: Verify DNS resolves Supervisor IPs. Check NTP sync on ESXi hosts (esxcli system time get). Control plane VMs require DNS and NTP.

Supervisor status shows 'Warning' with certificate errors

Cause: Certificate chain incomplete or expired

Fix: Re-export HAProxy CA cert ensuring full chain (root + intermediate). Check cert expiry: openssl x509 -in ca.crt -noout -dates

Task 3 Create Supervisor Namespace and Authenticate

security

Namespaces are the logical isolation boundary in Supervisor. Creating one and authenticating demonstrates the developer self-service model — critical for Obj 4.1 and 4.4.

Step 1

vCenter → Workload Management → Namespaces → Create Namespace.

Name: 'dev-team', Network: Workload network (VLAN 20), Storage Policy: vSAN default.

Step 2

Set resource quotas: CPU Limit=8000 MHz, Memory Limit=16384 MB, Storage Limit=100 GB.

Namespace 'dev-team' created with resource quotas displayed.

Step 3

Assign permissions: Add user (administrator@vsphere.local) with 'Edit' role to namespace.

Step 4

Install kubectl vsphere plugin on jumpbox:

Download from https://<supervisor-api-ip> → 'Download CLI Tools' link.

Step 5

Authenticate:
kubectl vsphere login --server=<supervisor-api-ip> --vsphere-username=administrator@vsphere.local --insecure-skip-tls-verify

Enter password when prompted.

Logged in successfully. Context set to 'dev-team'.

Step 6

Verify:
kubectl get namespaces
kubectl config use-context dev-team
kubectl get resourcequotas

Namespace 'dev-team' visible. Resource quotas show CPU/memory/storage limits set in Step 2.

Validation Gate

Check: kubectl get nodes --context=dev-team

Expected: Shows Supervisor control plane nodes in Ready state

Final Validation

HAProxy deployed, Supervisor enabled on VVF cluster with vDS networking, namespace created, kubectl authenticated.

✓ HAProxy Data Plane API responds on port 5556 → Valid JSON response

✓ Workload Management → Supervisors shows 'Running' (green) → 3 control plane VMs running

✓ kubectl vsphere login succeeds and namespace 'dev-team' accessible → kubectl get resourcequotas shows CPU/memory/storage limits

Cleanup / Restore

Snapshot: post-supervisor-enabled

• Take snapshot 'post-supervisor-enabled' for VM Service and VKS labs

Design Reflection (VCDX)

Panelist: Why choose vDS networking over NSX for Supervisor? What are the limitations? How does HAProxy compare to NSX ALB for load balancing? What's your namespace isolation strategy for multi-tenant environments?

Requirements

Kubernetes control plane on VVF cluster
Developer self-service via kubectl
Network isolation between namespaces
Persistent storage for stateful workloads

Constraints

No NSX — limited to vDS L2 networking, no micro-segmentation
HAProxy single point of failure unless HA pair configured
Supervisor control plane consumes ~12 vCPU, 48GB RAM
VVF licensing limits advanced Supervisor features

Assumptions

Developers have kubectl experience
DNS configured for Supervisor API endpoint
Sufficient cluster resources after Supervisor overhead

Risks

HAProxy failure = Kubernetes API unavailable
Namespace resource quotas not enforced if not set
vDS networking limits network policies to basic VLAN isolation
Control plane VM sprawl if multiple Supervisors enabled

Self-Assessment Discussion Prompts

What's the HA story for Supervisor control plane? What happens if one of the 3 VMs fails?
How would you migrate from vDS-based Supervisor to NSX-based when upgrading VVF to VCF?
What namespace resource quota strategy prevents one team from starving others?

References

vSphere with Tanzu Configuration Guide (vDS Networking)Tier 1 — Official
HAProxy for vSphere with TanzuTier 2 — VMware Press
Supervisor Namespace ConfigurationTier 1 — Official

Mark complete