A network architect on one migration asked me a question that stalled the whole design review. If both platforms run on NSX, she said, why can we not point VKS at the NSX-T topology we already built for TKGI. Fair question, and answering it honestly is the reason this part exists. Both platforms do sit on NSX, and almost nothing about how they consume it survives the move.

Networking on the TKGI estate today

Start with what you already run, because the assessment begins there. On TKGI, pods reach the network through NCP, the NSX Container Plugin, a controller that watches the Kubernetes API and programs NSX-T objects to match. When a namespace appears, NCP carves a subnet, wires a segment, and updates the load balancer. None of that is manual once it runs, but every object it creates sits on a topology you built by hand first.

That topology has a shape TKGI assumes. A Tier 0 gateway, the NSX-T construct that connects to the physical fabric, sits at the top. Under it, the default Shared Tier 1 topology gives each cluster one Tier 1 gateway for its node, namespace and load balancer objects, which keeps the NSX-T object count per cluster low enough to scale. Two IP blocks feed the arrangement, a node IP block for the Kubernetes virtual machines and a pod IP block for the pods themselves. Each new namespace draws a subnet, a /24 by default, out of that pod block.

Pod addresses are non routable, so NSX-T writes a SNAT rule, source network address translation, on the Tier 0 gateway to let pod traffic egress. Service load balancing comes from the NSX-T load balancer, provisioned and sized in NSX-T terms. On the reference estate that is three clusters, dev, staging and prod, all leaning on the same NSX-T managers and edges, with a pod IP block that looked generous on day one and rarely gets audited after.

Assessment here is mostly counting. A rough proxy for how much of the pod block you have consumed is the namespace count, since each namespace holds a /24. This much is safe to run against a live cluster, then cross checked in NSX-T Manager where the pods IP block shows allocated subnets against its total size:

NSX VPC networking under VKS

VKS consumes networking differently, and the difference starts one layer up. Instead of a hand built Tier 1 per cluster, a VKS Supervisor draws from an NSX VPC, a virtual private cloud construct that behaves like a self service tenant network. If you do not name a VPC when you create a vSphere Namespace, NSX creates one for you in the default project, which is convenient in a lab and a trap in a migration, for the reason my war story just showed.

Inside a VPC an administrator sets two ranges, the external IP blocks that provide routable addresses and the private IP blocks that back internal subnets. Subnets then come in three access modes, Private, Public and Private Transit Gateway, and each subnet is realized as an overlay segment in the project transport zone. That model replaces the node block, pod block and manual SNAT arrangement you tuned on NSX-T with a construct that handles routing, address translation and subnet creation on its own. Less to hand build, and a different mental model to learn.

In the cluster, VKS runs Antrea, its default container network plugin, as an overlay. On VCF 9.1 an Antrea to NSX adapter surfaces pod traffic back into NSX so vDefend can apply microsegmentation and see flows, which is how you recover the distributed firewall visibility NCP gave you on NSX-T. VKS is CNCF conformant, so Calico and Cilium run inside guest clusters if a team needs them, but Antrea is the path with native NSX visibility. Standing up the Supervisor takes a minimum of two Edge nodes for its Edge cluster, and it can spread across one or three Management Zones depending on the availability you want. My deeper walk through the adapter and VPC mechanics lives in the NSX Series piece on VKS and the Antrea to NSX adapter, and the VKS Series covers the Supervisor build end to end. This assessment leans on both rather than repeating them.

Construct to construct mapping, NSX-T to VPC

Keep the table below. It is the reference artifact of this part, a construct by construct map from what you run on NSX-T today to what replaces it under VKS, with the migration action for each row. When someone on the change board claims the networking carries across, this is the answer, line by line, that shows it does not.

Read the migration action column top to bottom and the pattern is impossible to miss. Every row is a rebuild or a remap, and not one is a transfer. The stack diagram below puts the two models side by side so the redesign is visible rather than asserted.

flowchart TB
  subgraph s1 [TKGI on NSX-T via NCP]
    A1[Tier 0 gateway to fabric] --> A2[Shared Tier 1 per cluster]
    A5[NCP programs NSX-T] --> A2
    A2 --> A3[Node IP block subnet]
    A2 --> A4[Pod IP block subnet /24]
    A2 --> A6[NSX-T load balancer]
  end
  subgraph s2 [VKS on NSX VPC via Antrea]
    B1[NSX VPC external and private blocks] --> B2[Private and Public subnets]
    B2 --> B3[Supervisor and node networks]
    B4[Antrea overlay in cluster] --> B5[Antrea to NSX adapter]
    B2 --> B6[Foundation LB or Avi]
  end

Numbers that shape the target design

Design arguments get settled faster with countable facts than with adjectives, so here are the numbers that actually move the VPC sizing decision. The table pairs each metric on NSX-T against its VKS form, and the chart under it turns the pod addressing math into the one picture that changes how people size blocks.

One number reframes the whole exercise. A /16 pod block sounds enormous until you divide it into /24 subnets, one per namespace, and land on a ceiling of 256 namespaces. On the reference estate, sitting at 203, that ceiling is not a distant abstraction, it is 53 namespaces away.

Here is where the tutorial default is wrong for a migration. Guides tell you to let VKS auto create a VPC in the default NSX project and move on, because for a greenfield lab that is the fast path. On an estate that already runs NSX-T, the auto created VPC pulls from default ranges that can collide with the node and pod blocks TKGI is still using, and a collision is exactly what sent my first cluster egress asymmetric. Pre carve the external and private blocks for the VPC, out of ranges that do not touch anything TKGI holds, before you activate the Supervisor. Convenience during setup buys you a routing incident during cutover.

Load balancing choice, Foundation LB against Avi

Service load balancing is the row on the mapping table that carries the most operational weight, because it is where your users actually hit the platform. VKS gives you two paths, the Foundation Load Balancer built into VCF for straightforward L4 service exposure, and Avi, the NSX Advanced Load Balancer, for richer L4 and L7 with real health monitoring, analytics and policy. Part 13 weighs the two in the depth the decision deserves, so this is the assessment level call, not the build.

My verdict for the reference estate is Avi, and the reason is continuity of behaviour rather than features on a slide. That estate already runs the NSX-T load balancer with a real inventory of virtual servers, health monitors and persistence profiles, and Avi maps those concepts far more closely than the Foundation Load Balancer does, so the services behave the way operators expect after cutover. Pick the Foundation Load Balancer when the workloads are simple L4, the team wants the smallest footprint, and there is no existing L7 policy to honour. The pick to avoid is assuming you can export NSX-T load balancer configuration and import it into either target. There is no such import. You re-express the intent, virtual server by virtual server, whichever engine you land on.

Design the VPC before you migrate a namespace

My recommendation out of this assessment is one sentence long. Treat networking as a fresh design keyed off the mapping table, not a lift of your NSX-T topology, and lock the VPC address plan before the Supervisor comes up. Every row on that table is a rebuild, the shared hypervisor is the only thing the two models have in common, and the one failure that will bite you hardest is an address overlap you could have designed out in an afternoon.

Avoid the reflex that got the architect in my opening question stuck, treating shared NSX as shared configuration. It is not. NCP programmed NSX-T on TKGI terms and the VPC programs itself on VKS terms, and the moment you try to reconcile them you are debugging asymmetric routing instead of running a migration.

Next part moves from networking to storage, where persistent volumes and StorageClass names hide a remap that looks like a copy. Bring the address plan, because storage and networking get designed against the same target namespaces.

References

• Broadcom TechDocs, Supervisor Architecture with VCF Networking with VPC, VCF 9
• Broadcom TechDocs, Customizing Pod Networks NSX Only, TKGI 1.18
• VMware Cloud Foundation Blog, Architecting VKS on VCF, Field Questions Answered

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