vSphere with Tanzu: Workload Domains Explained

vSphere with Tanzu (formerly TKGS — Tanzu Kubernetes Grid Service) embeds a Kubernetes control plane directly into vSphere, enabling VMs and Kubernetes workloads to share the same infrastructure managed through vCenter. The architecture has three distinct layers, and misunderstanding which layer to use for what causes most of the confusion.

Layer 1: The Supervisor Cluster

Enabling Workload Management on a vSphere cluster transforms it into a Supervisor cluster. This is Kubernetes running inside vSphere, managed by vCenter. Its purpose is not to run application workloads — it's the management plane for everything below it.

The Supervisor cluster runs:

• The Tanzu Kubernetes Grid service (provisions TKG clusters)
• VM Service (provisions VMs via Kubernetes manifests)
• vSphere Namespaces (the resource boundary for tenant teams)

Think of the Supervisor as the cloud controller of your private cloud. Application teams shouldn't touch it directly.

Layer 2: vSphere Namespaces

A vSphere Namespace is the tenant boundary. Each namespace gets:

• Storage policy assignment (which vSAN policy / datastore)
• Resource limits (CPU, memory, storage quotas)
• Network segment (NSX T1 gateway per namespace, or shared)
• Permission bindings (which SSO groups can deploy into this namespace)

# Namespace quota via vCenter API / Terraform
resource "vsphere_namespace" "team_payments" {
  name       = "team-payments"
  cluster_id = data.vsphere_compute_cluster.supervisor.id
  storage_policy {
    policy = data.vsphere_storage_policy.vsan_default.id
    limit  = 500  # GB
  }
  vm_class   = ["best-effort-small", "best-effort-medium"]
  cpu_limit  = 8000   # MHz
  memory_limit = 16384  # MB
}

Layer 3: TKG Workload Clusters

Application teams provision TanKzu Kubernetes clusters within their vSphere Namespace. Each TKG cluster is a full, conformant Kubernetes cluster — the application team has full kubectl access and cluster-admin rights.

apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: payments-dev
  namespace: team-payments
spec:
  clusterNetwork:
    pods:
      cidrBlocks: ["192.168.0.0/16"]
  topology:
    class: tanzukubernetescluster
    version: v1.28.8---vmware.1-fips.1
    controlPlane:
      replicas: 3
    workers:
      machineDeployments:
        - class: node
          name: workers
          replicas: 4
          variables:
            overrides:
              - name: vmClass
                value: best-effort-large

The cluster is provisioned as VMs on the Supervisor's compute cluster, using the storage and network configured on the vSphere Namespace. The vCenter admin sees VMs; the application team sees Kubernetes.

When to Use VM Service Instead

VM Service lets you provision VMs directly from a vSphere Namespace using Kubernetes manifests — no TKG cluster needed. It's useful for:

• Legacy applications that can't be containerised
• Windows workloads needing direct VM access
• CI/CD agents that need a fresh VM per job

The VirtualMachine CRD is a first-class Kubernetes resource in the Supervisor, so you can use Kubernetes RBAC to control who can provision VMs — and Argo CD to manage VM lifecycle via GitOps.

The Operational Win

The entire stack from vSphere Namespace creation to running TKG cluster can be automated with Terraform and Kubernetes manifests in a GitOps pipeline. Platform teams provision the vSphere Namespace; application teams deploy their TKG clusters within the quota boundaries. No tickets to the infra team for each new cluster.