Modern infrastructure teams rarely move from traditional virtualization to containers in a single phase. Many organizations still rely on VMware for established business applications while adopting Kubernetes to standardize deployment, scaling, and service operations for newer workloads. This mixed model is practical because it allows administrators to modernize without rebuilding the entire platform from scratch.
Kubernetes and VMware integration usually means running Kubernetes control plane and worker nodes as virtual machines (VM) on vSphere, then aligning storage, networking, monitoring, and recovery processes across both layers. OpenShift follows the same underlying idea, although it provides a more opinionated operational framework on top of Kubernetes. In either case, the integration matters because application stability is shaped not only by the cluster itself but also by the condition of the virtual infrastructure underneath it.
In this article, we provide a concise overview of how Kubernetes and VMware fit together, then focus on the operational best practices that help administrators run Kubernetes or OpenShift workloads reliably on VMware-backed infrastructure. Note that this article does not cover all the installation steps for VMware, Kubernetes, or OpenShift.
Summary of key Kubernetes and VMware integration best practices
Best practice | Summary |
Validate infrastructure capacity before deployment | Size hosts, node VMs, and datastores together so that growth and failures do not create resource starvation. |
Separate management and workload traffic | Isolate network paths to improve security, stability, and troubleshooting clarity across both layers. |
Use dedicated storage for Kubernetes workloads | Match StorageClasses and persistence policies to actual datastore behavior and workload needs. |
Monitor cluster resource utilization continuously | Review cluster and VMware signals together so pressure is detected before it becomes an outage. |
Test failover and recovery procedures regularly | Rehearse node, storage, and workload recovery to demonstrate resilience in practice. |
Protect Your OpenShift Virtualization Workloads with Confidence
Protect workloads with storage-agnostic disaster recovery built for OpenShift Virtualization
Achieve near-zero RPO with automated failover and policy-driven recovery
Perform non-disruptive DR testing across hybrid and multi-cloud environments
Kubernetes and VMware integration
Kubernetes provides the orchestration layer through control plane and worker nodes, while VMware provides the virtualized compute, networking, and storage foundation. When Kubernetes runs on VMware, each node is usually deployed as a virtual machine, and components such as the vSphere Cloud Provider Interface (CPI) help Kubernetes communicate with vCenter for tasks such as node initialization and topology-aware labeling. As a result, pod scheduling, failover behavior, and persistence depend on both Kubernetes health and the availability of hosts, datastores, and network paths below the cluster.
Control plane and worker relationship on Kubernetes (source)
Organizations usually integrate Kubernetes with VMware so they can adopt container orchestration without abandoning the virtual infrastructure, operational processes, and in-house VMware skills they already rely on. This approach helps teams modernize application delivery while continuing to use familiar compute, storage, networking, and availability controls within the same environment.
Storage Agnostic Disaster Recovery. Built for OpenShift Virtualization.
Deploying Kubernetes on VMware infrastructure
When Kubernetes runs on top of a VMware infrastructure, the control plane and worker nodes are typically deployed as VMs on vSphere while Kubernetes manages container scheduling and application lifecycles on top of VMware-provided compute, storage, and networking. Because of this, workload performance and resilience depend not only on cluster health but also on the availability of the underlying hosts, datastores, and network paths.
VMware Tanzu integrated with Broadcom VMware’s underlying architecture (source)
At this stage, the goal is not to revisit installation but to confirm that your environment is ready for workloads before you can apply the broader best practices in the next section. This short readiness check helps catch storage, service exposure, and node health issues before any teams rely on them in production.
Readiness area | What to confirm | Useful commands |
Cluster visibility | Nodes are Ready, role placement looks correct, and the cluster baseline is stable before deployment. | kubectl get nodes -o wide oc get nodes -o wide kubectl top nodes |
Storage readiness | The intended StorageClasses exist, PVs and PVCs are binding normally, and workloads are not silently falling back to an unintended default class. | kubectl get storageclass kubectl get pv kubectl get pvc -A |
Service exposure | Services, Ingress objects, and, where applicable, OpenShift Routes reflect how applications are expected to be reached. | kubectl get svc -A kubectl get ingress -A oc get routes -A |
Operational visibility | Events, resource metrics, and OpenShift platform status are available before the first rollout. | kubectl get events -A –sort-by=.lastTimestamp kubectl top pods -A oc get clusteroperators |
Here are a few more readiness checks outside Kubernetes that you should perform:
- Confirm that the VMware datastore or storage policy behind the target StorageClass matches the workload’s performance, resilience, and recovery requirements.
- Confirm that management, workload, and storage traffic follow the intended network design so failures are easier to isolate.
- Confirm that the hosts backing the Kubernetes node VMs have sufficient spare capacity to handle scaling events, maintenance windows, and at least one realistic failure scenario.
Best practices for Kubernetes and VMware integration
The preliminary checks discussed in the last section help you identify existing issues in the environment. Regardless of the results, the following best practices can strengthen Kubernetes and VMware integration across storage, networking, monitoring, and recovery.
Validate infrastructure capacity for Kubernetes on VMware
During capacity planning, apply N+1 logic to worker nodes rather than the control plane, so the cluster can continue scheduling workloads during host maintenance, burst usage, scaling activity, and at least one realistic failure scenario. Control plane placement should be treated differently—these nodes should be distributed across failure boundaries and generally kept in an odd-numbered set, since Kubernetes high-availability guidance notes that odd control plane counts help with leader selection and etcd recommends an odd number of members for quorum. In VMware environments, administrators should also consider DRS VM-VM anti-affinity rules, such as Separate Virtual Machines for control plane VMs, so normal placement activity does not concentrate them on a single ESXi host
This practice becomes even more important in OpenShift-based environments because platform automation still relies on healthy underlying capacity. A cluster that looks acceptable during initial setup can degrade quickly if worker density is too aggressive or datastore headroom is too thin.
Quick validation:
kubectl top nodes
oc adm top nodes
These commands help administrators see whether the cluster is already under resource pressure before new workloads are introduced.
Separate management and workload traffic across Kubernetes and VMware
Network separation should be treated as a stability control, not only as a security preference. Management traffic, pod communication, ingress traffic, and storage traffic can all behave differently under load. When they are collapsed into a single path without clear segmentation, troubleshooting slows, and outages can affect more services at once.
Ingress architecture diagram in Kubernetes (source)
A better approach is to separate these flows with dedicated networks or VLANs wherever practical, then document how applications are published. Load balancers, DNS records, firewall rules, Kubernetes ingress objects, and OpenShift routes should all reflect the same design intent. This reduces ambiguity when an application is reachable internally but not externally, or when storage traffic competes with user traffic during busy periods.
Quick validation:
These commands help administrators see whether the cluster is already under resource pressure before new workloads are introduced.
Separate management and workload traffic across Kubernetes and VMware
Network separation should be treated as a stability control, not only as a security preference. Management traffic, pod communication, ingress traffic, and storage traffic can all behave differently under load. When they are collapsed into a single path without clear segmentation, troubleshooting slows, and outages can affect more services at once.
Ingress architecture diagram in Kubernetes (source)
A better approach is to separate these flows with dedicated networks or VLANs wherever practical, then document how applications are published. Load balancers, DNS records, firewall rules, Kubernetes ingress objects, and OpenShift routes should all reflect the same design intent. This reduces ambiguity when an application is reachable internally but not externally, or when storage traffic competes with user traffic during busy periods.
Quick validation:
kubectl get svc -A
kubectl get ingress -A
oc get routes -A
These commands help verify whether service exposure matches the intended network model.
Align Kubernetes storage policies with VMware datastore capabilities
Persistent workloads should not inherit a generic storage pattern simply because the cluster can automatically provision volumes. Kubernetes abstracts storage well, but the underlying performance still depends on VMware datastores, policies, latency, and recovery capabilities. A database, shared application volume, and lower-priority development workload rarely have the same operational requirements.
For that reason, administrators should map StorageClasses to real performance tiers and protection expectations. This also makes backup and restore planning more realistic, as teams know which workloads depend on which storage behaviors. In environments that use the vSphere CSI driver, this alignment improves provisioning consistency and makes persistence easier to manage at scale.
Quick validation:
kubectl get storageclass
kubectl get pvc -A
oc get storageclass
In OpenShift environments running on vSphere, the thin-csi StorageClass uses the vSphere CSI driver and is subject to its snapshot limits. By default, the driver allows three CSI snapshots per block volume. Administrators can increase this limit to a maximum of 32 through the ClusterCSIDriver resource, although values above three can negatively affect storage performance and should be tested carefully.
For example, the following configuration raises the limit to 10 snapshots:
apiVersion: operator.openshift.io/v1
kind: ClusterCSIDriver
metadata:
name: csi.vsphere.vmware.com
spec:
driverConfig:
driverType: vSphere
vSphere:
globalMaxSnapshotsPerBlockVolume: 10
Apply the configuration:
oc apply -f thin-csi-patch.yaml
This ceiling limits the number of CSI snapshots that can coexist for a PersistentVolume and does not directly define backup retention. Where stronger data protection is required, a backup platform such as Trilio for Kubernetes can transfer snapshot data to NFS or S3-compatible storage, reducing the need to retain every recovery point as an in-place vSphere snapshot.
Monitor Kubernetes and VMware health together
Resource monitoring should not stop at the Kubernetes dashboard. Node and pod metrics are useful, but they do not always indicate whether a slowdown stems from CPU pressure within the cluster, a VM-level bottleneck, a host issue, or a datastore problem. Effective monitoring requires teams to correlate events and trends across both the orchestration and virtual infrastructure layers.
This recommendation is especially important for environments supporting production applications with strict uptime requirements. Continuous monitoring makes it easier to catch early warnings such as rising node pressure, storage latency, repeated restarts, or degraded platform components before users see a visible outage.
Quick validation:
kubectl get events -A --sort-by=.lastTimestamp
kubectl top pods -A
oc get clusteroperators
These commands provide a quick view into warning events, workload pressure, and overall cluster health.
Test failover and recovery across the cluster and infrastructure layers
High-availability features do not eliminate the need for recovery testing. As an administrator, you should know how the environment behaves when a worker node fails, a host becomes unavailable, storage access is interrupted, or an application must be restored from backup. Without rehearsal, resilience exists only as a design assumption.
Now, for this particular best practice, the method varies depending on how your environment is set up. However, if you need a starting point, here are a few ways on how failover and recovery procedures are usually done:
- Node maintenance test: Drain a worker node and confirm that pods reschedule cleanly without unexpected disruption.
- OpenShift remediation test: Verify that unhealthy nodes are replaced or recovered as expected in clusters using automated remediation.
- Stateful recovery test: Restore a workload from a snapshot or backup and confirm data integrity and recovery time.
- Infrastructure failover test: Simulate a VMware host or datastore issue and verify that the cluster behaves within expected recovery limits.
This is also where Trilio can support the integration strategy, since it is designed for application-centric backup and disaster recovery across Kubernetes and OpenShift environments.
Storage Agnostic Disaster Recovery. Built for OpenShift Virtualization.
Final thoughts
Kubernetes and VMware integration works well when organizations treat the two as a single operational system rather than adjacent platforms. A brief understanding of the architecture is important, but stable day-two operations depend more on practical controls such as capacity planning, network separation, storage alignment, monitoring, and recovery testing.
That is also why this topic relates naturally to OpenShift Virtualization. Whether the goal is to keep running Kubernetes on VMware or to move toward a broader platform for virtual machines and containers, the same foundation remains essential: Design the shared infrastructure carefully, validate it continuously, and rehearse recovery before a production incident forces the test.
Where stronger data protection is required, Trilio can complement Kubernetes and VMware integration with application-centric backup and recovery for Kubernetes and OpenShift workloads. This can help administrators standardize restore and disaster recovery processes as the environment scales
To learn more, try out the platform or read more about how Trilio can help you with your Kubernetes backups.
Like This Article?
Subscribe to our LinkedIn Newsletter to receive more educational content