VMware and Kubernetes Integrations: vSphere, VIC, and the Path Forward

This article is based on analysis originally published at techtarget.com in August 2019. Some product names, roadmap details, and integration statuses may have changed since then.

Why VMware Needed a Kubernetes Strategy

The rapid adoption of containers created an existential challenge for VMware. If developers shifted workloads from virtual machines to containers, demand for vSphere — VMware’s core hypervisor platform — could erode. Kubernetes emerged as the de-facto standard for container orchestration, making it the natural integration target for any infrastructure vendor that wanted to stay relevant.

VMware had already made early container bets, most notably with its Photon platform. When that effort did not gain sufficient traction, VMware pivoted to vSphere Integrated Containers (VIC) and co-developed Pivotal Container Service (PKS) in partnership with Pivotal. The question in 2019 was how deeply — and in what form — VMware would weave Kubernetes into its existing product stack.

vSphere Integrated Containers (VIC): Containers with VM Isolation

VIC is VMware’s approach to running Docker-compatible containers without abandoning the vSphere security and isolation model. Rather than placing containers inside a shared Linux kernel, VIC runs each container as a lightweight VM, using rapid VM cloning to keep instantiation fast.

Key architectural characteristics of VIC include:

• VM-level isolation per container: Each container gets its own kernel boundary, reducing the blast radius of a compromised container compared with shared-kernel runtimes.
• vSphere cluster as a single Docker host: VIC abstracts an entire vSphere cluster so that Docker clients see one logical host, while vSphere HA and the Distributed Resource Scheduler (DRS) handle availability and workload placement underneath.
• Familiar operational tooling: Operators already skilled in vSphere can manage container workloads without learning an entirely new stack.

The limitation that analysts pointed to in 2019 was that VIC did not natively expose a Kubernetes API. Adding a Kubernetes control plane on top of VIC would give teams a familiar orchestration interface while preserving the VM-isolation benefits underneath — but that integration had not been announced at the time of writing.

Kubernetes and vCenter: Overlapping Concerns, Different Philosophies

Kubernetes and vCenter both schedule and manage compute resources, but they reflect fundamentally different assumptions about workload identity:

• vCenter treats each VM as a unique, named entity with its own configuration, storage, and network identity. Operators track individual VMs through their lifecycle.
• Kubernetes treats pods as ephemeral and interchangeable members of a declared desired state. If a pod dies, the scheduler replaces it rather than restoring it.

Despite this philosophical gap, the two platforms are not incompatible. Kubernetes has extension points that make vSphere integration technically feasible:

• StatefulSets: Kubernetes StatefulSets give pods stable network identities and persistent storage across rescheduling events, narrowing the operational gap with vCenter-managed VMs.
• Storage plugins (CSI): The Container Storage Interface allows storage providers, including VMware’s vSAN and external arrays managed through vCenter, to expose persistent volumes to Kubernetes pods.
• Networking plugins (CNI): The Container Network Interface means that VMware’s native vSphere networking and its NSX-T software-defined networking platform could, in principle, serve as the data-plane for Kubernetes clusters.

Contributing upstream to the Kubernetes project — for example, by maintaining a vSphere cloud provider or CSI driver — would let VMware influence how Kubernetes interacts with vSphere infrastructure without requiring a monolithic proprietary integration.

Pivotal Container Service (PKS): Enterprise Kubernetes on vSphere

PKS (co-developed by VMware and Pivotal) took a different approach than VIC. Rather than making containers look like VMs, PKS provisioned fully managed Kubernetes clusters on top of vSphere infrastructure, using BOSH as the cluster lifecycle manager. This gave enterprise teams on-demand Kubernetes clusters with day-two operations (upgrades, scaling, health monitoring) handled by the platform.

In 2019, VIC and PKS existed as parallel products with limited integration between them. The two addressed different use cases — VIC preserved vSphere-centric operations, while PKS offered a Kubernetes-native experience for development teams. The open question was whether VMware would bridge the two, for example by allowing PKS-managed Kubernetes clusters to schedule workloads onto VIC endpoints.

Integration Paths VMware Could Pursue

Several integration strategies were plausible at the time:

1. Kubernetes API layer over VIC: Expose a Kubernetes-compatible control plane that schedules workloads onto VIC’s VM-backed container endpoints, giving developers a standard kubectl interface while operations teams retain vSphere visibility.
2. PKS and VIC convergence: Merge the two container platforms so that PKS-provisioned clusters can optionally use VIC’s VM-isolation runtime instead of a standard container runtime like containerd.
3. Deep vSphere cloud provider for Kubernetes: Invest in upstream Kubernetes integrations — cloud provider, CSI driver, CNI plugin — so that any Kubernetes distribution running on vSphere gets first-class storage and networking support.
4. Kubernetes-aware vCenter UI: Add a Kubernetes management view inside the vSphere Client so that operators can see both VM and container workloads in a single pane of glass.

The Broader Market Context

VMware’s Kubernetes strategy in 2019 was shaped by a competitive landscape that included Red Hat OpenShift, Google Anthos, and the major cloud providers’ managed Kubernetes services (EKS, AKS, GKE). Each of these offered Kubernetes with tightly integrated infrastructure services. VMware’s differentiation was its massive installed base of enterprise vSphere customers who were not ready to migrate entirely to public cloud but still needed a modern container story.

Deepening the connection between vSphere and Kubernetes was therefore not just a product feature — it was a retention strategy for a large segment of the enterprise infrastructure market.

Summary

As of mid-2019, VMware had multiple technically credible paths to integrating Kubernetes with its vSphere ecosystem: layering a Kubernetes API onto VIC, converging VIC and PKS, contributing vSphere-specific plugins upstream to Kubernetes, or extending vCenter’s UI to surface container workloads. None of these paths had been formally announced. The industry was watching VMworld 2019 for signals about which direction VMware would commit to. Regardless of the specific approach, the underlying imperative was clear — any infrastructure vendor with significant VM market share needed a coherent Kubernetes integration story or risk being bypassed by cloud-native development teams.