8.3 Enabling & Configuring the vSphere Supervisor

8.3 Enabling & Configuring the vSphere Supervisor

Modern enterprise IT demands infrastructure that supports both traditional monolithic virtual machines and dynamic containerized microservices. In VMware vSphere Foundation (VVF) 9.0, the vSphere Supervisor transforms a standard vSphere cluster into a Kubernetes-native control plane. It bridges the gap between Virtual Infrastructure (VI) Administrators and developers, enabling self-service workload consumption through familiar Kubernetes declarative APIs while maintaining centralized governance in vCenter.

---

The Architectural Paradigm: What is the vSphere Supervisor?

Rather than treating Kubernetes as an external workload running in unmanaged guest virtual machines, the vSphere Supervisor embeds Kubernetes control plane primitives directly into the ESXi hypervisor layer:

• Hypervisor-Native Integration: The hypervisor runs the Spherelet—a specialized kubelet daemon executing directly within ESXi UserWorld. The Spherelet communicates with the Supervisor Kubernetes control plane, translating Kubernetes Pod specifications into native hypervisor tasks.
• Unified Resource Plane: Virtual machines and containers coexist on the exact same physical ESXi hosts, backed by identical vSAN storage pools and protected by vSphere HA and DRS.
• The vSphere VM Service: A built-in Kubernetes Custom Resource Definition (CRD) operator that allows developers to define, provision, power on, and configure standard enterprise virtual machines using declarative YAML manifests (kind: VirtualMachine) submitted via standard kubectl CLI commands.

---

Supervisor Control Plane Architecture & Quorum

When an administrator enables Workload Management on a vSphere cluster, vCenter automatically deploys and configures the Supervisor Control Plane:

The Three Supervisor Control Plane VMs

A standard Supervisor control plane uses three VMs. The etcd voting majority is two of three; it can tolerate one member loss while retaining majority. The fault-tolerance count (3 - 1) / 2 = 1 is not the quorum size. Kubernetes API instances and controller leader election have their own roles, so do not describe the whole control plane as a single active API server with two passive database copies.

Placement across independent hosts reduces a shared hardware failure risk. Inspect readiness, cluster connectivity and the platform-managed placement instead of manually editing control-plane VMs. Loss of quorum can prevent state-changing API operations even when some containers or guest workloads remain running.

Networking Architectures: NSX vs. VDS-Based Networking

While full VMware Cloud Foundation utilizes VMware NSX overlay networking, VMware vSphere Foundation (VVF) 9.0 relies on vSphere Distributed Switch (VDS) networking:

Load Balancer Choices and Version Boundaries

Select a load-balancer/network combination supported by the installed Supervisor release. The 9.0 options include Foundation Load Balancer, Avi Load Balancer and applicable NSX configurations. The older vDS + HAProxy configuration is still supported in 9.0 but deprecated; it should not be presented as the default for every new deployment. See Broadcom KB 420255.

VVF entitlement and the chosen network architecture govern what can be used. A conceptual comparison with an NSX-based VCF deployment does not mean that NSX is included in the VVF subscription.

Dual Load Balancer Responsibilities

The external load balancer performs two critical functions:

• Control Plane Virtual IP (VIP): Exposes a single, high-availability floating IP address on port 6443 representing the Kubernetes API server across the three SCPVs. Developers and administrators direct kubectl traffic to this VIP.
• Workload / Data Plane VIPs: Dynamically provisions routable frontend IP addresses from a designated CIDR pool for Kubernetes services configured with type: LoadBalancer and ingress controllers.

---

Step-by-Step Workflow: Enabling the vSphere Supervisor

Enabling the Supervisor is executed via the vCenter Server vSphere Client:

1. Pre-Activation Cluster Validation

Verify that the target cluster satisfies all prerequisites:

• vSphere DRS is enabled and configured to Fully Automated.
• vSphere HA is enabled with Admission Control active.
• Shared enterprise storage (vSAN ESA or OSA) is initialized with healthy SPBM policies.
• A vSphere Distributed Switch (vDS) connects all hosts with dedicated distributed port groups.
• The external load balancer (HAProxy or Avi) is deployed, powered on, and operational.

2. Launching Workload Management

In the vSphere Client, navigate to the main menu and select Workload Management. Click Get Started.

3. Cluster & Network Selection

• Select the vCenter Datacenter and choose the compatible compute cluster.
• Select vSphere Distributed Switch (VDS) as the networking stack.

4. Control Plane Sizing and Storage

Choose a control-plane profile from the 9.0 deployment interface and supported sizing guidance. Account for all three control-plane VMs, their storage, reservations and growth. Avoid invented namespace/pod ceilings or reducing the assigned memory to fit a small lab.

Assign supported SPBM policies for the storage roles exposed by the selected networking configuration. Supported shared storage can include vSAN or external datastores. A claim that every Supervisor control plane must use vSAN RAID-1 is incorrect. Verify capacity, accessibility and policy compliance before activation.

6. Network Configuration

• Management Network: Select the distributed port group (dpg-management), gateway, DNS, and specify a contiguous block of 5 static IP addresses (3 for the SCPVs, 1 floating VIP, and 1 for rolling maintenance).
• Workload Network: Select the distributed port group dedicated to worker workloads, define the subnet mask, default gateway, and specify the IP address range for Kubernetes nodes.
• Load Balancer Configuration: Enter the load balancer type (HAProxy), management IP address, administrative port, API credentials, server certificate CA chain, and the frontend IP range allocated for Workload VIPs.

7. Deployment Execution

Click Finish. vCenter initiates the deployment task: it provisions the three SCPVs from internal templates, applies network configurations, forms the etcd cluster, installs Spherelet VIBs on all ESXi hosts, and registers the Kubernetes API server VIP. The cluster status transitions to Running.

---

Configuring and Administering vSphere Namespaces

Once the Supervisor is active, administrators manage tenancy and resource consumption through vSphere Namespaces.

Creating a vSphere Namespace

A vSphere Namespace represents a multi-tenant boundary matching a standard Kubernetes namespace. In the vSphere Client, navigate to Workload Management -> Namespaces -> Create Namespace. Assign a DNS-compliant lowercase name (e.g., dev-team-alpha) and associate it with the Supervisor cluster.

Resource Quotas & Limits

Under the Namespace Summary -> Capacity and Usage panel, administrators define strict resource guardrails:

• CPU Limits: Enforce maximum aggregate CPU reservations and limits (measured in MHz or GHz).
• Memory Limits: Enforce maximum RAM allocation (measured in MB or GB).
• Storage Quotas: Enforce storage capacity limits per attached storage policy (e.g., 2 TB on vSAN-Gold-RAID1).

Access Permissions (RBAC)

Under Permissions, administrators map vCenter Single Sign-On (SSO) users and enterprise Active Directory groups to Supervisor roles:

• Can View: Grants read-only visibility into Namespace resources, pod logs, and status.
• Can Edit: Grants full administrative rights within the Namespace, allowing users to authenticate via kubectl vsphere login, create deployment manifests, deploy pods, spin up Tanzu Kubernetes clusters, and provision VMs via the VM Service.

Attaching Storage Policies & StorageClasses

Under Storage, click Add Storage and select approved SPBM policies (e.g., vSAN-Gold-RAID1, vSAN-Silver-RAID5). When an administrator attaches an SPBM policy to a vSphere Namespace, the Supervisor automatically creates a corresponding Kubernetes StorageClass, which is a cluster-scoped Kubernetes resource made available under the namespace's storage policy and quota controls. Developers can immediately request persistent volumes using standard Kubernetes PersistentVolumeClaim (PVC) manifests referencing that storage class.

Enabling the vSphere VM Service

To enable developers to deploy enterprise virtual machines via YAML manifests:

1. Associate Content Library: Navigate to VM Service -> Add Content Library. Select a subscribed or local Content Library containing VM images (OVAs configured with cloud-init).
2. Assign VM Service Classes: Click Add VM Class and select pre-defined sizing profiles (e.g., best-effort-xsmall, guaranteed-medium, guaranteed-large). These classes define the exact vCPU, memory, and reservation parameters developers are permitted to request.
3. Declarative Consumption: Developers can now submit standard Kubernetes manifests specifying kind: VirtualMachine directly to the Namespace API endpoint, and ESXi provisions the virtual machine automatically without opening an IT helpdesk ticket.

Review Takeaways

• A standard three-member Supervisor control plane needs two etcd votes for majority.
• Select a supported network/load-balancer combination; vDS + HAProxy remains supported but deprecated in 9.0.
• Supported shared storage can satisfy Supervisor requirements without requiring every deployment to use vSAN.
• Namespaces control permissions and resource/storage quotas; StorageClass is a Kubernetes cluster-scoped resource.