1.6 vSphere with Tanzu: Supervisor, Namespaces, Zones & Lifecycle
Key Takeaways
A vSphere Zone maps to exactly one vSphere cluster; a Supervisor runs on either one zone or three zones, and a one-zone Supervisor cannot later be expanded to three zones.
Clusters in a three-zone Supervisor can be spread across sites as long as the latency between them does not exceed 100 ms, which gives Kubernetes workloads cluster-level high availability.
vSphere Namespace permissions are granted as Can view, Can edit, or Owner, and the namespace's storage policies appear to Kubernetes users as storage classes.
TKG clusters are declared with kubectl in a vSphere Namespace, specifying a Tanzu Kubernetes release, VM classes, a storage class, and node counts.
Starting in vSphere 8 Update 3, Supervisor control plane state can be included in vCenter file-based backups; vSphere Pods are backed up with the Velero Plugin for vSphere, and TKG cluster workloads with Velero.
1.6 vSphere with Tanzu: Supervisor, Namespaces, Zones & Lifecycle
Section 1.4 described the Supervisor architecture and its prerequisites. This section covers the operational objectives: configuring a Supervisor and namespaces (4.20), using vSphere Zones (1.13.2 and 4.20.3), provisioning TKG clusters (1.13.3 and 4.20.2), and updating and backing up the platform (5.13). Newer Broadcom documents call the feature vSphere Supervisor. The exam uses the vSphere with Tanzu names.
Activating Workload Management (4.20.1)
In the vSphere Client, Workload Management > Get Started launches the wizard. Its main choices are:
| Wizard Step | What You Provide |
|---|---|
| Networking stack | NSX, or vSphere Distributed Switch (VDS) networking with a load balancer (Avi Load Balancer or HAProxy) |
| Deployment type | Cluster deployment (one zone) or zonal deployment across three vSphere Zones |
| Storage | A storage policy for the control plane VMs (and for ephemeral and image storage) |
| Management network | Addresses for the three Supervisor control plane VMs |
| Workload network(s) | Networks, IP ranges, and DNS/NTP for Kubernetes workloads |
| Control plane size | Tiny, Small, Medium, or Large, sized to the expected number of pods and objects |
Prerequisites from Section 1.4 still apply: HA, DRS in Fully Automated mode (VDS designs also accept Partially Automated), shared storage with policies, and a cluster managed by a vLCM image.
vSphere Namespaces and Permissions (4.20.4)
A vSphere Namespace is the tenancy boundary on a Supervisor. It appears in vCenter's inventory much like a resource pool. When you create one, you configure:
- Permissions for SSO users or groups, using three roles:
- Can view: read-only access to the namespace's objects,
- Can edit: create and manage workloads (pods, TKG clusters, VMs) in the namespace,
- Owner: everything Can edit allows, plus managing the namespace's permissions.
- Storage policies, which Kubernetes users see as storage classes for persistent volumes.
- Capacity and usage limits for CPU, memory, and storage.
- VM classes and content libraries for the VM Service, which lets DevOps users deploy VMs through Kubernetes.
The vSphere administrator controls the guardrails, while developers self-serve inside them with kubectl.
vSphere Zones (1.13.2 and 4.20.3)
A vSphere Zone maps to exactly one vSphere cluster that you treat as an independent failure domain.
| Deployment | Zones | Availability |
|---|---|---|
| Single-cluster Supervisor | One zone, created automatically for the cluster | Host-level HA from vSphere HA only |
| Three-zone Supervisor | Three zones (three clusters) that together form one Supervisor | Cluster-level HA: workloads can survive the loss of a whole cluster |
Rules to remember:
- You create the zones in vCenter and assign one cluster to each before deploying a zonal Supervisor.
- Each cluster needs HA and DRS, plus its own independent storage and networking.
- Clusters in the zones can sit in different physical sites if latency between them does not exceed 100 ms.
- A Supervisor deployed on one zone cannot later be expanded to three zones. Choose the zonal design up front.
- In a three-zone Supervisor, a vSphere Namespace spans all three zones, and TKG clusters can spread their nodes across zones.
TKG Clusters (1.13.3 and 4.20.2)
A Tanzu Kubernetes Grid (TKG) cluster is a conformant, upstream-style Kubernetes cluster that the Supervisor provisions declaratively inside a namespace. Use one when teams need a full Kubernetes cluster of their own (their own control plane, versions, and add-ons) rather than running pods directly on the Supervisor.
Typical workflow:
- Log in:
kubectl vsphere login --server=<supervisor-address> --vsphere-username <user>. - Switch to the namespace:
kubectl config use-context <namespace>. - Apply a cluster manifest that names the Tanzu Kubernetes release (TKr) version, the VM class for control plane and worker nodes, the storage class, and the node counts.
- The Supervisor creates the node VMs from the TKr images in a content library and hands back a kubeconfig for the new cluster.
TKr images come from a content library linked to the Supervisor, typically a subscribed library (Section 7.4).
Lifecycle: Updating the Supervisor (5.13.1)
- Update vCenter first. New Supervisor Kubernetes versions arrive with vCenter updates.
- Then open Workload Management > Supervisors > Updates, select an available Kubernetes version, and apply it. The control plane VMs are replaced in a rolling fashion, and the Spherelet on the ESXi hosts is updated as needed.
- Keep the Supervisor on a supported version. Falling too far behind blocks later vCenter upgrades.
- TKG clusters are updated separately: change the TKr version in the cluster's specification, and the nodes are replaced in a rolling update.
Lifecycle: Backup and Restore (5.13.2)
| What to Protect | Tool (vSphere 8 guidance) |
|---|---|
| vCenter Server | vCenter file-based backup and restore |
| Supervisor control plane state | vCenter file-based backup, which includes Supervisor state starting in vSphere 8 Update 3; restore it from the Workload Management UI |
| vSphere Pods | Velero Plugin for vSphere, installed on the Supervisor |
| TKG cluster | vCenter file-based backup for the cluster itself, plus Velero for the cluster's workloads |
| NSX (load balancers, ingress) | NSX Manager backup and restore |
Restoring vCenter and restoring Supervisor state are separate workflows. Do not rely on vCenter snapshot rollbacks when Supervisor control plane VMs exist; use file-based backups instead.
Exam Traps
- Zones are clusters. One vSphere Zone equals one vSphere cluster. A three-zone Supervisor therefore needs three clusters, not three hosts.
- Pick zonal up front. A one-zone Supervisor cannot be expanded to three zones later.
- Permissions are per namespace. Granting a developer Administrator on vCenter to "make Kubernetes work" is the wrong answer; Can edit on the namespace is enough.
- Storage policies become storage classes. If a developer cannot see a storage class, check which storage policies are assigned to the namespace.
An architect needs a Supervisor whose Kubernetes workloads survive the loss of an entire vSphere cluster. The design has three clusters in two buildings with 4 ms of latency between them. What should be deployed?
A single-cluster Supervisor on the largest cluster, later expanded to three zones
Three separate Supervisors, one per cluster, joined through Enhanced Linked Mode
A Supervisor with vCenter HA enabled on the management cluster
Three vSphere Zones, each mapped to one cluster, with a three-zone Supervisor deployed across them
A developer must be able to create and manage TKG clusters and pods in a vSphere Namespace but must not change who has access to the namespace. Which namespace permission should the developer's group receive?
Can edit
Can view
Owner
Administrator on the vCenter root object
Which tool does vSphere 8 documentation specify for backing up and restoring workloads that run as vSphere Pods on a Supervisor?
vCenter file-based backup from the VAMI
The Velero Plugin for vSphere installed on the Supervisor
vSphere Replication with multiple point-in-time instances
Content library check-in of the pod images
Sections you finish are checked off in the contents.