A candidate I was coaching last month asked me a question I could not answer in one sentence. He had read objective 4.10 as a Harbor question, spent a week practising add-on service lifecycle, and wanted to know whether he had wasted the week. He had not wasted it, but he had prepared for roughly half of what the wording covers.

Update, upgrade, and a blueprint phrase that reads two ways

Start with the vocabulary, because Broadcom is unusually careful about it here and the objective is not. Product documentation states plainly that the term update describes this process instead of the term upgrade, and that upgrade is a limited form of update which increments the software version. An update moves the Kubernetes version of the Supervisor and the infrastructure components and services underneath it. That distinction is not pedantry. It is the reason a Supervisor update touches your ESX hosts and a mental model built on kubeadm does not.

Now the ambiguity my candidate hit. Objective 4.10 says Supervisor service, singular and lowercase. Read one way that is the vSphere Supervisor platform itself, the thing you move from Kubernetes 1.31 to 1.32. Read the other way it is a Supervisor Service, the capitalised add-on concept covering Harbor, external-dns and the rest, which Part 19 already walked through. Broadcom uses both phrasings in its own documentation, so guessing which one the blueprint means is a bad use of study time. Prepare both. Weight your effort about eighty twenty toward the platform update, because that is where the destructive failures live and because the add-on service lifecycle is already covered by objective 4.4.

Trace this back to the Supervisor, as this series does in every Part. Nothing in a VKS workload cluster is upgraded by this procedure, yet everything in a VKS workload cluster is exposed to it. Product documentation carries an explicit note that updating a Supervisor can trigger a rolling update of the VKS clusters deployed there. Your pg-orders StatefulSet from Part 24 does not care about Supervisor version strings, but it will absolutely care when the node it sits on gets replaced because a Supervisor update cascaded downward. Read Part 21 on VKS rolling updates next to this one, because the two mechanisms chain.

Preflight, content library, and a legal version path

Four prerequisites, each with a check that proves it rather than a click that assumes it. You need a Supervisor content library holding the target release, because from VCF 9 onward that is where asynchronously delivered Supervisor images come from. You need a target version exactly one Kubernetes minor above your current one. You need vCenter at or above the build that target requires. You need enough DRS headroom that hosts can evacuate, which is the prerequisite nobody writes down.

Preflight 2 deserves a sentence of its own. That single batch-writer pod is a vSphere Pod running directly on the ESX host rather than inside a workload cluster, and it is the most common reason a Supervisor update stalls. Documentation is explicit that a failure to evacuate vSphere Pods from an ESX host causes an unsuccessful Supervisor upgrade, because the host cannot enter maintenance mode. Find those pods before you start, not at hour two.

On the version string itself, learn to read it rather than memorise it. In v1.32.9+vmware.2-fips-vsc9.0.2.0 the prefix v1.32.9 is the Kubernetes version and the vsc9.0.2.0 suffix is the vSphere Supervisor release number. Two different things live in one string, and the exam likes that kind of compound identifier. Supervisor Kubernetes versions follow an N minus 2 support policy with a minimum of twelve months of support per release, and Broadcom’s own guidance is that you may need to update three times a year to keep pace. Three runs a year, each of them a cluster wide maintenance event, is a planning fact worth carrying into a design question.

flowchart TD
  A[Confirm current Supervisor Kubernetes version] --> B{Target exactly one minor higher}
  B -- No --> C[Run the intermediate minor first]
  B -- Yes --> D{vCenter build supports target}
  D -- No --> E[Upgrade vCenter before the Supervisor]
  D -- Yes --> F[Supervisor content library holds the image]
  F --> G[Drain vSphere Pods that block EMM]
  G --> H[Apply Updates and let prechecks run]
  H --> I[Control plane VMs replaced one at a time]
  I --> J[Each ESX host enters maintenance mode for spherelet]
  J --> K[VKS clusters may roll afterwards]

Numbered update run from Supervisor Management

Broadcom exposes no supported CLI for triggering this. That is unusual for a series where almost everything else is a kubectl verb, and it is worth saying out loud once: the Supervisor update is a vCenter workflow, and the exam will present it as one. Six steps, and none of them are optional.

Now the run that does not work, because a happy path teaches nothing. On my first attempt I reached past the version my vCenter could carry. Prechecks caught it, which is the system working correctly, but the wording sent me looking in the wrong place for twenty minutes.

Step 4 has a companion decision that the Updates tab surfaces and that candidates routinely miss. You can update only the Supervisor Kubernetes version, or you can update everything, meaning the VMware component versions alongside the Kubernetes version. Picking Kubernetes only keeps the change surface small and is the right answer when you are chasing a CVE. Picking everything is the right answer when you are about to run a vCenter upgrade and want the Supervisor and its infrastructure components aligned first. Neither is a default. A scenario item that mentions a component version mismatch is steering you toward update everything.

Where does the image come from. Prior to vCenter 9.0.0.0, vSphere Supervisor shipped inside vCenter releases and there was nothing to choose. Supervisor components are now decoupled, and vSphere Supervisor 9.0.0.0100, generally available on 11 July 2025, was the first independently delivered release. Patches arrive through a subscribed content library pointed at Broadcom’s Supervisor image endpoint, while releases carrying larger architectural change still come through a vCenter upgrade. An air gapped estate publishes the same images from a local content library, which is the same pattern Part 9 established for Kubernetes releases. I am marking the exact subscription URL as [VERIFY] rather than printing a host I could not confirm against a Broadcom page this run; the documented path component is /supervisor/v1/latest/lib.json and you should read it off your own Software Depot configuration.

Verification while four control plane VMs exist

Here is the moment that causes support calls. Midway through a healthy Supervisor update, vSphere inventory shows four control plane VMs where there should be three. That is correct behaviour, documented behaviour, and it is temporary. Order of operations is: the system builds a new control plane VM and joins it to the existing control plane, migrates objects off one old VM, removes that old VM, then repeats until all three are replaced. Only after the control plane is done do the worker nodes update, and the worker nodes are your ESX hosts, each spherelet replaced one at a time.

Do not stop at the node list. Check that svc-harbor and any other Supervisor Service namespace came back Active, because a Supervisor update reconciles those services too. There is a documented case worth knowing: estates that still had Embedded Registry enabled found that vCenter 9.0.0.0 removes it entirely, the controller manager lands in CrashLoopBackOff, and after a subsequent Supervisor update the Harbor namespace can sit in a terminating state. Migration to Harbor as a Supervisor Service is expected to happen before the vCenter upgrade, not after. If a scenario mentions Embedded Registry anywhere near an upgrade, that is the hook.

Rollback, pause, and an honest fallback

Give people the truthful answer here, because the comfortable answer is wrong. You cannot downgrade a Supervisor Kubernetes version. There is no button that walks 1.32 back to 1.31. What exists is a system that enforces precheck conditions before it starts and supports rollback if a cluster upgrade is not successful, which is a narrower promise than it sounds. In practice your fallbacks are three, in this order.

First, fix forward. A stalled update is usually a blocked host, and clearing the blocker lets the same run continue rather than restarting it. Second, re-run the components update, which is the documented workaround for a race condition on ManagementImageProxyConfig that leaves a components upgrade wedged. Third, and only for a genuinely broken control plane, restore the Supervisor from backup. Restore carries its own documented sharp edges, including a case where restoring vCenter from backup after a Supervisor version change leaves existing control plane VMs under Discovered VMs and new ones orphaned. Restore is a real option and a bad first option.

Supervisor update failure to remediation lookup

This table is the artifact worth returning to. Every row is a documented failure with the error text or symptom you will actually see, and the action that clears it. Learn the left column by symptom, not by cause, because the exam gives you symptoms.

Two rows in that table are the same underlying mistake wearing different clothes, and that is the point. Compatibility failures surface at precheck with wording that blames infrastructure, so a candidate reads ESX or NSX and starts investigating the wrong layer. Whenever a Supervisor version refuses to apply, check vCenter build first and everything else second.

Field note on a window that ran three times long

I booked a 45 minute window. I had read the rolling update description, counted three control plane VMs, mentally divided by a coffee, and told the application team we would be done before 23:00. We finished at 00:41, two hours and forty one minutes after Apply Updates.

Control plane replacement took 38 minutes and behaved exactly as documented, including the fourth VM appearing in inventory and me briefly assuming something had gone wrong. Everything after that was hosts. Twelve of them, each entering maintenance mode so the spherelet could be installed, averaging 9.3 minutes. One host sat at 47 minutes because a single vSphere Pod in a namespace nobody had touched in six months refused to evacuate. Deleting that pod cleared it in under a minute. Six months of an unowned batch job cost me 38 minutes of a maintenance window and a very awkward status update.

Here is where I disagree with the common advice. Almost every write up describes a Supervisor update as a rolling control plane operation with minimal workload impact, and treats the host phase as a footnote. That framing is backwards. In my measured run the host phase was 70 percent of the elapsed time and 100 percent of the risk, because entering maintenance mode on each ESX host is a real workload evacuation across the whole cluster. Broadcom documents that this has been standard behaviour since vSphere 7.0 and continues through 9.1.x, and notes the process is expected to change in a future release to reduce host impact. Until it does, size the window by host count and DRS headroom, not by control plane VM count. I reversed my own practice after that night: I now inventory vSphere Pods and quiesce them before every Supervisor update, and I multiply my estimate by host count times ten minutes with a 30 percent margin.

Supervisor update discipline I would adopt

My recommendation is narrow and I will defend it. Treat a Supervisor update as an ESX cluster maintenance event that happens to change a Kubernetes version, and schedule it the way you schedule host patching. Choose Kubernetes version only when you are chasing a fix and update everything when you are staging for a vCenter upgrade. Never let a Supervisor drift more than one minor behind what your estate supports, because catching up costs you two full windows instead of one and the N minus 2 policy gives you less room than it appears to.

A clean result looks like this. Three control plane VMs, all reporting the target version, all Ready. Every ESX host reporting the same target version. All vSphere Namespaces still Active, including your Supervisor Service namespaces such as svc-harbor. Workload clusters in Provisioned phase with their VKr unchanged unless you intended otherwise. No lingering tasks in Recent Tasks. If any one of those five is off, you have a partial update, not a finished one.

Tonight, in your own lab, do one thing before you do anything else with this objective. Run the vSphere Pod inventory from Preflight 2 across every node in your Supervisor and write down what you find. If your lab is anything like mine, there is at least one pod nobody remembers deploying sitting on a host that will need to drain. Finding it now is a five minute job. Finding it at hour two is the reason people book longer windows the second time. When you have that list, read the VCAP-VKS exam guide pillar for how 4.10 sits alongside the other Section 4 objectives, and if the Supervisor platform itself still feels like a black box, the VKS Series is the walkthrough sitting underneath this study path. For the add-on service reading of this objective, Part 19 covers Supervisor Service lifecycle.

References

How vSphere Supervisor Updates Work, VMware Cloud Foundation 9.0 documentation
Update the Supervisor, VMware Cloud Foundation 9.0 documentation
VMware vSphere Supervisor Release Notes
VMware Certified Advanced Professional vSphere Kubernetes Service 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