A customer enabled a Supervisor on one vSphere Zone in April because the workload domain was ready and the hardware for the other two zones was still in a crate. In July they needed cluster level high availability for the control plane, found out that the management zone count is fixed at activation, and rebuilt the platform from scratch. Objective 1.3 exists because that mistake is common enough to be worth testing.

One naming note before the design work starts, because it shows up in every command later in this series. VKS, vSphere Kubernetes Service, is the product formerly called TKG Service or TKGS. Broadcom changed the product name and left the plumbing alone, so zone objects still answer to an API group called topology.tanzu.vmware.com and half the documentation URLs still say tkg. Read tanzu and tkg as VKS and move on.

flowchart TD
  A[VKS design brief] --> B{Cluster level HA required for the Supervisor}
  B -->|Yes| C[Three management zones]
  B -->|No| D[Single management zone]
  C --> E{Tenants must not share hosts with the control plane}
  D --> E
  E -->|Yes| F[Isolated workload zones]
  E -->|No| G[Combined workload zones]
  F --> H{Self service tenant networks required}
  G --> H
  H -->|Yes| I[NSX VPC with VKS 3.3.1 or later]
  H -->|No| J{NSX already deployed in the workload domain}
  J -->|Yes| K[NSX segments with Tier 0 and Tier 1]
  J -->|No| L[VDS with Foundation Load Balancer or Avi]

Zone models Broadcom publishes, and what each one survives

A vSphere Zone is a named container that maps to exactly one vSphere cluster and is treated as an independent failure domain. That is the whole definition. Everything interesting comes from how many of them you point the Supervisor control plane at, and how many of them you then hand to vSphere Namespaces for workloads.

Broadcom splits this into two independent axes in the VCF 9.0 design library, and candidates who have not read that library tend to collapse them into one. Axis one is management zones: one or three, decided at activation. Axis two is workload zones: combined with the management zones, or isolated into separate zones so tenant workloads never land on hosts running control plane VMs. Two axes with two settings each gives the four published models, and they are named exactly as follows.

Print that table. It is the reference artifact for this part, and every design item on the exam that mentions zones is asking you to land on one of those four rows. A fifth option, the Simplified Supervisor Model, exists in the same design library for people who want a Supervisor with the fewest decisions possible, and it is a single management zone underneath. Treat it as an enablement workflow rather than a distinct architecture.

Two rules govern how workload zones attach. A vSphere Namespace requires at least one vSphere Zone, and you can assign up to three. Assign three and the Supervisor spreads that namespace across all three underlying clusters in equal parts. Broadcom gives the arithmetic plainly: dedicate 300 MHz of CPU to a namespace on a three zone Supervisor and 100 MHz is taken from each vSphere cluster. That is not a rounding detail. It means a single pod in a three zone namespace can never consume the whole reservation, and it catches people who size namespaces the way they size resource pools.

Networking stack choice and what it locks in

Zones decide where things run. Networking decides what tenants can ask for. VCF 9.0 ships four supported paths to a Supervisor, and the exam guide names NSX and VDS in the objective wording precisely because candidates who have only ever seen one of them tend to answer from habit.

Three things about this table earn their place on a score report. Foundation Load Balancer is Layer 4 only, so any requirement mentioning ingress termination, a web application firewall or certificate offload rules it out immediately. NSX VPC is the only row that gives tenants a self service network boundary in the public cloud sense, and it carries a hard version floor: Supervisor 9.0 introduced VPC support and VKS 3.3.1 or later is required to consume it. And vSphere Pods, the CRX backed pods that run directly on ESX, need NSX. If a scenario asks for vSphere Pods and offers you a VDS answer, the VDS answer is wrong regardless of how sensible the rest of it looks.

What the networking choice does not lock is as important as what it does. Unlike the management zone count, a networking stack can be replaced by rebuilding the Supervisor on the same hardware, which is expensive but not architectural surgery. I have watched teams treat both decisions as equally permanent and consequently overthink the load balancer while under thinking the zones. Get the zones right first.

Host, IP and capacity arithmetic per model

Design items on this exam are frequently arithmetic in disguise. A scenario hands you a host count and asks which model fits, and the candidate who has memorised the per zone minimums answers in ten seconds while everybody else reasons from first principles and runs out of clock.

Broadcom states the per zone floor plainly. Each vSphere cluster backing a zone needs at least three ESX hosts, and four when vSAN provides the storage. Test and proof of concept estates are allowed to drop to one host, or two with vSAN, which is why so many home lab builds look nothing like the production numbers in the design library. Multiply the vSAN floor across the four models and the capital cost of each row becomes obvious.

IP arithmetic is smaller and gets forgotten more often. On the management network the Supervisor control plane wants five contiguous addresses: one for each of the three control plane VMs, one floating address that follows whichever VM currently answers, and a fifth held in reserve so that a patch can stand up a replacement VM without evicting anything. Hand a Supervisor a range of four and enablement completes, then the first patch cycle stalls. Every zone can use its own management network, which is a genuine relief on stretched physical estates and a detail worth remembering because it contradicts the intuition that a Supervisor needs one flat management subnet.

Discovery on an estate you inherited

Design work rarely starts on a blank sheet, and neither do design items. Both hand you an existing estate and ask what it is. These are the three commands I run before I write a single line of a VKS design document, against the reference lab this series uses throughout.

First question, how many zones does this Supervisor know about, and does the API agree with the vSphere Client. Zone objects live on the Supervisor as a custom resource, and the API group is the naming artefact I flagged earlier.

Now the failure this design produces, which I have caused twice and which almost nobody predicts on paper. Spreading nodes across three zones is good for stateless workloads and actively hostile to a naive stateful one. Block persistent volumes are per zone. They do not replicate across zones at the storage layer, because the latency penalty would be unacceptable. So a pod that gets rescheduled into a different zone from its volume cannot start, and the scheduler tells you exactly that.

Two fixes, and picking between them is a design decision rather than a repair. Constrain the StatefulSet to a single zone with node affinity and accept that a zone failure takes that database offline until you restore it, or run replication at the application layer with one replica per zone and let each replica own a volume in its own zone. High availability across zones for stateful services is an application property, not a storage property. That sentence has saved more of my designs than any diagram.

Exam focus for objective 1.3

A second, quieter trap lives in the load balancer column. Requirements that mention a web application firewall, TLS termination at the edge or DNS record automation are Avi requirements, not NSX edge requirements, because the NSX load balancer that ships by default with a VCF configuration handles Layer 4 only. Candidates who work in NSX heavy shops answer NSX by reflex and lose the item.

Objective checkpoint

Design three management zones and isolate the workload zones

My recommendation, and the one I now put in every VKS design where the host budget allows it, is Three Management Zones with Isolated Workload Zones on NSX VPC networking with Avi in the load balancing path. Three management zones because the only irreversible decision on the list deserves the safer setting. Isolated workload zones because keeping tenant pods off control plane hosts costs one cluster and removes an entire class of support conversation. NSX VPC because tenant self service is where this platform earns its keep, and Avi because Layer 7 requirements arrive eventually whether or not they were in the original brief.

Avoid Single Management Zone with Combined Workload Zones for anything you intend to keep. It is a fine shape for a lab and a bad shape for a platform, and I have never seen a team that started there stay there happily. If budget genuinely forbids twelve hosts, the honest compromise is three management zones running at the minimum three or four hosts each, with combined workload zones, and a documented plan to add an isolated workload zone later. That plan is deliverable because workload zones can be added. A plan to add management zones later is not deliverable, and writing one into a design document is how a rebuild starts.

Readers arriving from a Tanzu Kubernetes Grid Integrated estate should note that none of these zone models map cleanly onto a TKGI availability zone, and the migration path has its own series in the TKGI to VKS guide. For this exam, design from the four published models and nothing else.

Tonight, open the vSphere Client on your own lab, go to vCenter, Configure, vSphere Zones, and write down which model you are actually running. Then run kubectl get availabilityzones against the Supervisor and confirm the two agree. If your lab is a single zone, add a second zone as a workload zone and assign it to one vSphere Namespace, because doing that once is how you learn in your fingers which half of the zone story is reversible. Next part opens the Supervisor itself and works through its capabilities, services and architecture topologies against Objective 2.1.

References

• Supervisor Architecture and Deployment Options, Broadcom TechDocs, VCF 9.0
• vSphere Supervisor Zone Models, VCF 9.0 Design Library
• Create vSphere Zones for a Multi Zone Deployment with NSX, Broadcom TechDocs
• Architecting VKS on VCF, Field Questions Answered, VMware Cloud Foundation blog
• VMware Cloud Foundation VKS Administrator Exam Guide, 3V0-24.25

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts