Project Pacific is an engineering project to natively embed Kubernetes into vSphere. Pacific is a deep, deep integration of the two technologies, embedding Kubernetes into ESXi to make containers first-class citizens in vSphere. The project gives developers a well-known way to deploy and operate their applications, including creating entire Kubernetes clusters and vSphere resources like virtual machines via the Kubernetes APIs, while operators can continue to leverage the power of vSphere to operate the underlying infrastructure.

Adding Kubernetes to vSphere extends the lifespan of vSphere by combining container and virtual machine workloads in a single platform, allowing organizations to start using containers without much additional knowledge, effort or cost. It gives organization a smooth migration path to containers, and keeps VMware and VMware admins in the driver’s seat of this change.

What if when developers wanted to create a virtual machine, or a container, or a kubernetes cluster, they could just write a kubernetes YAML file and deploy it with kubectl like they do with any other Kubernetes object?

Technical Overview

VMware Project Pacific overview

Supervisor Cluster

Technically, Project Pacific runs a Kubernetes control plane per vSphere clusters; individual ESXi hosts act as Kubernetes worker nodes, running ‘Spherelets’ instead of a Kubelet directly on ESXi. The Kubernetes control plane (called the Supervisor Cluster) is just a feature toggle away, just like HA and DRS.

Native Pods

Containers run on CRX, a specific atomic Linux distribution that runs as a VM for containers to run on. This is called a ‘vSphere Native Pod’. Like VMs, containers are isolated at the hypervisor level; effectively paravirtualizing the container. This increases security, but also performance by up to 8%.

Guest Clusters

VMware Project Pacific Guest Clusters

The Supervisor Kubernetes version is not vanilla upstream Kubernetes. It’s Kubernetes to improve vSphere. For regular, vanilla Kubernetes workloads, Guest Clusters exist. This cluster runs inside virtual machines on the Supervisor Cluster. This is as if you’d build your own Kubernetes cluster, running on VMs, albeit integrated into vSphere from a UI perspective.

3rd Party Integration

Because of the native integration, many 3rd party products that integrate with vSphere APIs work with Kubernetes. This helps transitioning to Kubernetes workloads, leveraging existing investment in monitoring, loging, etc. There’s some more details on Frank Denneman‘s blog, as well as on the VMware CNA and vSphere blogs.

Will Project Pacific help customers transition to containers smoothly?

I applaud any and all initiatives that make Kubernetes easy. Installing and configuring this beast is a task no-one should have to undergo; options to run Kubernetes as a services from the hyperscalers (EKS, AKS, GKE) or the likes of Platform9 should be the de-facto way of consuming Kubernetes. Alternatives include running it as part of your PaaS platform (like with Pivotal). But never should it be done the hard way (apart from learning).

So having Kubernetes embedded into vSphere makes sense. Technically, I’m excited by seeing the Kubernetes control plane integrated into a hypervisor so that Kubernetes users (developers, operators) can natively use vSphere. I’m excited that ESXi can now run containers as single-kernel workloads (I’ve long argued that unikernels make more sense than shared-kernel containerization, a reality that’s finally happening).

But ‘just’ doing Kubernetes does not equal ‘being cloud-native’; meeting the five characteristics of cloud consumption, understanding the concepts of flow (and other LEAN thinking), and being able to do small experiments, incrementally improving are key aspects. Kubernetes is only a small, small fraction of ‘doing DevOps’ right. Not understanding cloud-native technologies will cause organizations to fall further behind.

So I can’t help but wonder what the added value for customers is. I get VMware’s play for relevance, combining current on-prem investments in datacenters with the unstoppable Kubernetes force. And I see some limited value in customers land-locked to using their own (or co-located) datacenters. But for the rest of us, isn’t embracing all that is DevOps, LEAN, Agile much more important than to protect current investments in datacenter technologies?