VMware VKS Architecture Explained: How Kubernetes Runs on VMware Cloud Foundation

Introduction

Kubernetes does not operate in isolation. Every cluster depends on compute capacity, network connectivity, persistent storage, identity, release content, and operational control. VMware vSphere Kubernetes Service (VKS) connects those Kubernetes requirements to VMware Cloud Foundation (VCF), creating an architecture in which cloud infrastructure and Kubernetes remain distinct layers but work through integrated control points.

This article explains the VMware VKS architecture using VMware Cloud Foundation 9.0 as the baseline. It focuses on how the vSphere Supervisor, vSphere Namespaces, and VKS clusters relate to one another, how desired-state requests move through the platform, and where infrastructure and Kubernetes responsibilities meet. Detailed deployment procedures and topology-specific configuration are outside this architectural scope.

Architecture Overview

At a high level, VKS uses a layered architecture rather than placing application containers directly onto undifferentiated infrastructure. VMware Cloud Foundation supplies the private cloud foundation. The vSphere Supervisor adds a Kubernetes-enabled control layer to vSphere. A vSphere Namespace establishes a governed resource boundary, and a VKS cluster provides the Kubernetes environment in which application workloads run.

The following flow shows the relationship among these layers:

The VMware Cloud Foundation 9.0 modern applications architecture describes the vSphere Supervisor as a consistent, declarative control layer for virtual machines and Kubernetes clusters. This does not collapse every workload into one control plane. Instead, it provides a common infrastructure-facing API while each VKS cluster retains its own Kubernetes API and workload state.

VKS is a conformant Kubernetes runtime. The control plane and worker nodes of a VKS cluster run as virtual machines (VMs) on vSphere. Application Pods are scheduled onto those worker nodes by the Kubernetes scheduler. Conventional VMs can run on the same VCF platform, but they remain separate workloads governed through their applicable vSphere or VM Service model.

Core Components

The architecture becomes clearer when each component is defined by the state it owns and the services it provides.

Component Explanation

VMware Cloud Foundation is the infrastructure and cloud-management foundation. VMware vSphere supplies the virtualization layer and host capacity. VMware NSX or a supported vSphere Distributed Switch (VDS) design supplies network connectivity according to the chosen Supervisor topology. VMware vSAN or other supported vSphere storage provides policy-driven capacity. VCF Operations and VCF Automation can add operational visibility, governance, and self-service above these core services.

The vSphere Supervisor is the platform control layer. It exposes Kubernetes-style APIs and runs controllers that reconcile requested resources with vSphere infrastructure. VMware’s application-modernization overview for VCF 9.0 identifies VKS and VM Service as services exposed through the Supervisor. For VKS, the Supervisor receives cluster declarations, coordinates infrastructure creation, and tracks the state of the resulting cluster resources.

A vSphere Namespace is a resource and policy boundary on the Supervisor. It can carry access permissions, compute limits, available VM classes, vSphere Storage Policies, network configuration, and service entitlements. A VKS cluster is created within this boundary and consumes only the capabilities made available to it. The vSphere Namespace is not the same as a Kubernetes namespace inside the workload cluster.

A VKS cluster is a dedicated Kubernetes environment. Its control plane nodes maintain cluster state and serve the Kubernetes API. Its worker nodes provide the capacity on which application Pods run. These nodes are VMs managed through vSphere, while Kubernetes manages the workloads scheduled inside them. Node pools allow worker capacity to be grouped by characteristics such as size or intended workload role, subject to the supported cluster specification.

A vSphere Kubernetes release (VKr) identifies a supported Kubernetes release and the associated node image content used for a VKS cluster. The release must be available to the Supervisor through the configured content source and compatible with the platform. This release boundary helps prevent a cluster declaration from selecting arbitrary, unvalidated Kubernetes node content.

Platform integration components connect Kubernetes behavior to the underlying infrastructure. A Container Network Interface (CNI) implementation configures Pod networking inside the cluster. The vSphere Container Storage Interface (CSI) Driver connects Kubernetes persistent volume operations to vSphere storage. The Cloud Provider Interface (CPI) supplies the Kubernetes cloud-provider integration needed to associate cluster nodes and infrastructure context with vSphere. Their detailed implementation depends on the supported VKS release and design.

Kubernetes namespaces exist inside a VKS cluster and organize application resources such as Pods, Deployments, Services, Secrets, and ConfigMaps. They are governed by the cluster’s Kubernetes Role-Based Access Control (RBAC) and policy model. This application-level scope remains separate from the infrastructure policies attached to the parent vSphere Namespace.

How Components Work Together

The architecture follows a declarative control pattern. A platform user submits a VKS cluster specification through a supported Kubernetes interface. The specification describes the intended cluster state, including the Kubernetes release, topology, control plane, worker node pools, VM classes, storage, and network-related selections that the environment exposes.

The request is scoped to a vSphere Namespace. Before infrastructure can be created, the request must fit the namespace’s permissions and available policies. This is the first important architectural boundary: the cluster consumer declares a desired Kubernetes environment, but the infrastructure administrator controls the options that can be consumed.

Supervisor controllers observe the requested state and coordinate the vSphere resources needed for the cluster. They obtain compatible node content, create the control plane and worker VMs, connect supported networking, and apply storage and placement requirements. The process is reconciliatory rather than a single one-time script. The Supervisor continues to compare declared and observed infrastructure state and acts when supported lifecycle operations require a change.

After the cluster becomes available, users connect to its Kubernetes API rather than treating the Supervisor API as the application control plane. Kubernetes then schedules Pods onto VKS worker nodes and manages application resources inside the cluster. This creates two related reconciliation domains: the Supervisor manages the infrastructure representation and lifecycle of the VKS cluster, while the cluster’s Kubernetes control plane manages nodes, workloads, and cluster-local services.

Networking and storage cross both domains. The infrastructure layer provides routable networks, load-balancing dependencies, address capacity, storage policies, and datastores. Cluster integrations translate these capabilities into Kubernetes constructs such as node networking, Services, storage classes, persistent volumes, and persistent volume claims. A healthy Kubernetes object therefore may still depend on a correctly configured VCF service outside the cluster.

Operations also span the layers. vCenter Server and VCF tools expose infrastructure health and VM state, while Kubernetes tools expose cluster resources, events, and workload status. Effective monitoring and troubleshooting correlate both views instead of assuming that either one represents the entire system.

Design Considerations

Architecture decisions should begin with workload and service requirements, then map those requirements to supported VCF and VKS capabilities. Capacity planning must include Supervisor overhead, VKS control plane and worker VMs, application demand, growth, and failure scenarios. Cluster node capacity should not be treated as the only compute requirement.

Namespace design determines who can create clusters and which infrastructure choices they can make. Permissions, quotas, VM classes, storage policies, and network access should reflect a clear ownership model. Placing unrelated teams or environments in one broad namespace can weaken resource governance and complicate operational accountability.

Network design must account for management access, Kubernetes API access, node connectivity, Pod and Service address space, ingress, egress, name resolution, and load balancing. Supported options can include VMware NSX constructs such as an NSX Virtual Private Cloud (VPC) or NSX Segment, or a VDS-based design with an appropriate load-balancing solution. The correct choice depends on the required isolation, scale, automation, and supported platform configuration.

Storage design should map application persistence and availability needs to vSphere Storage Policies and supported datastores. Kubernetes storage classes and persistent volume claims express workload consumption, but the underlying performance, resilience, placement, and capacity remain infrastructure responsibilities.

Identity and security must cover both administrative planes. Access to the vSphere Supervisor and vSphere Namespace governs infrastructure consumption; Kubernetes RBAC governs actions inside the VKS cluster. Certificates, registry trust, secrets, and network policy add further boundaries that must be designed consistently rather than assumed to flow automatically from one layer to another.

Best Practices

• Document the ownership boundary for VCF infrastructure, the Supervisor, vSphere Namespaces, VKS clusters, and application namespaces.
• Treat a vSphere Namespace as a deliberate tenancy and policy boundary, not merely a folder for cluster objects.
• Validate network address capacity, routing, load balancing, and name resolution before cluster provisioning.
• Map vSphere Storage Policies to workload availability and performance requirements before exposing them to cluster consumers.
• Use supported vSphere Kubernetes releases and verify compatibility before planning cluster creation or upgrades.
• Monitor infrastructure and Kubernetes signals together so that cross-layer dependencies remain visible.
• Test failure and recovery assumptions for control plane nodes, worker nodes, networking, storage, and external services.
• Match every design decision to current VCF 9.0 and VKS documentation rather than relying on legacy Tanzu terminology or procedures.

Common Mistakes

One common mistake is treating the vSphere Supervisor as the workload cluster. The Supervisor provides the platform control layer; each VKS cluster has its own Kubernetes control plane, worker nodes, API, and application state.

Another is confusing a vSphere Namespace with a Kubernetes namespace. The former controls infrastructure consumption on the Supervisor, while the latter organizes application objects inside a VKS cluster. Applying a policy at one layer does not automatically mean an equivalent policy exists at the other.

It is also incorrect to assume that VKS application Pods run directly on physical hosts without a node layer. VKS control plane and worker nodes are VMs, and application Pods run on the worker nodes. Supervisor Pods and VM Service workloads are separate workload models and should not be used to describe VKS cluster internals.

Teams sometimes design networking and storage after defining the cluster. That reverses the dependency order: cluster creation and workload operation depend on address space, routing, load balancing, storage policies, datastore capacity, and compatible integrations already being available.

A final mistake is troubleshooting from only one interface. Kubernetes events may reveal a failed volume attachment or unavailable node, while vSphere and VCF tools reveal the underlying VM, network, storage, or capacity condition. The architecture requires evidence from both layers.

Certification Relevance

The architecture is foundational to the VMware Certified Advanced Professional vSphere Kubernetes Service (3V0-24.25) knowledge scope. The official exam guide uses VMware Cloud Foundation 9.0 as its baseline and covers Kubernetes architecture, vSphere Supervisor capabilities, vSphere Namespace design, VKS cluster operations, networking, storage, security, lifecycle, and troubleshooting.

The practical value is understanding where a configuration or failure belongs. A learner should be able to distinguish Supervisor state from VKS cluster state, infrastructure policy from Kubernetes policy, and a vSphere Namespace from a Kubernetes namespace. That architectural reasoning supports design and operations work without relying on memorized interface sequences.

Conclusion

VMware VKS architecture separates concerns without separating the platform. VMware Cloud Foundation provides the infrastructure services, the vSphere Supervisor provides the declarative platform control layer, a vSphere Namespace defines the consumption boundary, and a VKS cluster provides the Kubernetes control plane and worker capacity for applications.

Understanding how these components exchange desired state and infrastructure services explains how Kubernetes runs on VCF. It also clarifies why network, storage, identity, lifecycle, and operational decisions must be coordinated across both VMware and Kubernetes control planes. With these boundaries established, deeper design and configuration topics can be evaluated in the correct architectural context.