Introduction

Networking is one of the earliest design decisions for VMware vSphere Kubernetes Service (VKS). The selected Supervisor topology influences isolation, routing, address consumption, load balancing, policy, and operational ownership. VMware NSX Virtual Private Cloud (VPC), NSX Segment, and vSphere Distributed Switch (VDS) approaches should be evaluated against requirements and exact version support, not chosen by name alone.

Architecture Overview

A VKS platform needs connectivity for management, Supervisor control-plane endpoints, VKS nodes, Pods, Kubernetes Services, ingress, egress, registries, Domain Name System, time sources, identity providers, and storage or backup endpoints. The network design decides where these address domains live and which component routes or protects each path.

NSX-based designs can provide software-defined routing, segmentation, and policy capabilities. A VDS-based design uses vSphere distributed switching with supported external network and load-balancing dependencies. Exact features and combinations vary by VCF release, so the final topology must be checked against official compatibility documentation.

Core Components

Component Explanation

  • NSX VPC: Provides a tenant-oriented network boundary with supported connectivity and isolation constructs.
  • NSX Segment: Supplies logical Layer 2 connectivity as part of an NSX design.
  • VDS: Provides distributed switching across vSphere hosts and relies on the surrounding network for routed services.
  • Node networks: Connect VKS control-plane and worker virtual machines.
  • Pod and Service networks: Carry Kubernetes workload and virtual-service addresses according to the CNI design.
  • Load balancer: Presents reachable virtual addresses for supported platform or workload services.
  • Ingress and egress paths: Control traffic entering or leaving workloads.

How Components Work Together

The Supervisor network configuration establishes platform reachability and makes network capabilities available to vSphere Namespaces. When a VKS cluster is provisioned, its nodes receive connectivity and the selected Container Network Interface (CNI) configures Pod networking. Kubernetes Services and ingress resources then depend on the available service and load-balancing architecture.

Network topology and runtime traffic behavior are related but distinct. This article focuses on topology selection and address planning; detailed CNI, ingress, egress, and service-mesh traffic paths belong to the next article.

Design Considerations

Document every address pool, prefix, route, firewall boundary, Maximum Transmission Unit (MTU), and ownership domain. Pools must not overlap with each other or with reachable enterprise networks. Size them for initial deployment, scaling, upgrades, and node replacement.

Choose a topology based on isolation, policy, automation, existing operations, and supported availability requirements. Also determine where load balancer virtual addresses are allocated and advertised, how external clients reach them, and how return traffic is routed.

Best Practices

  • Validate topology support for the exact VCF, vSphere Supervisor, NSX, and VKS versions.
  • Build an address-consumption model with growth and maintenance headroom.
  • Verify Domain Name System, Network Time Protocol, registry, identity, and API reachability from the correct source networks.
  • Keep MTU consistent across encapsulated and physical paths.
  • Define routing and firewall ownership before implementation.
  • Test failure and maintenance paths, not only steady-state connectivity.

Common Mistakes

  • Reusing overlapping Pod, Service, node, or enterprise address ranges
  • Sizing pools only for day-one nodes
  • Assuming a load balancer automatically makes a service routable from every client network
  • Ignoring return routes and firewall state
  • Mixing topology selection with application ingress design
  • Choosing NSX or VDS without checking the operational and feature implications of the exact release

Certification Relevance

The 3V0-24.25 scope includes NSX VPC, NSX Segments, VDS networking, load balancing, ingress, egress, and CNI integration. Source-based preparation should include drawing each address domain and explaining the handoff between physical networking, vSphere networking, Supervisor networking, and Kubernetes networking.

Conclusion

VKS network planning is a dependency design exercise. A successful topology provides sufficient non-overlapping addressing, predictable routing, appropriate isolation, reachable load-balancer services, and clear ownership. Once those foundations are established, runtime workload traffic can be analyzed without confusing platform topology with Kubernetes behavior.