Three. That is the ceiling on how many vSphere Zones a single vSphere Namespace can draw compute from, and in every VCF 9.0 build I have tested it is a number you commit to at creation and cannot revise afterwards. A team that carves a namespace against two zones because the third cluster was still being patched has quietly decided that no zonal VKS cluster will ever live there, and they will find out weeks later when a cluster create is rejected and nothing in the message says namespace.

Last Part we activated Supervisors across five legal network and load balancer pairings. This Part carves that estate up. A vSphere Namespace is the unit a vSphere administrator hands to a platform team: a slice of CPU, memory and storage taken from one to three zones, with a specific set of storage policies, VM classes and content libraries stapled to it. Everything a VKS cluster can later do is decided here, which is exactly why objective 4.2 carries more weight in troubleshooting items than its position in the blueprint suggests.

Zone assignment as a one way door

When you create a namespace against three zones, vCenter does not create one container. It creates a namespace resource pool on each of the three vSphere clusters those zones map to, and every quota you later set is enforced across that set rather than inside a single pool. That detail explains most of the confusing behaviour operators report. A namespace showing plenty of headroom in aggregate can still refuse to place a large guaranteed node, because the reservation has to fit inside one zone, not across three.

Storage inherits the same shape. Broadcom documentation is explicit that a three zone namespace will not let you assign a storage policy that is not topology aware, and the reason is placement: a persistent volume has to be creatable in whichever zone the consuming pod lands in. A policy scoped to one cluster local datastore cannot satisfy that, so the Supervisor removes it from the list rather than letting you discover the problem at PVC time. On a single zone namespace the same policy attaches happily, which is why a manifest that works in a lab namespace fails in the zonal one.

flowchart TD
  Z1[vSphere Zone alpha] --> S[Supervisor]
  Z2[vSphere Zone bravo] --> S
  Z3[vSphere Zone charlie] --> S
  S --> NS[vSphere Namespace ns platform a]
  NS --> RP1[Resource pool on cluster alpha]
  NS --> RP2[Resource pool on cluster bravo]
  NS --> RP3[Resource pool on cluster charlie]
  NS --> SP[Storage policies project as StorageClasses]
  NS --> VC[VM classes project as VirtualMachineClass]
  NS --> CL[Content library supplies Kubernetes Releases]
  SP --> W[VKS cluster and PVC requests succeed]
  VC --> W
  CL --> W

Keep the table below. It is the artifact from this Part, and it answers the only question that matters when someone asks you to change a namespace: can I edit this, or am I rebuilding.

Namespace attribute mutability and the first symptom each one produces on a VCF 9.0 Supervisor.

Namespace creation and configuration procedure

Everything below was run against the reference estate: one vCenter, one workload domain, three vSphere Zones mapped to three clusters, VCF Networking with VPC, Avi in the load balancing path, vSAN backing two storage policies. Versions matter for the exam and for reproducing this, so here they are first.

Step 1, preflight the zones before you touch a namespace. A zone that is not healthy will still appear in the create wizard, so prove them from the Supervisor context first. Log in with the vSphere plugin rather than a raw kubeconfig, because the plugin is what mints the token your identity source issued, and it is the only login path the exam treats as correct for a Supervisor.

Note the API group behind that resource. It is topology.tanzu.vmware.com, not anything with vks in the name. Broadcom renamed the product and left the API surface alone, so any objective that touches zones, releases or cluster objects will show you tanzu strings, and a candidate who has only read the marketing pages hesitates on exactly those screens. Three zones, three cluster managed object ids, one per zone. If a zone maps to more than one cluster or a cluster appears twice, stop and fix the topology before carving tenancy on top of it.

Step 2, create the namespace against the zone set you actually want. In the vSphere Client this is Supervisor Management, then Namespaces, then Create Namespace. You pick the Supervisor, the name, the network, and the zones in one screen. For a namespace that will host zonal VKS clusters, select all three zones. There is no undo on that screen worth the name; deleting and recreating is the supported correction and it took six minutes on my estate including the resource pool teardown.

Step 3, assign storage policies and set a per policy limit. Configure, then Storage. Add the topology aware vSAN policy as the default and, if the team needs it, the high performance policy as a second class. Set a limit on each rather than leaving them unbounded, because an unbounded storage class on a shared vSAN cluster is how one team fills a datastore for everyone. Each assigned policy appears inside the namespace as a StorageClass with the policy name normalised to lower case and hyphens.

Step 4, assign VM classes and the content library. Configure, then VM Service. Add the classes the team is allowed to size nodes from, and add the subscribed content library that carries Kubernetes Releases. Skipping the library is the single most common cause of a cluster create that sits doing nothing, because the cluster controller has no image to resolve and reports the shortage as a class or release mismatch rather than a library problem.

Step 5, grant permissions from the identity source. Permissions, then Add. Bind the LDAP group to the edit role for a team that provisions its own clusters, and view for auditors. A user with a valid token and no binding logs in without error and then sees an empty namespace list, which every service desk on earth misreads as a login failure.

Step 6, cap object counts instead of reaching for CPU limits. Configure, then Object Limits. Capping the number of pods, services, PVCs and config maps constrains a runaway pipeline without touching the reservation arithmetic that VKS nodes depend on. This is the part of the procedure most guides skip, and it is the part that keeps a shared Supervisor stable.

Verification, limits and failure signatures

Three commands prove a namespace is actually usable, and they prove it faster than reading the Configure tabs back. Run them in the namespace context, not the Supervisor root.

That is what green looks like: at least one StorageClass, at least one VirtualMachineClass, and at least one Kubernetes Release reporting Ready True. Note the short name tkr and the release string carrying vmi and vks together. Broadcom kept the tanzukubernetesrelease resource and grafted the new product version onto the label, which is a small thing until you are reading a hot area screen under time pressure and looking for a resource called something sensible.

Now the failure. My PostgreSQL StatefulSet went to Pending against a namespace where the high performance policy had been removed during a cleanup and nobody had noticed, because a StatefulSet with WaitForFirstConsumer does not complain until a pod is scheduled.

Neither line mentions a vSphere Namespace. Both are pure Kubernetes messages produced by a vSphere side configuration change, and learning to read backwards from them is most of what objective 5.1 will later ask of you. Storage policy assignment produces the first message. Storage limit per policy produces the second.

Rollback. Every assignment in steps 3 to 6 is reversible in place: remove a storage policy, remove a VM class, unbind a permission, clear a limit. Removing a storage policy that is currently backing bound volumes does not delete the volumes, but it does stop new claims immediately, so treat removal as a change with a blast radius rather than a tidy up. The only true rollback for a wrong zone set or a wrong name is deletion and recreation, and deleting a namespace deletes everything in it including VKS clusters, so drain and back up first. Part 28 covers the Velero side of that.

Failure to cause lookup for vSphere Namespace and zone misconfiguration on VCF 9.0.

Exam focus for objective 4.2

One more habit worth building before the exam. Whenever a VKS cluster misbehaves, name the Supervisor object that could have caused it before you touch the cluster. Nine times in ten for this objective it is one of five things: the zone set, a storage policy, a VM class, a content library, or a permission. Working that list takes about ninety seconds and it is faster than any log you could open.

Objective checkpoint

Namespace and zone call for this estate

Here is the war story, because it is the reason I changed how I hand out namespaces. On a Tuesday afternoon I put a 96 GHz CPU limit on ns-platform-a to stop a noisy build farm from starving a database team on the same vSAN cluster. Nothing broke that day. On Friday the cluster autoscaler on a VKS cluster in that namespace stopped adding workers under load, and the cluster reported nothing more useful than a machine stuck in Provisioning. Nodes were sized from guaranteed-2xlarge, 8 vCPU and 32 GiB each, fully reserved. Five existing workers had already consumed most of the ceiling, and the sixth could not reserve. Forty one minutes went into reading machine controller logs before I looked at the namespace tab I had edited myself three days earlier. Clearing the CPU limit fixed it in under a minute.

My recommendation for this estate, and the one I give candidates: create every namespace that will host VKS clusters against all three zones even if only one cluster is needed today, assign both storage policies and every VM class the team could plausibly need at creation time, attach the content library in the same sitting, and govern with storage limits and object limits only. Leave CPU and memory limits alone unless the namespace is running Supervisor Pods from best effort classes. Three zones cost you nothing if unused; two zones cost you a rebuild.

Tonight, in your own lab, log into the Supervisor and run those four verification commands against your busiest namespace. If any one of them comes back empty, you have found a cluster failure that has not happened yet. For the underlying product mechanics this Part deliberately does not re teach, the VKS Series is the walkthrough that sits beneath this exam path, and the NSX Series covers the segment and VPC objects a namespace binds to. Next Part moves from carving tenancy to filling it, with Supervisor Pods and VM Service workloads under objective 4.3.

References

• Broadcom TechDocs, Configuring and Managing vSphere Namespaces, VCF 9.0
• Broadcom TechDocs, Set Resource Limits to a vSphere Namespace
• Broadcom TechDocs, Configuring and Managing vSphere Zones
• Broadcom, VCAP-VKS 3V0-24.25 Exam Guide

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