Admins understand that simply operating containers is not enough. Instead, purpose-designed container orchestration is also necessary, which is where the popular Docker was seen to be lacking. Google's Kubernetes jumped into the breach and developed a busy life of its own far removed from Docker.

For decades, VMware was the industry leader in virtualization, offering a virtualization environment from a single source. VMware vSphere, the server virtualization platform, easily docks with other VMware products and has even jumped on the OpenStack bandwagon with a kind of translation component between the official OpenStack APIs and vSphere in the form of VIO – VMware Integrated OpenStack.

It was strange for VMware to have seemingly been asleep through most of the Kubernetes hype. Ultimately, Kubernetes with its containers in the background – no matter which run time they use – are tantamount to a central attack on the core of VMware's business (i.e., full virtualization and paravirtualization).

Sleeping on the Kubernetes threat is now a thing of the past: Project Tanzu is about to become the VMware toolkit for Kubernetes, claiming to integrate Kubernetes seamlessly with the existing VMware framework.

Some of the tools used in Tanzu are already available under an open source license; further components will follow in the coming months. It's worth taking a closer look. What are VMware's tactics with regard to Kubernetes? What can VMware users expect when it comes to Kubernetes? Where does VMware's love of container orchestration end?

Integration Is Not Easy

Even if it looks to be so at first glance, it is not easy for VMware to integrate Kubernetes and possible additional programs into its own portfolio. After all, Kubernetes (also called K8s) seems to do very well without real virtualizers like VMware or KVM – that's one of the software's core promises.

Additionally, Kubernetes deliberately excluded many concepts that were the downfall of other approaches (e.g., OpenStack). Kubernetes does not even provide for multiclient capability. Instead, it suggests that individual Kubernetes clusters should simply be rolled out for each customer. Although this method leads to some overhead at the Kubernetes level, you need far fewer technologies like software-defined networking (SDN) in the setup to achieve client separation. If VMware wanted to find a gap in this construct for itself, one thing was clear: It wouldn't be easy.

In the search for a way out of the dilemma, VMware came across an approach that many other vendors have already chosen for themselves: If the trend is to run many Kubernetes instances at the same time, then the admin needs a tool that offloads some of the work. Such a tool is now becoming the core of VMware's strategy to penetrate the Kubernetes market.

Project Tanzu

VMware, which now belongs to the Dell EMC Group, presented its strategy for the Tanzu project at its in-house VMworld in San Francisco at the end of August 2019. The company announced several tools that will make it easier for admins to operate Kubernetes while simplifying development in Kubernetes [1].

Tanzu basically comprises three concepts: Tanzu Mission Control allows the efficient management of several Kubernetes clusters, whereas Enterprise PKS and Essential PKS make it possible to roll out the Kubernetes distribution – a VMware acquisition called Pivotal – in private as well as public environments.

Controlling Kubernetes

VMware has made a name for itself over the past decades by always equipping its products with flashy graphical tools that abstract complex technology. Even technically complex processes could be controlled in simple graphical user interfaces (GUIs), and as the icing on the cake, meaningful statistics were also available in the form of charts.

Therefore a graphical tool is part of Tanzu, too: Tanzu Mission Control (Figure 1), which is primarily used to connect different Kubernetes instances at different destinations and control them centrally.

Figure 1: VMware Tanzu Mission Control divides Kubernetes into clusters and currently prefers to address instances in public clouds. © VMware

Basically, Tanzu Mission Control (MC) differentiates between cluster groups and clusters: A cluster is always a Kubernetes instance, and an admin creates groups on the basis of various parameters, such as the type of cluster (i.e., whether it has been rolled out from AWS, is an Azure-Kubernetes cluster, or is a separate on-premises solution). New clusters can also be started from within Tanzu MC, so if you already have active Kubernetes instances, you can integrate them into a new instance of Tanzu, if desired.

Put simply, Tanzu wraps itself around the Kubernetes instances under its control. Tanzu also offers the classic VMware nomenclature for Kubernetes to which admins are accustomed from vSphere. One example is the integration of a comprehensive policy framework, including user administration, that allows specific permissions to be defined down to the level of individual actions.

VMware has always impressed its customers by facilitating compliance and implementing centralized policies, because the ESX hypervisor, vSphere, and other VMware products (e.g., VMware vSAN software-defined storage or NSX software-defined networking) can span all levels of the installation in classic VMware setups and control them accordingly.

However, compliance considerations are not the only elements in Tanzu that VMware is using to fish for customers. A complement to this is a kind of orchestration for Kubernetes instances; admins can centrally store configurations for the container orchestrator in Tanzu. Tanzu then applies the configs to the Kubernetes instances under its control. If Tanzu itself starts a new Kubernetes environment, the same happens there.