Running Kubernetes on vSphere: An On-Prem Guide

Running a Kubernetes fleet on vSphere is not simply a cloud deployment moved behind the firewall. Platform teams have to coordinate cluster lifecycle, VM templates, storage policies, networking, and the operational needs of existing virtual workloads. That complexity becomes more consequential when clusters serve regulated environments or must operate without a dependable connection to external services.

Start a free sandbox trial of Plural and explore a single operating model for your on-prem Kubernetes fleet before you commit to a provisioning path.

Kubernetes on vSphere is a first-class, production-grade option for on-prem and air-gapped platform teams. So long as the underlying design covers cluster provisioning, persistent storage, network controls, upgrades, and day-2 operations. It lets organizations extend their existing virtualization investment while applying Kubernetes APIs and automation to application delivery.

The right approach depends on how much of the control plane and node lifecycle your team wants to manage. As well as how consistently you need to operate across clusters. Start by understanding why vSphere remains a practical foundation for platform teams, then evaluate the deployment and operating choices that fit your environment.

Why Platform Teams Run Kubernetes on vSphere

For many enterprise platform teams, moving every workload to a cloud-managed Kubernetes service is not a simple modernization step. Existing virtualization operations, compliance requirements, application dependencies, and investments in datacenter capacity still matter. Running Kubernetes on vSphere provides a way to adopt the Kubernetes API without discarding the operational model that already supports the business. That separation matters when you are also managing a multi-tenancy strategy across clusters, because the same virtualization estate can host several isolated platforms without a second infrastructure layer.

Coexistence with VMs and existing infrastructure

The clearest advantage is operational continuity. Infrastructure administrators can keep using familiar vSphere interfaces, policies, and workflows, while developers consume standard declarative Kubernetes APIs for deploying and managing applications. That separation lets each team work in the abstraction it understands without creating a second, disconnected infrastructure platform. The underlying model is documented by VMware in its overview of Kubernetes services on vSphere.

Containers also fit naturally beside existing virtual machines. They provide many of the isolation benefits of VMs without the same time and space overhead, which makes them useful for application workloads that need fast, repeatable scheduling. The container virtualization model explains why that distinction matters: containers virtualize at the operating-system level rather than booting a complete guest operating system for every workload.

For organizations with established VMware estates, this coexistence can preserve familiar redundancy, resilience, and performance characteristics while potentially lowering the cost of running containerized workloads alongside VMs. That does not eliminate capacity planning or failure-domain design, but it avoids treating Kubernetes as a reason to rebuild the entire platform from scratch. VMware's vSphere Kubernetes service comparison describes the administrator and developer experience behind this model.

Speed to a first cluster

Time to value is another practical consideration. A Kubernetes cluster on vSphere can be running in less than two hours, according to the implementation guidance captured in the research for this article. That is fast enough to support a focused platform pilot without committing the team to a long infrastructure program.

The first cluster is only the starting point. Teams still need to establish storage, networking, identity, upgrades, and workload policies before production use. But starting with the existing virtualization foundation can shorten the path from an approved design to a working environment. Especially when the team already has vSphere skills and operational controls in place.

Can Kubernetes Run on VMware vSphere Infrastructure?

Yes. The right deployment model depends on how much of the control plane your platform team wants to own. VMware vSphere Kubernetes Service (VKS), formerly delivered through the vSphere with Tanzu experience, integrates Kubernetes directly with vSphere. A Supervisor Cluster provides the native vSphere control plane, and vSphere Native Pods can run directly on ESXi with isolation comparable to virtual machines. VMware reports that these pods can achieve up to 8% better performance than pods on a bare-metal Linux node. In part because the ESXi scheduler localizes memory access within NUMA domains. VMware's performance analysis explains the implementation details.

Tanzu Kubernetes Grid (TKG) is the more portable Tanzu distribution. It is a useful fit when Kubernetes clusters need to run across vSphere and other infrastructure, while still following Tanzu's operational conventions. Rancher with RKE2 takes a different approach: Rancher provisions and manages self-operated clusters through the vSphere API. That model requires connectivity to vCenter on port 443. Plus SSH on port 22 and the Docker API on port 2376 for the created VMs, as documented in the Rancher vSphere provisioning guide.

Finally, kubeadm with the vSphere cloud provider gives teams maximum control. It also leaves you responsible for node images, control-plane lifecycle, upgrades, storage integration, and failure recovery. That flexibility is valuable for specialized environments, but it increases the day-2 burden.

Deployment options for running Kubernetes on vSphere:

A managed control plane is usually the pragmatic choice when the team wants vSphere integration without turning every cluster upgrade or recovery procedure into bespoke engineering. Native vSphere workflows can get a cluster running in less than a couple of hours, according to the cited VMware ecosystem guidance. Choose TKG, Rancher, or kubeadm when portability, existing platform standards, or deep customization outweigh the value of tighter vSphere integration.

If you standardize node provisioning itself, Cluster API automation can give you declarative, repeatable cluster lifecycle on vSphere regardless of the distribution you pick.

See Plural pricing and plans to find the tier that matches your fleet size.

How Do You Handle Storage and Networking on vSphere?

Storage and networking determine whether a cluster remains predictable after the first deployment. In vSphere environments, Kubernetes should not treat datastores and virtual networks as opaque infrastructure. The vSphere Container Storage Interface (CSI) driver dynamically provisions PersistentVolumes on vSphere datastores. Kubernetes requests storage through a StorageClass, and the driver creates the underlying virtual disk based on the storage policy you attach. For stateful workloads and databases, capacity and volume management become a major part of controlling fleet cost.

Choose the volume type based on the workload rather than defaulting to the largest datastore. Block volumes are a common fit for databases and other applications that need exclusive disk semantics. File volumes are useful when many pods must share the same data with consistent concurrent access. The right default is one StorageClass that matches typical workloads, with additional classes reserved for performance or capacity-sensitive cases.

Networking has a similar separation of concerns. The CNI handles pod connectivity and network policy, but the vSphere virtual switch or NSX-T provides the virtual network foundation. Calico and Cilium are common CNI choices on vSphere. Each offers policy and observability features, and the correct pick depends on your existing firewall rules, performance requirements, and the network operations model your team already supports.

Choosing your Service load balancer

On-premises clusters do not receive a cloud provider load balancer automatically. A Kubernetes Service of type LoadBalancer therefore needs an implementation that owns address allocation and advertises routes to the physical network. Common options include:

MetalLB: A lightweight option that supports Layer 2 announcements or BGP. It works well when the network team can reserve an address pool and define the required routing behavior.

NSX Advanced Load Balancer: A full-featured option that integrates with NSX-T and provides advanced traffic management, including multiprotocol load balancing and application-layer insight.

HAProxy: A mature entry point that can front Services with widely understood configuration, useful when the operations team already runs HAProxy elsewhere.

What Are the Best VM Template and Node Provisioning Strategies?

Provisioning is where a vSphere Kubernetes design becomes repeatable, or becomes a collection of one-off fixes. Treat the node image, placement rules, and network access as versioned infrastructure rather than as settings an operator applies by hand.

Treat node images like immutable artifacts

Build a golden image. Start with a supported operating system and the exact container runtime, kubelet, kubeadm, storage components, and monitoring agents required by the cluster version. Use cloud-init to apply the remaining node configuration at first boot, then freeze the result as a VM template.

Version and refresh the template in a pipeline. Do not hand-edit a template on each node. Push new node image versions through the same CI/CD flow you use for application releases, then roll them out with a controlled node-replacement strategy. This keeps the fleet reproducible and reduces drift across clusters.

Separate node roles and placement. Reserve dedicated vSphere resource pools, folders, and affinity rules for control-plane and worker nodes, and align failure domains with datastores rather than spreading workloads blindly.

Open only the paths provisioning requires. Restrict outbound and inbound traffic to the registry, image store, and API endpoints the node actually needs. And document those rules so air-gapped environments have a repeatable network cutover.

What Does It Take to Operate Kubernetes on vSphere at Production Scale?

Once clusters are running, the hard work moves from provisioning to day-2 operations. A production fleet needs a repeatable way to coordinate Kubernetes versions, node images, controllers, infrastructure dependencies, and approvals across environments. That operating model matters even more when the fleet spans 10 or more clusters, where upgrade complexity is often the primary operational struggle.

Automating the hardest part: cluster upgrades

Upgrades are not a single version change. Before touching a cluster, platform teams need to confirm Kubernetes and node-image compatibility. Map controller versions, check CSI and CNI support, validate workload feature gates, and stage the changes across environments in a defined order.

The safest process treats upgrades as controlled changes. Define the desired version in Git, validate the matrix, apply the change to a lower-risk cluster, and promote it through approval gates. Keep the previous node image and configuration available so the team can restore a known-good state if health checks fail. In a typical enterprise, safely upgrading Kubernetes can take months. Plural has reduced that cycle from three months to one day by automating the upgrade workflow and coordinating changes across the fleet.

Plural provides a single-pane-of-glass dashboard for multi-cluster operations, while GitOps continuous deployment automation keeps the desired state reviewable and repeatable. Approval gates let platform teams preserve change control without turning every upgrade into a manual runbook. For vSphere environments, Plural Stacks can manage Terraform, Pulumi, or Ansible workflows that provision and update the underlying infrastructure alongside the Kubernetes configuration.

Coordinating versions and approvals across a fleet is exactly the problem a unified fleet-management control plane is designed to solve.

Security and Air-Gapped Operations for Your vSphere Fleet

Security for a vSphere-based Kubernetes fleet starts with the access model, not the perimeter. The National Institute of Standards and Technology describes zero trust architecture as a way to provide security despite an assumed-breach environment. So every request is treated as if it originates from an untrusted network. NIST zero trust architecture guidance is the reference for that model.

Apply the same discipline inside vSphere. Encrypt sensitive virtual machines and their storage, enable encrypted vMotion where supported by your environment, and separate management, storage, and workload traffic with explicit network policies. Use least-privilege RBAC in vCenter, Kubernetes, and the systems that provision both. Centralized logging and regular access reviews then give operators a way to verify that the controls work across clusters instead of treating each cluster as an exception. For a deeper look at pod-level controls, see Plural's guide to Kubernetes pod security standards.

This matters most in financial services, healthcare, and government or defense, where compliance and data sovereignty can require a self-hosted platform. In those environments, a managed service that needs central credential storage or continuous inbound access becomes a compliance risk rather than a convenience.

Why an agent-based pull architecture suits air-gapped vSphere

A self-hosted, agent-based pull architecture changes the trust boundary. Agents inside the environment retrieve approved configuration and workloads, so the control plane does not need to store central credentials or accept inbound access to every cluster. With the right private registries, artifact mirroring, and update process, the same pattern can operate fully air-gapped while preserving GitOps-based change control. Our agent-based Kubernetes security guide walks through this model in detail.

Plural is an AI-native, architecture-agnostic fleet-management platform that supports on-premises vSphere without requiring a different operating model for those clusters. Its self-hosted control plane and pull-based design fit regulated environments, while its Kubernetes management and automation provide a consistent view across vSphere and cloud infrastructure. The result is not a security shortcut or a separate vSphere silo. It is one policy and operations model adapted to the network and compliance constraints each fleet must meet.

Try Plural's self-hosted control plane and see how it keeps your vSphere clusters compliant without central credential storage.

Frequently Asked Questions

Can Kubernetes run on VMware vSphere?

Yes. You can run Kubernetes on vSphere using integrated options such as a supervisor cluster, or deploy a distribution such as TKG, RKE2, or kubeadm on virtual machines. The right choice depends on how much control-plane ownership and custom automation your platform team wants.

How do you set up Kubernetes on vSphere?

Start by choosing the cluster model, then provision the required control-plane and worker nodes. Configure networking and storage, and establish the identity, image, and firewall policies your environment requires before running production workloads.

What is the difference between TKG and vSphere with Tanzu?

vSphere with Tanzu provides an integrated Kubernetes control plane within vSphere, with vSphere administrators managing infrastructure through familiar interfaces. Tanzu Kubernetes Grid is a Kubernetes distribution that runs on top of vSphere and other infrastructure, giving platform teams more portability at the cost of some native integration.

Is Kubernetes on vSphere suitable for production?

Yes, provided the platform team designs for production operations rather than treating VM provisioning as the finish line. Validate capacity, availability, storage behavior, network failure modes, upgrades, and security controls before promoting workloads.

How does storage work with Kubernetes on vSphere?

The vSphere CSI driver connects Kubernetes persistent volumes to vSphere datastores and can dynamically provision storage from configured storage policies. Define classes for workload needs such as performance, capacity, and replication, and pin stateful workloads to the right class.

Ready to simplify your vSphere Kubernetes fleet?

Start a free sandbox trial of Plural and see how a self-hosted control plane unifies provisioning, upgrades, and day-2 operations across your vSphere clusters.