Here is a line of output that has cost me more hours than any other single string on this objective.

Read it plainly and it says a VM class is missing. Act on it plainly and you open vCenter and start building one. Then you find that guaranteed-medium already exists on this same vCenter, sized at 2 vCPU and 8Gi, and has existed since the estate was built eighteen months ago. Nothing in that string tells you the real fault is a binding checkbox two clicks deep in Workload Management, on a namespace whose name does not even appear in the error text.

Objective 5.2 is that same problem repeated five times with five different nouns. VM class, cluster plans, content library, storage, networking. Each one raises its error inside Kubernetes and then gets repaired somewhere that is not Kubernetes, or gets repaired by restarting a component the error never mentions. Memorising the strings is not sufficient, and I will argue at the end of this Part that memorising them is actively counterproductive. What carries you through is a mapping from noun to owning surface, plus a fixed order for walking it.

One naming note, said once here and not repeated. VKS is the product formerly called TKG Service or TKGS, and that rename stops at the marketing layer. You will read Cluster API logs in a namespace called svc-tkg-domain-cNN, list Kubernetes releases with kubectl get kr where the short name descends from the tkg era, and find the stock cluster plan carrying a ClusterClass named tanzukubernetescluster. None of that is legacy output. It is current VCF 9.0 output, and both the product and the exam print it exactly as the CLI does.

Preflight before you touch a cluster

Every timing in that chart came from inducing a fault deliberately, walking away, and coming back cold. What separates the two bars is not knowledge, it is whether I established four things before forming an opinion. Which namespace the cluster lives in, which svc-tkg domain namespace serves it, which Supervisor Service version is installed, and which zone each node landed in. Skip those and every subsequent command is a guess dressed up as a diagnostic.

Derive that svc-tkg domain namespace rather than recalling it. On a multi cluster workload domain the suffix tracks the vCenter cluster moref, so an estate with three vSphere Zones can carry more than one of them, and typing the wrong suffix produces perfectly formatted output about a cluster you are not troubleshooting.

Numbered fault isolation procedure

Walk these five gates in order. Order matters because gates one and three are cheap and unconditional, while gates four and five require you to know which zone a workload landed in, and that knowledge only exists once machines have rendered. A fault at gate one makes gates four and five unanswerable, so a sweep that starts at networking wastes its first twenty minutes proving that a cluster with no nodes has no node networking.

Gate 1. VM class binding on the namespace

A cluster requests a VM class by name in its topology variables. VM Operator resolves that name against VirtualMachineClass objects present in the namespace, and a class that exists globally but is not bound to the namespace does not exist as far as the render is concerned.

Two details are worth carrying into the exam. First, the VM Operator controller log carries the same fault in a form that names the namespace explicitly, which the cluster condition does not. Second, this failure is also the reason a cluster can sit at Provisioned rather than Provisioning, because the Cluster object rendered fine and only the machine underneath it failed, per Broadcom knowledge article 402985.

Gate 2. Cluster plan reconciliation

Cluster plans surface as ClusterClass objects in the svc-tkg domain namespace, and every cluster operation waits on the plan reconciling its variables. When variable discovery fails, scaling, creation and upgrade all stop, and nothing in the cluster you are staring at is wrong.

Gate 3. Content library and Kubernetes release availability

Kubernetes releases reach a Supervisor through a content library, subscribed or local. This gate is the quietest of the five because a release that failed to synchronise or that carries a non compliant template raises no error at all. It is simply absent, and absence reads exactly like a version that was never published.

Broadcom knowledge article 425905 covers the case where a library item is present but corrupt or not security compliant, and the Supervisor therefore never registers it as a Kubernetes release. Note also the COMPATIBLE column. A release that lists as READY True and COMPATIBLE False is available but not a legal upgrade target for the plan you are running, which is a different fault with an identical looking symptom for anybody who reads only the first column.

Gate 4. Storage policy reach across zones

Storage classes inside a namespace are generated from storage policies assigned to that namespace, so a missing class is a vCenter assignment problem. On a zonal Supervisor there is a nastier variant. Assignment succeeds, the class appears, and volumes still fail, because the policy is only compatible with datastores in two of the three clusters that make up the zonal topology.

Read the pattern rather than the message here. The provisioning event text from vSphere CSI is generic and rarely names a zone, so what tells you the answer is that two claims from the same StatefulSet bound and the third did not. A policy built against a vSAN storage tag that only two of three clusters carry produces exactly this, and it will pass every test you run in az1 and az2.

Gate 5. Node networking and stale subnet entries

Last gate, and the one most likely to be blamed first. A machine that reaches Provisioned and stops, with a healthy NCP and no NSX alarms, is usually a leftover from a rolling redeployment rather than a networking outage.

Remove only the entry naming a machine that no longer exists, save, and the cleanup propagates to the NSX side. Broadcom knowledge article 402228 documents this as a vSphere CPI defect where deletion requests for the subnet are not sent when a node is replaced. Deleting a live entry by mistake is destructive, so compare against kubectl get machine output every time rather than trusting the naming pattern.

Verification, rollback and a clean end state

Each gate has its own proof, and none of them is the cluster reporting Ready, because a cluster can report Ready while carrying a fault that only bites on the next scale operation. Gate one is green when kubectl get virtualmachineclasses in the namespace lists the exact class named in the topology variables. Gate two is green when TopologyReconciled shows Status True with Reason Available on every workload cluster served by that svc-tkg domain namespace, not just the one you were asked about. Gate three is green when kubectl get kr lists your target version with READY True and COMPATIBLE True. Gate four is green when a test claim binds in every zone, which means three claims, not one. Gate five is green when the IPPool subnet list and kubectl get machine agree on names, one for one.

Rollback is straightforward for four of the five and genuinely risky for one. Binding a VM class, assigning a storage policy and restarting a controller deployment are all reversible with no data consequence, so back out by reversing the same action on the same surface. Editing an IPPool is the exception. There is no undo, and removing a subnet entry that belongs to a live node strands that node. Before saving that edit, capture the object with kubectl get ippool -n NS NAME -o yaml written to a file, so a mistaken removal can be reapplied. I have needed that file exactly once, which was enough to make it a habit.

Fault to owner lookup

This table is the artifact worth keeping. Column three is the point of the whole exercise, because in four of these five rows the object that owns the fault is not the object the error names, and in three of them the repair surface is not kubectl at all.

flowchart TD
  A[Cluster operation not completing] --> B{VM class bound to namespace}
  B -->|No| C[Bind class in VM Service, fix is in vCenter]
  B -->|Yes| D{TopologyReconciled True}
  D -->|No| E[Restart runtime extension and capi controllers]
  D -->|Yes| F{Target release listed by kubectl get kr}
  F -->|No| G[Check content library item compliance]
  F -->|Yes| H{Claims bind in every zone}
  H -->|No| I[Check policy compatibility per cluster]
  H -->|Yes| J{IPPool matches machine list}
  J -->|No| K[Remove stale subnet entry only]
  J -->|Yes| L[Fault is outside objective 5.2, return to Part 30 chain]

Exam focus, objective 5.2

Objective checkpoint

Sweep order I trust over intuition

My worst run at this objective was a customer estate where autoscaling had stopped and nobody could say when. Cluster looked healthy, nodes were up, workloads served traffic. Scaling simply did not happen. I spent seventy minutes on it and made three separate edits to the cluster manifest, because the condition message said ClusterClass and my instinct said manifest. I bumped a variable, reverted it, changed the machine deployment replica count by hand, reverted that too. Nothing moved. What eventually fixed it was a single rollout restart of a controller deployment I had not opened once, and the whole repair took ninety seconds. Then it came back sixty one days later, on a Sunday, and by then I recognised it in four minutes.

So here is my verdict, and it cuts against the most common piece of study advice for this section. Popular guidance says to build a flashcard deck of error strings for troubleshooting objectives. For objective 5.2 that deck will actively mislead you, because four of these five errors name the wrong object on purpose, in the sense that a controller can only report what it failed to resolve, never why resolution failed. Learn the ownership map instead. Noun to owning object to repair surface, five rows, the table above. That map survives version changes and a string deck does not, and it is also what an item writer is testing when they paste a condition message into a stem and offer you four plausible repairs.

Tonight, in your own lab, induce two of these deliberately. Unbind a VM class from a namespace with a running cluster, then try to scale it, and time yourself from symptom to the vCenter checkbox. Then create a storage policy that only matches datastore tags in two of your three clusters, assign it, and deploy a three replica StatefulSet against it. Twenty five minutes of breakage buys you the two hardest rows in the table, in a form you will not forget under exam pressure. Next Part stays in Section 5 and moves past provisioning into what happens after the cluster is fine and the container is not, with objective 5.3 on container deployment, registry and trusted CA errors.

References

• VKS cluster creation stuck creating the node virtual machine object, Broadcom knowledge article 402985
• ClusterClass is not successfully reconciled, VariablesReconciled must be True, Broadcom knowledge article 424003
• Not all Kubernetes Release versions visible on Supervisor after syncing the content library, Broadcom knowledge article 425905
• Unable to create workload cluster nodes due to stale NSX subnets, Broadcom knowledge article 402228
• 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