When deploying Kubernetes on VMware Cloud Foundation, it’s important to understand that VMware vSphere Kubernetes Service (VKS) and VMware NSX have different roles.
VKS provides the Kubernetes platform where applications run. NSX provides much of the networking and security infrastructure that connects those applications to each other, to the rest of the VMware environment, and to external networks.
A useful way to visualize the relationship is:
Users / External Networks
|
v
+------------------+
| Avi Load |
| Balancer |
+--------+---------+
|
v
+------------------+
| NSX |
| Networking |
| Security |
| Routing |
+--------+---------+
|
v
+------------------+
| VKS |
| Kubernetes |
| |
| Pods / Services |
+------------------+The key idea is simple:
VKS runs the workloads. NSX provides the networking and security foundation around those workloads.
VKS and NSX have different jobs
It’s easy to think of VKS and NSX as competing technologies because both are involved in networking Kubernetes applications. In reality, they operate at different layers.
VKS provides the Kubernetes environment and manages things such as:
- Kubernetes control planes
- Worker nodes
- Pods
- Deployments
- Services
- Kubernetes APIs
- Workload lifecycle
NSX provides infrastructure capabilities such as:
- Network connectivity
- Routing
- Network segmentation
- Security
- Distributed firewalling
- Network services
- Integration with the broader VMware network
This separation allows application teams to work with standard Kubernetes APIs while infrastructure teams manage the underlying network and security environment.
Pod networking
One of the fundamental requirements of Kubernetes is a network that allows Pods to communicate.
A Kubernetes application might have multiple Pods distributed across several worker nodes:
VKS Cluster
Worker Node 1 Worker Node 2
+-----------+ +-----------+
| | | |
| Pod A | | Pod B |
| | | |
+-----+-----+ +-----+-----+
| |
+---------- NSX -----------+NSX provides the underlying networking architecture that allows these workloads to communicate and participate in the broader VMware network.
This is particularly useful in enterprise environments where Kubernetes applications need to communicate with existing virtual machines, databases, services, and external networks.
Connecting Kubernetes to the rest of the environment
Kubernetes applications rarely operate in isolation.
An application running in VKS might need to communicate with:
- A database running on a VM
- An Active Directory service
- An external API
- Another application
- A legacy application
- The Internet
- Another Kubernetes cluster
The network therefore needs to connect Kubernetes workloads with the rest of the enterprise environment.
Conceptually:
NSX
|
+-----------+-----------+
| | |
v v v
VKS VMs External
Kubernetes Database ServicesNSX provides the routing and networking infrastructure that makes these connections possible.
This is an important advantage of integrating Kubernetes into the VMware networking stack: Kubernetes doesn’t have to become a completely isolated network environment.
Network segmentation
Another important NSX capability is network segmentation.
Imagine an organization with separate production, development, and test environments:
NSX
|
+--------------+--------------+
| | |
v v v
Production Development Test
| | |
VKS VKS VKSNetwork-level controls can be used to isolate these environments and restrict communication between them.
This is complementary to Kubernetes namespaces.
A namespace provides logical organization and isolation within Kubernetes. NSX operates at the infrastructure networking and security layer.
This distinction is important in enterprise environments because security requirements often extend beyond the Kubernetes cluster itself.
Distributed firewalling
NSX also provides distributed firewall capabilities.
Traditional network security often relies heavily on perimeter firewalls:
Internet
|
Firewall
|
Internal Network
|
ApplicationsA distributed security model can enforce controls much closer to workloads:
Application A
|
Security
|
Application B
|
Security
|
DatabaseThis allows organizations to implement policies such as:
Web → Application ALLOW
Application → Database ALLOW
Web → Database DENY
Development → Production DENYThe exact policy model depends on the NSX and VKS architecture, but the underlying principle is the same: security can be enforced closer to workloads instead of relying solely on network perimeter controls.
Routing
Kubernetes also needs to communicate with networks outside the cluster.
NSX provides the routing infrastructure that connects Kubernetes networks with the broader environment.
A simplified NSX topology might look like:
External Network
|
|
NSX Tier-0
|
NSX Tier-1
|
VKS
|
Kubernetes PodsThe exact architecture depends on the VMware Cloud Foundation deployment, but NSX provides the underlying network connectivity required to integrate Kubernetes into the enterprise network.
Load balancing and Avi
Load balancing introduces another component into the architecture: Avi Load Balancer.
Avi and NSX are complementary.
A simplified traffic flow looks like:
External Client
|
v
Avi Load Balancer
|
v
NSX
|
v
VKS / Kubernetes Service
|
+--+--+
| |
Pod PodAvi focuses on application delivery and load balancing.
NSX provides the networking and security infrastructure.
Kubernetes defines the application and its Services.
This separation of responsibilities allows each layer to perform the function it is designed for.
Kubernetes networking and NSX security
Kubernetes also has its own networking and security concepts.
For example, Kubernetes supports NetworkPolicy resources that can control communication between Pods.
This means an application could have security controls at multiple layers:
Application
|
v
Kubernetes NetworkPolicy
|
v
NSX Network Security
|
v
Enterprise NetworkThis layered approach can be useful for organizations with strong security and compliance requirements.
Kubernetes policies can describe application-level communication requirements, while NSX can provide infrastructure-level networking and security controls.
IP addressing and network infrastructure
Kubernetes workloads need IP addresses, networks, and routing.
In a VKS environment, the underlying VMware networking architecture can provide the network segments and IP infrastructure required by the Kubernetes environment.
A conceptual deployment might look like:
Production VKS
Pod Network: 10.20.0.0/16
Node Network: 10.30.0.0/24
Service Network: 10.40.0.0/16These are examples only; actual network ranges and allocation mechanisms depend on the deployment.
The important point is that Kubernetes networking can be integrated into the organization’s existing network architecture rather than managed as an entirely independent environment.
Why the integration matters
The biggest benefit of VKS and NSX isn’t any individual feature.
It’s the fact that Kubernetes becomes a first-class workload within the VMware networking and security architecture.
Without this integration, an organization might end up with two separate environments:
VMware Environment
|
+-- VM networking
+-- VM security
Kubernetes Environment
|
+-- Separate CNI
+-- Separate networking
+-- Separate securityWith VKS and NSX, the architecture can instead look like:
VMware Cloud Foundation
|
NSX
|
+-----------+-----------+
| |
v v
VKS vSphere VMs
| |
+-----------+-----------+
|
Enterprise
NetworkFor organizations already operating VMware infrastructure, this can simplify the operational model considerably.
The networking team can continue using the VMware networking and security platform, while application teams use standard Kubernetes tools.
Putting the pieces together
The complete application traffic flow can be thought of as:
User
|
v
Avi Load Balancer
|
v
NSX
|
v
VKS / Kubernetes
|
Kubernetes Service
|
+------+------+
| |
v v
Pod Pod
|
v
NSX
|
+---------+---------+
| |
v v
Database External APIEach component has a distinct role:
| Component | Primary responsibility |
|---|---|
| VKS | Provides the Kubernetes environment |
| Kubernetes | Manages Pods, Services, Deployments, and workloads |
| NSX | Provides networking, routing, segmentation, and security |
| Avi Load Balancer | Provides application load balancing and application delivery |
| VCF | Provides the broader private-cloud infrastructure platform |
The key takeaway
The easiest way to understand the VKS and NSX relationship is to think in layers.
VKS provides the Kubernetes platform.
Kubernetes manages the applications.
NSX provides the network and security foundation.
Avi provides application load balancing and delivery.
Together, these components allow Kubernetes workloads to operate as an integrated part of the VMware Cloud Foundation environment.
For organizations already invested in VMware, this integration is one of the more significant advantages of VKS: Kubernetes doesn’t have to become a separate networking and security island. Instead, containerized applications can use the same broader infrastructure architecture that supports the organization’s existing workloads.
