5.4 vSphere Supervisor Configuration & vSphere Kubernetes Service (VKS) Integration

5.4 vSphere Supervisor Configuration & vSphere Kubernetes Service (VKS) Integration

Executive Overview: VMware Cloud Foundation converges traditional enterprise virtualization with cloud-native application delivery through vSphere Supervisor (formerly known as Workload Management). By integrating Kubernetes directly into the ESXi hypervisor, VCF transforms a standard VI Workload Domain into an enterprise-grade Kubernetes runtime. Rather than managing disparate container silos, infrastructure administrators leverage SDDC Manager and vCenter Server to provision a highly available 3-node Supervisor Control Plane, establish multi-tenant vSphere Namespaces, integrate private container registries, and enable developers to declaratively spin up downstream Tanzu Kubernetes Grid (TKG) guest clusters using standard Kubernetes manifests.

[!NOTE] VCF 9.0 naming. The Kubernetes runtime that the Supervisor provisions is now vSphere Kubernetes Service (VKS), formerly the VMware Tanzu Kubernetes Grid (TKG) Service. Since vSphere 8.0 Update 3 it is installed as a Supervisor Service. Official 9.0 material and the exam objective wording use "Supervisor-based Services" and VKS; "TKG" and "Tanzu" persist in older documentation and in some in-product object names, so treat them as the same technology under its previous branding.

---

vSphere Supervisor Architectural Overview

vSphere Supervisor bridges the gap between infrastructure administrators and software developers by embedding a declarative Kubernetes control plane directly into vSphere.

• Hypervisor Convergence: On every participating ESXi host within an enabled cluster, the traditional hypervisor control plane integrates the Spherelet process (an optimized hypervisor equivalent of the Kubernetes kubelet). This allows the hypervisor to interpret native Kubernetes Custom Resource Definitions (CRDs) and manage container runtimes alongside traditional virtual machines.
• Dual Consumption Models:
  1. vSphere Pod Service: Allows running container workloads directly on ESXi hypervisors inside ultra-lightweight, secure micro-VMs called CRX (Container Runtime for ESXi) pods, providing hardware-level security isolation with near-bare-metal performance.
  2. Tanzu Kubernetes Grid (TKG) Service: Operates the upstream-compliant Cluster API (CAPI) provider on the Supervisor. Platform engineers and developers use standard kubectl CLI commands and declarative YAML manifests to provision, scale, and lifecycle-manage dedicated downstream Tanzu Kubernetes guest clusters (workload clusters).

┌─────────────────────────────────────────────────────────────────────────┐
│                     VSPHERE SUPERVISOR ARCHITECTURE                     │
├─────────────────────────────────────────────────────────────────────────┤
│  Developer / DevOps API Access: kubectl apply -f tkg-cluster.yaml       │
│                                  │                                      │
│                                  ▼                                      │
│  Supervisor Control Plane (3 HA VMs across ESXi Hosts with Shared VIP)  │
│  - Kubernetes API Server, etcd, Cluster API (CAPI) Controllers          │
├─────────────────────────────────────────────────────────────────────────┤
│  vCenter Server: vSphere Namespaces (Quotas, Permissions, SPBM Policies) │
├─────────────────────────────────────────────────────────────────────────┤
│  NSX Fabric: Edge Cluster, Tier-0 Gateway, Ingress/Egress LB, DFW       │
├─────────────────────────────────────────────────────────────────────────┤
│  Infrastructure: ESXi Hosts with Spherelet + vSAN / Shared Storage      │
└─────────────────────────────────────────────────────────────────────────┘

---

Environmental Prerequisites for Enabling Supervisor in VCF

Enabling the Supervisor on a VI Workload Domain cluster requires meticulous network, compute, and storage preparation.

1. Compute & Cluster Prerequisites

• vSphere HA and DRS: The underlying vSphere cluster must have both vSphere High Availability (HA) and Distributed Resource Scheduler (DRS) enabled. DRS must be configured in Fully Automated mode to permit the automatic initial placement and dynamic load balancing of Supervisor Control Plane VMs and container workloads.
• Content Library Integration: A subscribed or local vCenter Content Library must be configured and associated with the cluster, containing official VMware Tanzu Kubernetes releases (TKr OVA images).

2. Networking Architecture & NSX Edge Cluster Integration

vSphere Supervisor relies on advanced software-defined networking for pod communication, external routing, and load balancing.

• NSX Edge Cluster & Tier-0 Gateway: A healthy NSX Edge cluster must be deployed within the workload domain, hosting an active Tier-0 (or Tier-1) Gateway. The Tier-0 gateway must have established eBGP peering with upstream physical routers to advertise external container routes dynamically.
• IP Address Block Sizing & Allocation: Administrators must allocate five discrete, non-overlapping IP address ranges:
  • Control Plane Management Network: A VLAN-backed subnet providing at least 5 static IP addresses on the management network (3 for the Supervisor Control Plane VMs, 1 floating Virtual IP [VIP] for the Kubernetes API server endpoint, and 1 reserved for rolling updates).
  • Pod CIDR: A non-routable private subnet (e.g., 10.244.0.0/16) used for internal pod-to-pod networking across worker nodes.
  • Service CIDR: A non-routable private subnet (e.g., 10.96.0.0/12) used for Kubernetes internal ClusterIP services.
  • Ingress CIDR: A routable subnet pool (e.g., 192.168.100.0/24) dynamically assigned to Kubernetes Ingress controllers and Type: LoadBalancer services to expose containerized applications externally.
  • Egress (SNAT) CIDR: A routable subnet pool used by NSX to perform Source Network Address Translation (SNAT) when pods initiate outbound connections to external datacenter or internet resources.

3. Storage Policy-Based Management (SPBM)

Dedicated storage policies must be created in vCenter prior to enablement:

• A policy backing the Supervisor Control Plane VMs (typically backed by high-performance vSAN with FTT=1 or FTT=2).
• A policy backing ephemeral container disks.
• A policy backing persistent container storage through the Cloud Native Storage (CNS) Container Storage Interface (CSI) driver.

---

Control Plane VM Sizing & 3-Node High Availability Deployment

During the Supervisor enablement workflow in the vSphere Client (Workload Management > Enable), administrators select the Control Plane sizing tier based on the expected scale of namespaces, pods, and guest clusters:

Automated 3-Node HA Rollout

Upon clicking Finish, vCenter Server orchestrates the automated deployment of exactly three (3) Supervisor Control Plane VMs.

• Strict Anti-Affinity: vSphere DRS automatically creates anti-affinity rules ensuring that each of the three Control Plane VMs runs on a separate physical ESXi host within the cluster. This prevents a single hardware failure from compromising the Kubernetes control plane.
• Clustered Quorum (etcd): The three nodes form an odd-numbered etcd database cluster, guaranteeing quorum resilience against single-node failures.
• Kubernetes API Server Endpoint (VIP): NSX or the load balancer binds a floating Virtual IP (VIP) across the control plane nodes, exposing a highly available Kubernetes API endpoint at https://<supervisor-vip>:6443.

---

vSphere Namespaces & Governance Architecture

The fundamental unit of multi-tenancy on the vSphere Supervisor is the vSphere Namespace.

• Tenancy Boundary: A vSphere Namespace corresponds to a Kubernetes namespace but is managed directly within the vCenter Server inventory. It acts as an isolated resource and security envelope for a development team or project.
• Resource Quotas & Limits: Administrators define strict compute boundaries:
  • Maximum CPU capacity (in MHz or GHz) and memory capacity (in GB).
  • CPU and memory reservations, guaranteeing dedicated performance for mission-critical applications.
  • Storage capacity quotas allocated per Storage Policy, preventing runaway container volumes from consuming underlying datastores.
• Role-Based Access Control (RBAC): Permissions are federated directly through VMware Single Sign-On (SSO) and enterprise identity providers (Active Directory, OIDC). Built-in roles include:
  • Owner: Full administrative authority over the namespace, including assigning access permissions and deleting resources.
  • Edit: Authority to deploy workloads, configure secrets, create services, and provision Tanzu Kubernetes clusters.
  • View: Read-only access to inspect namespace status and workload health.

---

Tanzu Kubernetes Grid (TKG) & Declarative Cluster Provisioning

Once vSphere Namespaces are established, development teams consume infrastructure programmatically using standard Kubernetes tooling.

• Declarative Cluster Provisioning: Rather than submitting IT tickets, developers log into the Supervisor via kubectl vsphere login and submit a standard Kubernetes manifest (TanzuKubernetesCluster or Cluster v1beta1 spec) declaring the desired state of a downstream guest cluster:

  apiVersion: cluster.x-k8s.io/v1beta1
  kind: Cluster
  metadata:
    name: prod-tkg-cluster-01
    namespace: payment-services
  spec:
    topology:
      class: tkg-cluster-class
      version: v1.28.2---vmware.1-tkg.1
      controlPlane:
        replicas: 3
      workers:
        machineDeployments:
          - class: node-pool-1
            name: worker-pool
            replicas: 5
  

• Automated Lifecycle via Cluster API: The Supervisor's Cluster API controllers intercept the manifest, clone the requested number of control plane and worker VMs from the Content Library's TKr image, configure virtual network interfaces, attach storage policies, bootstrap the Kubernetes control plane, and present a fully conformant, enterprise-ready Kubernetes cluster.

---

Platform Services: Harbor Image Registry & Supervisor Services

• Embedded Harbor Registry Integration: vSphere Supervisor supports native integration with VMware Harbor, an enterprise-class container image registry. Harbor provides vulnerability scanning (via Trivy), cryptographic image signing (via Notary), role-based project multi-tenancy, and image retention policies directly within the vSphere private cloud.
• Supervisor Services: Administrators can extend the core Supervisor control plane by deploying native Kubernetes operators directly into the cluster. Supported Supervisor Services include cert-manager for automated SSL/TLS certificate lifecycle management, Contour for advanced Layer 7 ingress routing, and Velero for container backup and disaster recovery.

---

Exam Watch: Key Scenarios and Candidate Traps

[!IMPORTANT] DRS Must Be Fully Automated: A prime failure scenario tested on the VCP-VCF exam is attempting to enable Workload Management on a vSphere cluster where DRS is configured as "Manual" or "Partially Automated." The enablement wizard will explicitly block progression until DRS is set to Fully Automated. The system requires autonomous control to place and migrate Supervisor Control Plane VMs dynamically.

[!TIP] Supervisor Control Plane Node Count: The vSphere Supervisor control plane always deploys exactly three (3) virtual machines across the cluster. This is an immutable architecture designed to satisfy etcd distributed consensus quorum requirements. You cannot deploy a 1-node or 2-node Supervisor in production environments.

[!WARNING] IP Sizing Scenarios: When sizing the Management Network for the Supervisor Control Plane, ensure you allocate at least 5 static IP addresses: 3 for the control plane nodes, 1 for the floating Virtual IP (VIP), and 1 buffer address used temporarily during non-disruptive rolling upgrades of the control plane nodes.