Target Estate in One Picture

You do not migrate TKGI to VKS by lifting a cluster. You stand up a platform with a different shape and move workloads onto it, and that shape is the thing you are designing in this part. On our reference estate the target resolves into five layers, and every decision in the rest of this series lands on one of them. At the base sits a VCF 9 workload domain, ESX for compute, vSAN for storage, NSX for networking. On top of that runs the vSphere Supervisor, the Kubernetes control plane baked into vSphere that replaces the BOSH director and Ops Manager pairing you ran under TKGI. BOSH is the release engineering and VM lifecycle system TKGI leaned on; Ops Manager is the tile based console that drove it. Neither has a thing you reinstall on VCF 9, because the Supervisor absorbs their job. Above the Supervisor you carve vSphere Namespaces, each a slice with its own quota, roles and network. Inside a namespace a team provisions VKS guest clusters through Cluster API, the declarative Kubernetes API that stamps out and manages clusters. A platform load balancer, Foundation Load Balancer, NSX Load Balancer or Avi, gives each layer a Layer 4 address on the wire.

Draw those five layers once and every later part slots into it. Parts 12 and 13 build the bottom two, Supervisor and networking. Part 14 carves the namespaces and the first cluster. Parts 17 through 21 move workloads into the top layer with Velero. So the picture below is not decoration, it is the map every subsequent runbook writes against.

flowchart TD
  A[VCF 9 Workload Domain, ESX and vSAN and NSX] --> B[vSphere Supervisor control plane]
  B --> C[vSphere Namespace dev]
  B --> D[vSphere Namespace staging]
  B --> E[vSphere Namespace prod]
  C --> F[VKS guest cluster, Antrea CNI]
  D --> G[VKS guest cluster, Antrea CNI]
  E --> H[VKS guest cluster, Antrea CNI]
  LB[Platform Load Balancer, FLB or NSX LB or Avi] --> B

Component Mapping from TKGI to VKS

Most design mistakes on this migration come from assuming a TKGI component has a like for like twin on VCF 9. Some do, some collapse into the Supervisor, and one, Ops Manager, simply disappears. This table is the reference artifact for the whole part. Print it, put a target owner against each row, and you have the spine of your design document. Every mapping here is a decision you make once and then repeat for dev, staging and prod.

Read the first row again, because it is the one that surprises people. Under TKGI a full third of your operational surface was BOSH and Ops Manager, patching stemcells, reconciling tiles, applying changes that took an hour to converge. On VCF 9 that surface is gone, folded into vCenter and the Supervisor. Your design document is shorter than the TKGI one it replaces, and that is the point.

Three rows in that table hide real design work, so flag them now. VM classes are not a free rename of your plans, because a plan carried worker count and storage sizing that a VM class does not, so you split each plan into a VM class for the hardware shape plus explicit node counts and a StorageClass. That NCP to VPC row assumes an NSX edition that offers VPC, which not every TKGI estate licensed, so put a licence check against it before it reads as done. The Harbor row looks trivial and is the one that bites, because a registry with images in flight during a wave migration cannot share a lifecycle with a cluster you are about to delete. Owners against those three rows earn their place in the review.

Networking and Load Balancer Choices

VCF 9 gives the Supervisor three workload networking stacks, vSphere Distributed Switch, NSX Segment, and NSX VPC. NSX VPC, a Virtual Private Cloud construct that templates a per namespace network, is the cloud native default and the one this series designs toward. Here is the trap, and it is worth reading twice. Your workload network decides your load balancer, not the other way round. NSX VPC supports Avi Load Balancer only. It does not accept Foundation Load Balancer, and it does not accept the classic NSX Load Balancer. If your licensing does not include Avi Enterprise, choosing VPC on the whiteboard writes a cheque your platform cannot cash.

One nuance keeps this from being a straitjacket. The platform load balancer only serves Layer 4 for Supervisor managed endpoints, VM Service VMs, vSphere Pods, and VKS cluster control planes. Inside a VKS cluster your application teams still run whatever Kubernetes native ingress they like, Contour, Istio or the Gateway API, for Layer 7 routing and TLS. So picking FLB at the platform does not force plain Layer 4 on your apps. That separation is the honest answer to the team that insists they need Layer 7 everywhere, they get it, just not from the platform tier.

VPC networking also changes what your IP plan looks like, so budget for it in the design, not in the deployment. When you enable the Supervisor on VPC, the platform stands up a system VPC named vmware-system-supervisor-services-vpc for its own services and a kube-system VPC where the load balancers front the Kubernetes API and the CSI controller. Each namespace then draws its own VPC on top. That is a different address model from the shared T0 and per cluster T1 you hand cut under NSX-T, and it wants supernets sized for growth rather than a subnet per cluster carved by hand. Reserve the ranges once, at design time, and the namespace churn later costs you nothing.

Sizing the Reference Clusters

TKGI plans pushed you toward a fixed control plane count, and most estates ran three control plane nodes on every cluster out of habit, dev included. On VKS you set node counts per cluster in YAML, so dev does not need to pay for high availability it never uses. Our reference target runs a single control plane node in dev, three in staging and three in prod, with worker pools of two, three and six. That is nine control plane VMs across the estate instead of the fifteen a uniform three by three by three layout would burn, six VMs of headroom you keep for workers. The chart below is the sizing I take into the capacity conversation.

Common advice says match production topology in every environment so behaviour is identical. On a control plane that advice is wrong for VKS, because a single node control plane in dev fails and recovers the same way you already tolerate, and the two spare VMs matter more as workers when a developer is load testing. Keep the three node control plane where an outage has a customer on the other end, prod and the staging that gates it, and nowhere else.

Identity, Storage and Registry Placement

Three cross cutting decisions belong in the reference architecture even though each gets its own part later. Identity keeps its source of truth, your LDAP or Active Directory stays put; what changes is the broker, from UAA to vCenter SSO with Pinniped issuing the tokens VKS clusters trust. Storage runs through the Paravirtual CSI plugin in each guest cluster, which hands volume requests down to the Supervisor and on to Cloud Native Storage on vSAN, so your StorageClass names are a design choice you set now, not a runtime accident. Registry placement is the one people get wrong, put Harbor where its lifecycle is independent of any cluster you will recycle during migration, either as a Supervisor service or standalone, never inside a guest cluster you plan to tear down.

Before you commit VM classes and storage classes to the design, prove what the target Supervisor actually offers. Once it is stood up in Part 12, a two line check confirms the inventory your diagram assumes:

Design Choices to Lock Before You Build

If you take three things from this part, take these. Choose the workload network and its load balancer in the first session and get the licence signed off, because that one pair constrains everything downstream and it is the cheapest mistake to avoid and the most expensive to reverse. Write the TKGI to VKS mapping table into your design document and assign an owner per row, so nobody assumes Ops Manager needs a replacement it does not. Size control planes to risk, three nodes where an outage reaches a customer, one where it does not, and spend the saved VMs on workers. My verdict on the tempting default, do not reach for NSX VPC just because it reads as the future state, reach for it only when Avi Enterprise is already in your entitlement, otherwise NSX Segment with the NSX Load Balancer is the design that ships. Your next action, on your own estate, open a blank page, draw the five layers, and fill the load balancer box first.

For the component mechanics this design leans on, the VKS Complete Guide covers cluster internals, and the NSX Complete Guide covers VPC and segment networking in depth, so this series does not re-teach them. Next part stands up VCF 9 and enables the Supervisor, the bottom two layers of the picture you just drew.

References

VKS Architecture and Components, Broadcom TechDocs
Load Balancing in vSphere 9.0 and VCF 9.0, VMware Cloud Foundation Blog
Architecting VKS on VCF, Field Questions Answered, VMware Cloud Foundation Blog

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