Run one command against a freshly provisioned VKS cluster in my lab and four storage classes come back, even though the vSphere administrator only ever created two storage policies. Nobody typed those four names into a manifest, and working out where they came from is most of what Objective 1.2 is actually asking you to do.

Candidates preparing for 3V0-24.25 keep reaching for CKA material when they hit this objective. I understand the instinct and I think it wastes a fortnight. On a VKS cluster you will never run kubeadm, never place a static pod manifest, never take an etcd snapshot by hand and never rotate a control plane certificate with kubeadm certs renew. Those tasks belong to Cluster API controllers running on the Supervisor, and Broadcom did not write a single objective about them. What Objective 1.2 wants is narrower and, in my experience coaching people through this exam, much harder: given a Kubernetes object in front of you, name the vSphere object that produced it.

One naming note that will save you confusion in every command below. VKS, vSphere Kubernetes Service, is the product formerly called TKG Service or TKGS. Broadcom renamed the product but not the plumbing, so API groups, CRDs, namespaces such as tkg-system and half the documentation URLs still say tkg. Read tkg as VKS and keep going. TKGS is not a separate live product you also need to learn.

Control plane anatomy from a kubectl session

Last part we compared vSphere Pods, VM Service machines and VKS clusters on paper. This part we open a terminal against the cluster that came out of that comparison, a three node VKS cluster called vks-prod-01 sitting in a vSphere Namespace called vks-prod on our three zone estate. Everything that follows was run against these versions, and I would not trust output from an older Supervisor to match.

Two things deserve a comment. I use kubectl with the vSphere plugin rather than a raw kubeconfig because that plugin is what wires your vCenter identity into both API servers at once, and because every identity objective later in the blueprint assumes it. And –insecure-skip-tls-verify is a lab habit, not a production one. Objective 2.5 in Section 2 is partly about the certificate work that lets you drop that flag.

A successful login leaves you holding two contexts, and confusing them is the single most common self inflicted wound I see. One context points at the Supervisor, where a vSphere Namespace behaves like a Kubernetes namespace and where Cluster API objects live. Another points at the VKS cluster, where you are a normal Kubernetes user with real cluster admin. Same kubectl binary, two completely different object catalogues.

Read that last column carefully, because it is the whole third premise of this series in one field. Kubernetes believes it discovered those zone labels. It did not. A vSphere administrator mapped three vSphere Zones to three vSphere clusters, attached them to the Supervisor, and the Cluster API provider stamped the labels onto nodes it created. Delete a zone in vCenter and your Kubernetes topology constraints stop working, with no Kubernetes level explanation of why.

Machine objects on the Supervisor and Node objects in the cluster describe the same virtual machines from two sides. When a node goes NotReady, the answer is almost never in the cluster. It is in the Machine object, the VirtualMachine object underneath it, or the vSphere task list. Practise pivoting between the two contexts now and Section 5 becomes far less frightening.

Pod networking, services and where a VIP comes from

A CNI, Container Network Interface, is the plugin that gives pods addresses and enforces network policy. VKS clusters support two of them and no others: Antrea, which uses Open vSwitch, and Calico, which uses the Linux bridge with BGP and enforces policy through IP tables. Antrea is the system default, so a cluster manifest that says nothing about a CNI gets Antrea. Calico is selected either in the cluster YAML or by changing the Supervisor wide default. There is also an Antrea NSX Routed variant for routable pod networking, which matters when something outside the cluster needs to address a pod directly.

What trips people up is that the CNI stops at the edge of the cluster. Pod to pod traffic and network policy belong to Antrea or Calico. ClusterIP and NodePort services belong to Antrea or Calico. A Service of type LoadBalancer belongs to none of them. That address is minted by whichever load balancer the Supervisor was enabled with, which on our estate is Avi, and on other estates is the NSX load balancer or the Foundation Load Balancer. Ingress belongs to nobody at all until you install a third party ingress controller such as Contour, because VKS does not ship one and does not pretend to.

Prove the split to yourself in ninety seconds. Expose the stateless web deployment we have been carrying since the start of the series and watch which component answers.

Twenty two seconds of pending is normal and it is not the cluster thinking. That gap is Avi being asked for a virtual IP through the Supervisor. If EXTERNAL-IP never leaves pending, stop looking at Antrea logs. Look at the load balancer, which is exactly what Objective 3.1 is about later in the blueprint.

Storage classes inherited from a vSphere Namespace

Back to those four storage classes. A vSphere administrator writes storage policies in vCenter, which are rules describing what a datastore must offer. Assigning a policy to a vSphere Namespace does two things at once: it decides which datastores that namespace may touch, and it causes the Supervisor to generate a matching Kubernetes storage class. That storage class is then propagated down into every VKS cluster provisioned in the namespace. Two policies became four classes because each one appears in two editions, one with Immediate volume binding and one with WaitForFirstConsumer.

Names vary by estate, so read yours rather than copying mine. What does not vary is the pairing, and choosing between the two editions has a measurable cost that nobody mentions in training. I ran the same 20Gi ReadWriteOnce claim ten times against each of our four classes and timed from apply to Bound.

That is a real trade off and it has a clear answer. On a multi zone estate, use the WaitForFirstConsumer edition for anything with a pod affinity or topology constraint, because Immediate binding will happily create a disk in zone A and then leave your pod unschedulable in zone C. On a single zone estate, Immediate binding is faster and costs you nothing. I have watched teams standardise on late binding everywhere as a supposed best practice and then spend a sprint wondering why their CI pipeline got slower.

Knowing why the wait exists means knowing the path a claim travels. Nothing is provisioned inside your cluster. pvCSI, the paravirtual CSI driver that lives in the VKS cluster, has no vCenter credentials at all and cannot create a disk. It hands the request up.

flowchart LR
  A[PVC applied in VKS cluster] --> B[pvCSI, no vCenter credentials]
  B --> C[Mirror PVC in the vSphere Namespace]
  C --> D[CNS CSI on the Supervisor]
  D --> E[CNS in vCenter]
  E --> F[Datastore matched by storage policy]
  F --> G[PV shows Bound in cluster and namespace]

Now the failure, because a happy path teaches nothing. Here is the war story that made me build the lookup table further down. A customer of mine had a PostgreSQL StatefulSet stuck Pending for three days. Two engineers had rewritten the Helm values twice and opened a support case against the chart. I asked for one command.

Not a chart problem. Not a Kubernetes problem. Somebody had assigned only the default storage policy to that vSphere Namespace, so the high performance class was never generated and never propagated. Fix time in the vSphere Client was under a minute: open the namespace, add the second storage policy, and watch the class appear in the cluster without touching the StatefulSet. Three days of engineering time against forty seconds of vCenter work, and the whole gap was caused by nobody in the room knowing which object creates a storage class.

Backing that out is undramatic and worth rehearsing. Removing a storage policy from a namespace removes the class from the cluster, but it does not delete volumes already bound through it, and a pod that later tries to reschedule will fail in a way that looks like a scheduling fault. Drain the workload first, then remove the policy, then confirm no PVC still references the class.

Helm charts, packages and a service mesh footnote

Helm is a package manager for Kubernetes and it works on a VKS cluster exactly as it works anywhere else, which is precisely why it earns a mention in the objective and almost no special handling. You are cluster admin inside a VKS cluster, so helm install behaves normally. Two things are different and both bite.

First, Pod Security Admission is enabled by default on VKS clusters, with the enforcement level set through the podSecurityStandard variable on the cluster, and system namespaces such as kube-system and tkg-system excluded. Any community chart that assumes it can run privileged will be refused, and the refusal appears on the ReplicaSet rather than on the helm command, which is why people misread it.

Helm reported success because Helm did its job. It created a Deployment. Admission control killed the pods a layer below. Fix it by setting securityContext fields in the chart values, or by relaxing enforcement for that one namespace with a label, and choose the first option unless you enjoy explaining the second to an auditor.

Second, Helm is not the only packaging system in play. VKS ships a set of standard packages delivered through Carvel style repositories and driven by the VCF CLI, which is a separate mechanism with its own versioning and its own default values files. Istio, the service mesh, arrives that way rather than as a plain Helm chart.

For Objective 1.2 you need to know what a service mesh does and that VKS offers Istio as a supported package, not how to run one. A mesh puts a proxy in the request path so that traffic between services can be encrypted, retried, split and observed without application code changing. Istio gives you two shapes of data plane: the sidecar model, where a proxy container joins every workload pod, and the ambient model, where a shared node level proxy handles traffic instead. Sidecars cost memory per pod and ambient costs you a newer, less familiar failure surface. Part 15 of this series takes that decision apart properly against Objective 3.6, and package repository mechanics belong to Objective 4.8.

Failure to cause lookup for objective 1.2

This is the artifact to keep. Every row maps a Kubernetes symptom to the vSphere object that actually caused it, which is the exact translation the objective is testing and the exact translation Section 5 will demand of you under time pressure.

Exam focus for objective 1.2

Objective checkpoint

Three original questions written from the published objective wording. Cover the reasoning, answer, then check.

Learn the inheritance chain, not the Kubernetes glossary

My recommendation for this objective is blunt, and it contradicts most study advice I see posted. Do not spend a fortnight on a general Kubernetes course before sitting 3V0-24.25. If you already know what a Deployment, a Service and a PVC are, you know enough Kubernetes for this exam. Spend that fortnight instead building the mental map of which vSphere object produces which Kubernetes object, because that map is what the other 32 objectives silently assume and it is not taught in any Kubernetes course.

A clean result for this part looks like four things. You can switch between the Supervisor context and the cluster context without hesitating. You can name the provider for every row in the endpoint table from memory. You can point at any storage class in your cluster and name the vSphere storage policy behind it. And you can explain, out loud, why a claim in your cluster becomes a disk in vCenter without your cluster ever holding a vCenter credential.

Tonight, in your own lab, run kubectl get storageclass in a VKS cluster and then open the matching vSphere Namespace in the vSphere Client. Count the classes, count the policies, and confirm the arithmetic holds. If it does not, you have found something worth understanding before Part 4 turns to reference architecture. Next part we leave the terminal and design the estate: NSX, VDS and zones against Objective 1.3.

References

• VKS Cluster Networking, Broadcom TechDocs, VCF 9.0
• Storage for VKS Clusters, Broadcom TechDocs, VCF 9.0
• Install Istio on VKS Clusters, Broadcom TechDocs
• 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