VMware's Project Pacific aims to add Kubernetes functionality to vSphere, a move that will create greater support for cloud-native applications and enable more cohesive management.
VMware aims to add Kubernetes support to vSphere via its Project Pacific initiative. Project Pacific is not a product that VMware intends to sell, but instead it's a feature -- although VMware will likely make it the cornerstone feature of the next major vSphere release.
Kubernetes is a scheduler most often used to deploy Docker containers for running applications. It helps developers deploy, run and operate containerized applications in production environments. Docker is a software development enabler that makes software packaging and deployment easier. Project Pacific is part of VMware's pivot from legacy application support to cloud-native application support.
In the past, VMware focused on enabling applications to run on VMs without requiring organizations to change those applications. Now, the vendor must enable a new generation of applications -- ones built and managed via cloud technology -- to run on its product line. Project Pacific represents one element of this transition.
How vSphere and Kubernetes are related
With Project Pacific, VMware hopes to enable two very different management interfaces to manage the same infrastructure. VMware has never added support for an outside interface before, which is part of what makes Project Pacific a big deal.
Most IT infrastructure teams are familiar with vSphere. DevOps practitioners and developers are more familiar with the new Kubernetes interface. Project Pacific aims to enable admins and developers to manage both containers and VMs through either interface. Administrative and development teams can then use vSphere to manage applications and infrastructure without changing their interfaces or management paradigms.
With Project Pacific, VMware hopes to enable two very different management interfaces to manage the same infrastructure.
As Kubernetes proliferates as an application platform, having application and infrastructure teams speak the same management language will be quite an advantage for organizations.
VSphere Integrated Containers
Project Pacific isn't the first initiative to create a container platform from VMware. VMware developed vSphere Integrated Containers (VICs) to enable Docker commands to run on a vSphere cluster so that admins could create containers as VMs.
The vendor engineered an efficient method to instantly start containers as new VMs, rather than having multiple containers run on top of the same VM. Isolation is essential to enterprise customers who might have hundreds of applications -- more applications than physical servers -- running in containers, and who need to keep those applications apart. VIC created strongly isolated containers that act as native objects on vSphere.
With VICs, businesses can use containers alongside VMs for more lightweight applications. Using the same abstraction for both tools -- as Project Pacific aims to do -- creates a unified management that appeals to such organizations.
Kubernetes for VMs
Kubernetes is usually seen as a scheduler for containers; however, it can also act as a scheduler for other types of execution. VMware might deliver full VMs through a Kubernetes API using a Kubernetes feature called Custom Resource Definition (CRD), which enables an admin or developer to add VMs to a collection of containers. This could be important for applications that use components that don't suit container deployment, such as databases and file shares.
Project Pacific enables the same Kubernetes manifest that defines containers for an application to also define the VMs that application uses. For example, one Project Pacific Kubernetes manifest might deploy a group of stateless containers as a web service with a shared file system from a VM cluster. The manifest might also define vSphere or NSX networks and virtual appliances as a load balancer. This Kubernetes manifest becomes the definition of application deployment during development, as well as through testing, staging and production phases.
Nonstandard vs. standard Kubernetes
Part of what makes Kubernetes so valuable is that developers can use the same manifest on any Kubernetes platform. Whether you develop a Kubernetes manifest on premises or on a public cloud provider, the deployed application behaves the same. The only issue is that you can only deploy a nonstandard manifest that uses a CRD -- such as the VM definition from Project Pacific -- on a Kubernetes platform that provides the API in the CRD.
As soon as you start using VMs through Project Pacific, your manifest only works with Project Pacific. This lock-in isn't necessarily bad if your application only requires an infrastructure you own and control. It only becomes a problem when it prevents application mobility, and that mobility is a significant reason that so many vendors offer standard Kubernetes instead of nonstandard.
Dig Deeper on VMware updates, certifications and training
