VMware connections to the Kubernetes market

Supertanker

In-Depth Integration

If you are already a VMware customer and decide to follow VMware's foray into the world of Kubernetes, you can expect in-depth integration in return for hard cash. After all, VMware thrives with customers who have made themselves comfortable in the VMware universe and have few reasons to reconsider their decision. Specifically, this means that anyone wanting to roll out a Kubernetes cluster in their local environment can do so in existing vSphere clusters through Tanzu MC. The containers then run on ESXi hosts, mostly on VMs.

From an administrative point of view, this scheme makes sense. Admins will normally want to manage the complete life cycle of a cluster based on Kubernetes automatically and without manual intervention, which can be done easily with the standard VMware interfaces and the usual tools. By the way, this approach is by no means specific to VMware: People who operate large numbers of Kubernetes clusters occasionally resort to OpenStack because VMs in clouds can be provisioned quickly. In contrast, it takes considerably longer to roll out real metal.

However, this approach also involves considerable overhead in terms of resources. If you run Kubernetes on real VMs, you have the overhead of the VM on the one hand and the container on the other. For years, there has therefore been a desire to run containers on hardware instead of intermediate VMs while retaining the management solutions already known from solutions such as vSphere or OpenStack.

At the end of the day, an ESXi host logically ends up running an agent that starts VMs. If this was converted so that it could instead create containers from scratch, the goal would be achieved. VMware doesn't need to worry about problems like SDN or the central availability of storage, because vSAN and NSX exist – and could simply continue to be used in such a setup.

vSpherelet on Approach

Not surprisingly, an announcement from VMware refers to this very approach. In the future, VMware will provide vSpherelets alongside the classic Kubelets that allow a bare metal node to be used for running Kubernetes containers in vSphere. The overhead described above will therefore be history. VMware is even a little earlier in the game in this respect than Kubernetes itself, which is working on similar approaches, although not specifically tailored to VMware.

A vSpherelet makes the integration of VMware and Kubernetes even tighter, at the price of further vendor lock-in. Once you run Kubernetes in the context of such a setup, there is almost no chance to back out of it.

VMware markets the whole thing under the name Project Pacific (Figure 3). The central goal is to make vSphere a central application platform of the future. Heads up, people: Obviously, VMware is also assuming that in the future far fewer companies will be interested in classic infrastructure as a service (IaaS) and that platform (PaaS) and software as a service (SaaS), for example, will set the pace instead.

Figure 3: Instead of running containers on ESX, Kubernetes will become a peer hypervisor in the VMware universe. VMware is working on this scheme under the code name Project Pacific. © VMware

Open Source Role

Another interesting factor in the context of Tanzu at VMware is the launch of a new GitHub repository [2] parallel to the official Tanzu launch that makes various open source components from Tanzu available under an open license. Thus far, VMware has not exactly been considered an open source pioneer – reason enough to take a closer look at the components on offer. The tools clearly also offer useful functions outside of VMware setups.

Under the name Velero, for example, VMware offers a product that takes care of backing up Kubernetes instances and migrating complete Kubernetes installations. Because virtually all container workloads are virtualized anyway, this kind of migration is not uncommon. For example, if you get a better environment at AWS than at Azure, you might want to move all of your active Kubernetes instances. If you need disaster recovery, you will be interested in the part that copies data from A to B. Velero assumes precisely the role of a general-purpose tool for backups and migration in Kubernetes. VMware even provides a plugin that allows Velero to integrate directly with the backup capabilities of Google's container platform, with plugins for the other vendors expected to follow soon.

Octant (Figure 4), no less practical, allows admins to check the state of an instance of Kubernetes in a graphical console. Octant obviously serves as the foundation for Tanzu MC, because some views are almost identical in Octant. However, nothing can be changed in Octant: Look but don't touch. No problem. Octant quickly provides a better overview than many other tools on the market, and if you are looking for good visualization of your Kubernetes instances, you will want to take a closer look.

Figure 4: Octant, a VMware tool for Kubernetes, supplies admins a quick overview, even across several Kubernetes setups simultaneously. © VMware

Last but not least, do not forget Sonobuoy (Figure 5), which informs the admin about the state of a Kubernetes instance – and not just the mere facts, but metrics, such as the performance of individual services. Sonobuoy collects the data ad hoc on the basis of existing Kubernetes tests to present an overview at the end of the process.

Figure 5: Sonobuoy for Kubernetes: A plugin framework is used to define tests that Sonobuoy then processes. © VMware

All three components presented here communicate exclusively with the Kubernetes API or the API of the cloud provider who operates Kubernetes as a resource, with no need for any VMware products. I recommend that Kubernetes admins take a closer look at these tools.

Infos