BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Kubernetes Future: VMs, Containers, or Hypervisor?

Kubernetes Future: VMs, Containers, or Hypervisor?

This item in japanese

In competing visions of the future of Kubernetes, Paul Czarkowski, principal technologist at Pivotal, predicts that VMs will replace containers, and Joe Fernandes, a VP at Red Hat, considers that VMs usage is evolving for Kubernetes rather than replacing containers. In addition, Chris Short, Red Hat's principal product marketing manager, said that Kubernetes is close to replacing the hypervisor.

Czarkowski stated that even though containers improve how software is built and deployed, they’re not secure isolated sandboxes like virtual machines. Furthermore, containers were built upon a shared kernel model, providing only basic process isolation. Most components in Kubernetes aren't tenant aware, leading to a soft tenancy model where isolation is at the level of namespaces or pod security policies only, but the API is a shared component:

This leads to the emerging pattern of "many clusters" rather than "one big shared" cluster. It's not uncommon to see customers of Google's GKE Service have dozens of Kubernetes clusters deployed for multiple teams. Often each developer gets their own cluster. This kind of behavior leads to a shocking amount of "Kubesprawl".

To solve the Kubesprawl problem, Czarkowski talked about using micro VMs like Kata Containers, which is "an open source project and community working to build a standard implementation of lightweight VMs that feel and perform like containers, but provide the workload isolation and security advantages of VMs." Instead of having many Kubernetes control planes, the proposal is to use Kata Containers to give each tenant an isolated environment (including the Kubernetes API) with nested VM containers running in a VM from AWS, Azure, GCP or vSphere. Czarkowski represented this deployment in the following diagram:

Source: "The future of Kubernetes is Virtual Machines" by Paul Czarkowski

In the above diagram, two Kubernetes namespaces have been deployed, foo and bar. Each namespace has its own API, system services, and pods. In a future like this where nested VMs enable multi-tenancy clusters, Kubesprawl will be reduced, and the underlying infrastructure can be used to host non-container workloads in the same VM.

In addition, Short said that "one intriguing idea coming very close to the surface is to use Kubernetes as an hypervisor" with tools like KubeVirt and Kata Containers, helping organizations migrate legacy workloads which can’t be containerized. KubeVirt is an add-on for virtual machine management, providing a virtualization solution on top of Kubernetes. KubeVirt allows legacy applications that can’t be easily containerized to use the built-in features from Kubernetes like self-healing, automated rollouts (and rollbacks), horizontal scaling, among others. Short said:

This means a virtual machine could be containerized with little modification. With some already planned work, Kubernetes as an hypervisor will start to change the datacenter and cloud landscapes.

Therefore, both Czarkowski and Short complement each other with their thoughts. Czarkowski says that the future of Kubernetes is going to be VMs with emerging technologies like Firecracker from AWS, and gVisor from Google. And Short says that the future of VMs is Kubernetes with tools like KubeVirt where organizations want to move a legacy app as is to Kubernetes.

For Fernandes, the critical aspect regarding the future isn’t that containers will replace VMs, but how Kubernetes will be used to orchestrate different workloads like traditional VM-based workloads or micro-VMs. Kubernetes will allow organizations to modernize their workloads, and have hybrid operations for containers, VMs, or even bare metal infrastructure. There are going to be organizations that will continue to run workloads in bare-metal infrastructure for performance purposes where they need to benefit from hardware acceleration. Or, also for companies that want to lift-and-shift existing workloads by using VMs, micro VMs, or a mix with the help of tools like KubeVirt and Kata Containers, as mentioned by Short.

And that’s why Fernandes considers that VMs won’t replace containers. Instead, VMs usage is going to continue evolving in the Kubernetes stack. The trend for 2019 is at the intersection of Kubernetes and virtualization with a broader mindset change, where Kubernetes will start to enable to run hybrid workloads with containers and VMs.

Fernandes ends his post complementing Short and Czarkowski’s views by saying that the three key trends for Kubernetes are going to be:

  1. Kubernetes orchestrating micro-VMs to provide stricter multi-tenant isolation for untrusted workloads.
  2. Kubernetes orchestrating and managing traditional VM-based workloads (via KubeVirt) alongside container-based workloads.
  3. Kubernetes clusters increasingly being deployed on bare metal servers, as an alternative to Kubernetes on VM-based environments.

What do you think the future of Kubernetes will be?

Rate this Article

Adoption
Style

BT