Zero BOSH directors. That is the shift this part is about. On TKGI, short for Tanzu Kubernetes Grid Integrated, you built a cluster by asking a BOSH director, the release and lifecycle engine, to assemble VMs from a stemcell while Tanzu Operations Manager stitched the tile together. On VCF 9 you switch on a capability that already lives inside the ESX hypervisor, and about 47 minutes later you hold a Kubernetes control plane with no separate lifecycle stack to babysit.
VKS begins with the vSphere Supervisor, a Kubernetes control plane embedded in ESX and enabled per workload domain, not a BOSH deployment.
You choose the zone model, control plane availability, and load balancer at activation, and the zone choice is permanent while control plane HA can be scaled later.
From VCF 9 the Supervisor Kubernetes releases ship through a subscribed content library, separate from vCenter.
Headline command: kubectl vsphere login –server=sup01.corp.local –vsphere-username administrator@vsphere.local
Log in by fully qualified name, never by raw IP, or the virtual IP certificate check fails on the name mismatch.
Where the migration stands now
Parts 5 through 11 inventoried the TKGI estate and drew the VCF 9 target. Our reference migration is fixed: a production TKGI 1.18 estate on NSX-T with three clusters, UAA and LDAP authentication, a Harbor registry, NSX-T load balancing, one stateful application built from a web tier and PostgreSQL on persistent volumes, plus a couple of stateless services. Phase 3 starts here, and the first move is standing up the platform that will receive those workloads. Nothing about TKGI changes in this part. That is the core of the whole series: this is a migration onto a platform running beside the old one, not an in place upgrade of it. There is no path that turns BOSH and Ops Manager into a Supervisor.
The Supervisor is the Kubernetes control plane that VMware embeds directly into ESX. Each ESX host runs an agent called the Spherelet, which registers the host as a Kubernetes worker node. Enable the Supervisor and you get a conformant Kubernetes API from which vSphere Kubernetes Service, or VKS, provisions the guest clusters your applications actually land on. We covered the runtime mechanics in the standalone VKS Series, so this part spends its energy on the migration angle, the design calls, and the failures that stall an activation. For the full target picture, keep the series guide open in a tab.
One more framing before the commands. On TKGI, a cluster create meant a BOSH director building three to five VMs from a stemcell, often 20 to 30 minutes per cluster, on top of the Ops Manager apply that preceded it. Here the control plane is a property of the workload domain, so the 47 minute activation is a one time cost, not a per cluster tax. Every VKS guest cluster you create afterward is a Kubernetes object the Supervisor reconciles in minutes, with no director to resurrect and no tile to re apply. That single structural change, control plane as a platform capability rather than a deployed release, is why the day 2 model later in this series looks nothing like BOSH.
Prerequisites and preflight checks
Most failed activations I have seen were decided before anyone clicked Enable. Supervisor activation is fussy about routing, naming, and time. Walk this list first, because a stuck control plane at hour two usually traces back to one missing route or one absent DNS record.
| Preflight item | Why it matters | Proof |
|---|---|---|
| Route: management network to vCenter | Control plane VMs talk to vCenter over management | ping and 443 reachable from the subnet |
| Route: management network to Spherelet vmknic | ESX hosts join as worker nodes | host vmknic reachable on the management subnet |
| Five consecutive management IPs | Control plane and rolling upgrade addressing | block reserved and free of conflicts |
| Forward and reverse DNS for the VIP name | Login uses the name, not the address | nslookup resolves both directions |
| NTP consistent across ESX and vCenter | Token auth breaks on clock skew | skew within a few seconds fleet wide |
| Storage policy and content library | Placement of control plane and images | policy visible, library synced |
Run the name and time checks from a jump host on the management subnet before anything else. Versions tested: VCF 9.0 with the 9.1 line also generally available, Supervisor Kubernetes release synced from a subscribed content library, kubectl 1.31, and the kubectl vSphere plugin pulled from the Supervisor itself.
One preflight people skip is the content library sync itself. Because the Supervisor Kubernetes releases now arrive through a subscribed library rather than bundled with vCenter, a library that has never finished a sync will let you begin activation and then fail late, after the control plane VMs are already deploying. Confirm the last sync time reads recent, not never, before you submit, and treat a stale library as a blocker rather than a warning.
Design decisions before you activate
Three choices are locked in at activation to different degrees. Zone model is permanent. Control plane availability and load balancer can move later, with effort. Treat these tables as the reference artifact for this part: the mapping from what you want to what you must decide up front.
| Zone model | What it buys | Cost |
|---|---|---|
| Single management zone | Simplest activation, works with a single cluster, allows simple or HA control plane | One cluster outage hits management and workloads together |
| Three management zones | Control plane survives a single cluster loss | HA only, activation by API only, three clusters required, and no going back |
| Control plane | Nodes | Trade |
|---|---|---|
| Simple | 1 | Default when activated with a workload domain, single point of failure, downtime during upgrade, scalable to HA later |
| High availability | 3 | Survives one node loss, more CPU and memory, only option for three zone model |
| Load balancer | Fit | Limit |
|---|---|---|
| NSX | Default for NSX VPC and Segment models, no extra entitlement | Layer 4 only, cannot serve non Supervisor workloads |
| Avi, the NSX Advanced Load Balancer | Any networking model, Layer 7 rules, shareable, strong monitoring | Add on entitlement and its own deployment |
| Foundation Load Balancer | VLAN networking, single or active standby pair, no entitlement | Layer 4 only, limited scale, not for zonal HA |
Activation, step by step
Step 1, storage policy. Tag the datastore that will hold the control plane, then build a VM storage policy that matches the tag. Supervisor places its control plane, image cache, and objects by policy, and each zone is an independent failure domain with no cross zone replication, so keep management storage on consistent, local backing. Confirm the policy is visible to vCenter before you proceed.
Step 2, content library. From VCF 9 the Supervisor Kubernetes releases are delivered apart from vCenter. Create a subscribed content library and sync the Supervisor images, or use a local library if the site is dark. Do not skip the sync, because activation cannot stage the control plane image without it. Read the password from an environment variable rather than pasting it.
Step 3, activate. In vCenter, open Workload Management and enable the Supervisor on the target cluster, or use the simplified deployment flow for a lighter footprint. Select the cluster, the zone model, the management network with the five IP block, the workload network, the storage policy, and the content library. Submit, then watch the config status. Control plane VMs deploy, then the Spherelet rolls out to each ESX host. Expect the status to sit on Configuring for a while, that is normal.
Step 4, get the CLI and log in. Pull the plugin straight from the Supervisor VIP. Here is where the naming rule bites, so log in by fully qualified name.
Point the plugin at the raw address instead and the login is rejected on a certificate name mismatch, which is the documented reason to use a name. This is the real failure, not a hypothetical:
Verification and what green looks like
Green is three things at once: config status Running in Workload Management, a control plane node Ready, and ESX hosts showing up as worker nodes. Confirm from the CLI.
The node version string reflects the Supervisor Kubernetes release you synced, so it moves with the content library, not with vCenter. A single control plane node is expected for a simple activation. Once this is green, the Supervisor is live and ready for its first vSphere Namespace, which is the next part.
Rollback, fallback, and common failures
Rollback here is genuinely first class, because you are building beside a running estate. If activation goes sideways, disable the Supervisor from Workload Management. That removes the control plane VMs and any Supervisor side namespaces, and it leaves TKGI, its clusters, and every running workload completely untouched. There is no shared fate. You can disable, fix the routing or the library, and enable again the same afternoon. Keep the reserved IP block and DNS records in place between attempts so you are not chasing new conflicts each time.
| Symptom and error | Cause | Fix |
|---|---|---|
| Config status stuck on Configuring past an hour | Management network has no route to vCenter or DNS | Add the route, fix forward and reverse DNS, then let it reconcile |
| x509: certificate is valid for sup01.corp.local, not the IP | Login attempted by raw address | Log in by FQDN so SNI presents the right certificate |
| Login fails, message notes clock skew or token not yet valid | NTP skew between ESX, vCenter, and control plane | Fix NTP fleet wide, keep skew within seconds, retry |
| Content library sync fails or images missing | Proxy or certificate blocks the subscription URL | Set the library proxy, or switch to a local library and import |
| Insufficient resources to satisfy configured failover level for vSphere HA | Cluster lacks headroom for the control plane VMs | Free capacity or adjust HA admission control, then enable |
Field note and my call
My first Supervisor activation beside a live TKGI estate sat on Configuring for 92 minutes before I killed it. I had gone in with three management zones because it felt like the grown up choice, and I had assumed the management subnet reached everything it needed. It did not. Reverse DNS for the VIP name was missing in one zone, and the second cluster had no route back to the primary vCenter. I disabled, which cost nothing on the TKGI side, added the reverse zone and one static route, dropped back to a single management zone with a simple control plane, and re enabled. That run finished in 47 minutes, the timing you saw in the chart above. Two lessons stuck. First, the zone decision is the one you cannot walk back, so do not spend it on appearances. Second, every minute I thought I saved by skipping the reverse DNS check, I paid back roughly tenfold in a stalled activation.
My call for a migration landing zone: single management zone, simple control plane, and the NSX load balancer if you are already on NSX. Scale the control plane to three nodes after the first workloads land and you trust the platform. Avoid three management zones on day one unless you have a hard, current requirement for zonal control plane survival, because it is permanent and it forces API only activation. Reach for Avi only when you genuinely need Layer 7 rules or a shared load balancer, not by default.
Clean result checklist and quick answers
A clean end state looks like this:
- Workload Management shows config status Running for the cluster.
- kubectl get nodes returns a control plane node Ready and ESX hosts as worker nodes.
- Login succeeds by FQDN and the context is present.
- Storage policy and content library are bound and synced.
- TKGI and every existing cluster are unchanged and still serving.
Does enabling the Supervisor touch my TKGI clusters? No. It runs on a separate workload domain and shares no lifecycle with BOSH or Ops Manager.
Can I change the zone model later? No. Choose it at activation. Control plane HA, by contrast, is a later scale operation.
Is a Cloud Foundry estate migrated the same way? No. Tanzu Application Service is out of scope for this series, and its successor is Tanzu Platform for Cloud Foundry, not VKS.
What is my Monday move? On your own estate, reserve the five IP block, add the VIP name to DNS both directions, and confirm the management subnet reaches vCenter. That preflight alone prevents most stalled activations.
References
• Broadcom TechDocs, Requirements for Simplified Supervisor Deployment
• Broadcom TechDocs, vSphere Supervisor Models
• Broadcom TechDocs, Download and Install the Kubernetes CLI Tools for vSphere
About The Author
DrJha