10.4 Supervisor-Based Services, vSphere Kubernetes Service (VKS), & Modern App Consumption

10.4 Supervisor-Based Services, vSphere Kubernetes Service (VKS), & Modern App Consumption

Exam Focus: For the VCP-VCF (2V0-17.25) exam, candidates must understand how VMware Cloud Foundation 9.0 delivers a modern application platform. You must master the architectural role of the vSphere Supervisor, know how Supervisor Namespaces enforce multi-tenant compute, storage, and networking boundaries, understand how Supervisor Services (packaged via Carvel) deliver managed platform add-ons, comprehend declarative Tanzu Kubernetes Grid (TKG) cluster lifecycles via Cluster API (CAPI) and ClusterClass, and understand how developers consume both containerized workloads and VM Service virtual machines through VCF Automation self-service.

[!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.

---

The Modern Application Consumption Plane in VCF 9.0

In VMware Cloud Foundation 9.0, enterprise private clouds must support modern cloud-native containerized applications alongside traditional monolithic virtual machines. Rather than maintaining disparate, siloed infrastructure platforms—such as managing bare-metal Kubernetes distributions entirely separate from virtualization clusters—VCF integrates container orchestration directly into the hypervisor layer via vSphere Supervisor.

When a vSphere cluster within a VI Workload Domain is enabled for Workload Management, three specialized virtual machines running a customized, upstream-compliant Kubernetes control plane are deployed onto the ESXi hosts. This control plane transforms ESXi hypervisors into a distributed compute plane capable of interpreting standard Kubernetes declarative API objects. Through this architecture, VCF becomes a unified multi-tenant cloud operating system where platform engineers and developers interact with infrastructure using standard Kubernetes APIs (kubectl, Helm, Carvel), declarative Cloud Templates, or the Service Broker self-service catalog.

┌────────────────────────────────────────────────────────────────────────┐
│                     VCF CONSUMPTION INTERFACES                         │
│  Service Broker Catalog │ kubectl / Tanzu CLI │ IaC (YAML / Terraform) │
├────────────────────────────────────────────────────────────────────────┤
│                 vSPHERE SUPERVISOR CONTROL PLANE                       │
│   (Declarative K8s API, Tanzu Cluster API, VM Service, Carvel Engine)  │
├────────────────────────────────────────────────────────────────────────┤
│                 SUPERVISOR MULTI-TENANT NAMESPACES                     │
│ ┌───────────────────────────┐        ┌───────────────────────────────┐ │
│ │   Namespace: Fin-App-Dev  │        │   Namespace: Analytics-Prod   │ │
│ │ • TKG Workload Cluster    │        │ • Supervisor Services (MinIO) │ │
│ │ • VM Service (DB VMs)     │        │ • Tanzu Kubernetes Cluster    │ │
│ │ • Quotas & SPBM Storage   │        │ • Harbor Container Registry   │ │
│ └───────────────────────────┘        └───────────────────────────────┘ │
├────────────────────────────────────────────────────────────────────────┤
│                 SDDC INFRASTRUCTURE UNDERLAY                           │
│  vSphere 9.0 ESXi │ vSAN 9.0 ESA/OSA │ NSX 9.0 Overlays & Avi LB       │
└────────────────────────────────────────────────────────────────────────┘

---

Supervisor Namespaces: The Multi-Tenant Operational Boundary

The fundamental administrative and consumption construct within vSphere Supervisor is the Supervisor Namespace (also referred to as a vSphere Namespace). A Supervisor Namespace maps a standard Kubernetes namespace to underlying vSphere infrastructure boundaries, delivering strict multi-tenancy, resource isolation, and operational governance.

When a Cloud Administrator provisions a Supervisor Namespace for a development team or project, four foundational operational dimensions are enforced:

1. Compute Resource Quotas

Administrators configure CPU and memory limits and reservations. These limits map directly to a backing vSphere DRS Resource Pool created automatically on the cluster:

• CPU (Reservations & Limits): Specified in megahertz (MHz) or gigahertz (GHz), preventing container workloads or TKG clusters within the namespace from starving other tenants.
• Memory (Reservations & Limits): Specified in megabytes (MB) or gigabytes (GB), enforcing hard memory consumption ceilings.

2. Storage Policies & StorageClasses

Supervisor Namespaces bridge vSphere Storage Policy-Based Management (SPBM) into native Kubernetes StorageClasses:

• Administrators assign one or more SPBM policies (e.g., vSAN-ESA-RAID1-Encrypted, vSAN-OSA-Silver) to the namespace and configure storage capacity quotas (e.g., 5,000 GB).
• The Supervisor automatically registers matching Kubernetes StorageClasses. When a developer deploys a StatefulSet or requests a PersistentVolumeClaim (PVC), the underlying vSphere Cloud Native Storage (CNS) driver automatically provisions a First Class Disk (FCD) on the declared vSAN datastore, adhering precisely to the SPBM redundancy and encryption rules.

3. Software-Defined Networking & Load Balancing

Networking within Supervisor Namespaces is virtualized and automated via VMware NSX and NSX Advanced Load Balancer (Avi Load Balancer):

• NSX VPCs & Overlay Segments: Each namespace can be isolated within its own dedicated NSX Virtual Private Cloud (VPC) or routed Tier-1 segment, providing micro-segmentation and preventing cross-namespace lateral traffic.
• Ingress & Egress CIDRs: The Supervisor assigns dedicated, non-overlapping IP address pools for Kubernetes pod networking, Ingress controllers, and Load Balancer services.
• Avi Load Balancer Integration: When developers expose a service via type: LoadBalancer, Avi dynamically spins up a Service Engine virtual service, binding a routable enterprise VIP to the internal application pods without manual network engineering.

4. Identity Federation & RBAC

Access control integrates natively with enterprise identity providers (Active Directory, LDAP, Okta via VMware Workspace ONE Access or VCF Identity Broker):

• Administrators assign enterprise directory groups to standardized namespace roles: Owner (full administrative authority over namespace resources), Edit (can create, modify, and delete workloads, TKG clusters, and pods), and View (read-only visibility).

---

Supervisor Services: Extensible Cloud-Native Add-ons

Beyond orchestrating raw compute and container pods, modern application architectures require supporting data services, registries, and middleware. In VCF 9.0, Supervisor Services allow administrators to extend the Supervisor control plane by installing certified, operator-backed software packages that developers can consume declaratively.

The Carvel Packaging Standard

Supervisor Services are packaged and managed utilizing the open-source Carvel packaging framework (specifically kapp-controller and PackageRepository custom resources):

1. Package Registration: A Cloud Administrator registers an external Carvel package repository or uploads an engineered Supervisor Service bundle into vCenter Server.
2. Cluster Activation: The administrator activates the service on the vSphere Supervisor. The underlying operators and Custom Resource Definitions (CRDs) are deployed to the Supervisor control plane nodes.
3. Namespace Entitlement: The administrator entitles specific Supervisor Namespaces to consume the service. Developers within those namespaces can now deploy service instances declaratively by submitting simple YAML manifests using kubectl.

Key Enterprise Supervisor Services

---

Tanzu Kubernetes Grid (TKG) Lifecycle via Cluster API & ClusterClass

While developers can run specialized containers directly on ESXi via the Supervisor control plane, the standard pattern for running production application microservices is provisioning dedicated, upstream-compliant Tanzu Kubernetes Grid (TKG) Workload Clusters.

Declarative Cluster Lifecycle via Cluster API (CAPI)

TKG cluster lifecycles are driven entirely by upstream Cluster API (CAPI). The vSphere Supervisor acts as the CAPI Management Cluster, while the provisioned TKG clusters function as Workload Clusters. Platform teams declare cluster desired state in YAML, and CAPI controllers reconcile actual hypervisor state to match.

The ClusterClass Abstraction

In modern TKG deployments, cluster topology is governed by ClusterClass definitions:

• A ClusterClass defines the blueprint: control plane architecture, worker node pools, operating system image (VMware Photon OS or Ubuntu), Container Network Interface (CNI, such as Antrea or Calico), Cloud Storage Interface (CSI), and hypervisor integration.
• Developers provision clusters by creating a lightweight Cluster custom resource referencing the ClusterClass, declaring only variable parameters (such as node count or VM size).

Declarative TKG Workload Cluster YAML Example

apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: fin-prod-k8s-01
  namespace: fin-analytics-prod
spec:
  clusterNetwork:
    services:
      cidrBlocks: ["10.96.0.0/12"]
    pods:
      cidrBlocks: ["192.168.0.0/16"]
    serviceDomain: "cluster.local"
  topology:
    class: tkg-vsphere-default-v1.0.0
    version: v1.28.2---vmware.1-tkg.1
    controlPlane:
      replicas: 3
    workers:
      machineDeployments:
        - class: default-worker
          name: worker-pool-compute
          replicas: 5
          variables:
            overrides:
              - name: vmClass
                value: best-effort-2xlarge
              - name: storageClass
                value: vsan-esa-gold-storage-policy

Tanzu Kubernetes Releases (TKr) & Zero-Downtime Rolling Upgrades

VMware publishes pre-tested, cryptographically signed OS images and Kubernetes binaries bundled as Tanzu Kubernetes Releases (TKr).

• When a new Kubernetes version (e.g., v1.29) is released, administrators synchronize the TKr into their vSphere Content Library.
• To upgrade an active production cluster, an administrator or pipeline simply updates the spec.topology.version field in the cluster YAML manifest.
• CAPI orchestrates a rolling zero-downtime upgrade: it deploys a new control plane VM running the new version, validates cluster health, joins it to the etcd quorum, cordons and drains an old node, deletes the retired VM, and repeats the sequence host-by-host across control plane and worker node pools without application interruption.

---

vSphere VM Service: Declarative Virtual Machines next to Containers

Modern cloud-native architectures frequently require hybrid topologies where containerized microservices interact with dedicated virtual machines (such as large monolithic relational databases or legacy COTS software) that cannot easily be containerized.

The vSphere VM Service solves this by allowing developers to provision and manage traditional virtual machines declaratively using Kubernetes CRDs directly within a Supervisor Namespace using standard kubectl commands:

• VirtualMachineClass: Defines compute sizing flavors (e.g., best-effort-xlarge, guaranteed-2xlarge) mapped to vCPU and RAM allocations.
• VirtualMachineImage: Virtual machine templates synchronized from vSphere Content Libraries exposed as Kubernetes resources.
• VirtualMachine: The declarative manifest submitted by the developer. The VM Service controller reads the manifest and coordinates with vCenter Server to clone, configure, power on, and bind the virtual machine to the namespace network segment.

apiVersion: vmoperator.vmware.com/v1alpha1
kind: VirtualMachine
metadata:
  name: oracle-backend-db
  namespace: fin-analytics-prod
spec:
  className: guaranteed-4xlarge
  imageName: rhel-9-database-template
  powerState: poweredOn
  storageClass: vsan-esa-raid1-storage-policy
  networkInterfaces:
    - networkType: nsx

---

Consuming Modern Apps via VCF Automation & Service Broker

VCF Automation bridges the gap between raw Kubernetes APIs and enterprise self-service consumers:

1. Kubernetes Cloud Zones: Cloud Assembly discovers vSphere Supervisor clusters and individual Supervisor Namespaces, registering them as Kubernetes Cloud Zones. These zones can be tagged and entitled to consumer Projects.
2. Cloud Templates for Modern Apps: Cloud architects author declarative Cloud Templates that model modern application stacks containing a mix of Cloud.K8S.Namespace, Cloud.K8S.Cluster, and Cloud.vSphere.Machine (via VM Service) resources.
3. Self-Service Service Broker Catalog: Developers who lack deep kubectl expertise can browse the Service Broker catalog, select an "Enterprise TKG Cluster" or "PostgreSQL Database" catalog item, fill out a simple request form, and receive a fully configured, governed Kubernetes environment.
4. Unified Multi-Persona Consumption: Advanced DevOps teams interact directly with Supervisor Namespaces via kubectl and GitOps pipelines (ArgoCD, Flux), while business analysts consume pre-packaged environments via Service Broker—both governed by the same underlying resource quotas, approval gates, and lease policies.

---

Exam Watch: Key Scenarios and Candidate Traps

[!IMPORTANT] Supervisor Control Plane vs. TKG Workload Clusters: A fundamental architectural distinction tested on the exam: The Supervisor control plane consists of the 3 virtual machines deployed directly onto the ESXi hosts when Workload Management is enabled. It functions as the management and orchestration plane. TKG Workload Clusters are dedicated Kubernetes clusters deployed by the Supervisor for running application workloads. General application container pods should be deployed onto TKG Workload Clusters, not on the Supervisor control plane.

[!TIP] StorageClass Mapping Mechanism: In Kubernetes, how does a developer request vSAN storage on a Supervisor Namespace? You do not reference ESXi datastore names directly. The administrator assigns a vSphere SPBM Storage Policy to the Supervisor Namespace, which automatically publishes an identical StorageClass into the Kubernetes API. The developer then references that StorageClass name in their PersistentVolumeClaim (PVC).

[!WARNING] ClusterClass Immutability: When updating a Tanzu Kubernetes Grid cluster, you cannot change the underlying ClusterClass to a completely incompatible class on an active cluster. Version updates must follow validated upgrade paths published in the Tanzu Kubernetes Release (TKr) Software Bill of Materials.

[!NOTE] Real-World Exam Scenario: A platform engineering team needs to provide development teams with on-demand PostgreSQL databases and S3 object storage buckets without granting access to vCenter Server or cloud management consoles. The optimal solution is enabling vSphere Supervisor, installing the VMware Data Services Manager (DSM) and MinIO Supervisor Services, and granting developers access to their respective Supervisor Namespaces via standard kubectl CLI credentials.