Guide for 2019: What to Consider About VMs and Kubernetes
In a rundown of guideposts for the Kubernetes community in 2019, the topic of Kubernetes and the return of virtual machines was discussed. Virtual machines are not replacing containers, but rather, VM usage is evolving across multiple layers of the Kubernetes stack.
In recent years, containers have become synonymous with cloud native application architecture. They have redefined the way we package, distribute, deploy, and manage applications. But containers, as we know them today, are themselves a re-emergence of existing Linux technologies combined in a new and more useable way. While many organizations are migrating VM-based applications to containers, virtualization is still pervasive in both the data center and public cloud. We also see virtualization technology coming together with containers and Kubernetes in new ways, providing innovative solutions to new problem sets. In other words, VMs are becoming part of a cloud native architecture, too — this is container-native virtualization.
The bedrock of Kubernetes remains the orchestration and management of Linux containers, to create a powerful distributed system for deploying applications across a hybrid cloud environment. Kubernetes often runs on top of a VM-based infrastructure, and VM-based workloads, in general, remain a large part of the IT mix. Entering 2019 there are three key trends at the intersection of Kubernetes and virtualization that we expect to see playing out, each of which we will examine further:
- Kubernetes orchestrating micro-VMs to provide stricter multitenant isolation for untrusted workloads.
- Kubernetes orchestrating and managing traditional VM-based workloads (via KubeVirt) alongside container-based workloads.
- Kubernetes clusters increasingly being deployed on bare metal servers, as an alternative to Kubernetes on VM-based environments.
None of these is a new idea by itself, but in 2019 we expect to see the momentum behind each of these trends take hold. Each capability taken in isolation can be independently useful, but together they illustrate how Kubernetes continues to evolve and be applied to an even broader array of applications past, present, and future.
Kubernetes Orchestrating Micro-VMs
One of the core considerations when adopting Kubernetes and containers is security and how to ensure that containers run securely in a multi-tenant environment. Containers run as isolated processes on a shared Linux host, and you often run multiple containerized applications in a Kubernetes cluster comprised of multiple hosts. There are multiple layers of container security, from the Linux host level to the Kubernetes cluster level, that protect those applications from being exploited. These include Linux kernel-level capabilities like cGroups, namespaces, seccomp and SELinux which ensure that containers can’t exploit the underlying Linux host or other containers. At the Kubernetes cluster level, features like role-based access controls (RBAC), namespace tenant isolation and pod security policies enable multiple applications to run securely on the same cluster. Most users today are confident in the security these capabilities provide, and as a result, we’ve seen explosive growth in the number of customers running Kubernetes in mission-critical production environments.
For some users there may be a desire for even stronger multi-tenant isolation, whether that’s due to running untrusted workloads, having stricter security requirements or other reasons. This is where micro-VM based approaches like Kata Containers, Firecracker or gVisor have started to make their mark. Micro-VMs are not like traditional VMs that you might run on VMWare, AWS or other providers. Instead, they remix existing hardware-assisted virtualization technologies, like the Kernel-based Virtual Machine (KVM), within the context of application containers to provide a very lightweight virtual machine. Rather than trying to present a full “machine” as in traditional virtualization, this approach focuses on providing just enough VM to successfully execute an application container or function. As a result, you can’t just take a traditional VM and run it in a micro-VM based container, due to its functional differences and limitations. Instead, micro-VMs aim to provide hard isolation relative to standard Linux containers, while minimizing the trade-offs of traditional VMs in terms of cold start time and performance.
While technologies like Firecracker, Kata and gVisor have garnered a lot of attention, at this time there is no clear leader in this space in terms of user adoption, with each approach having its own inherent trade-offs. While we expect that the vast majority of workloads Kubernetes orchestrates will remain standard application containers, we are keeping an eye on this trend as micro-VMs continue to evolve in 2019.
Kubernetes Orchestrating Standard VMs
The Kubernetes orchestration engine provides a more scalable and flexible model for enterprise production workloads. Initially, this primarily came with a subtext — production workloads that are packaged as application containers. But through open source projects like KubeVirt we are seeing that this same powerful Kubernetes orchestration engine can be feasibly applied to manage standard virtual machines that would normally run in a cloud or virtualization platform.
In 2019 we expect this trend to continue and turn into a broader mindset change. What was previously a choice between VM-centric and container-centric infrastructure will be moot. Kubernetes will start to enable hybrid operations for containers and virtual machines… and it’ll be running on bare metal environments.
Container-native virtualization is a concept that enables virtual machines to follow the same workflow as container-based applications in Kubernetes. Previously, virtualization stacks were completely separate silos from Kubernetes and cloud native implementations — separate workflows, separate tools, separate teams, etc. But as digital transformation takes hold, the need to unify these disparate technologies, processes and teams become paramount. In using container-native virtualization with KubeVirt, enterprises will be able to more effectively integrate their application operations and retain existing IT skills while still embracing modern infrastructure built on Kubernetes.
Kubernetes on Bare Metal, without the VMs
While virtual machines become a bigger part of the Kubernetes workload mix, we also see them becoming less popular as part of Kubernetes’ underlying infrastructure. While most Kubernetes platforms are deployed on VM-based infrastructure today, containers have no dependency on VMs to run. We see interest in running Kubernetes and containers on bare metal continue to grow.
Running Kubernetes on bare metal will enable applications to take full advantage of the underlying hardware, which is important as customers bring more machine and performance sensitive applications to Kubernetes. Running Kubernetes and containers on bare metal can also help organizations reduce VM sprawl and simplify their operations.
With the desire to avoid lock-in to any one provider or vendor, users are focusing on Kubernetes as a common abstraction layer for applications running across physical, virtual, private cloud and public cloud environments. We need to meet users where their needs are. This means offering Kubernetes across the open hybrid cloud, including on-premises and on metal.
Into 2019 and Beyond
While Kubernetes has now been around for several years, innovation continues to accelerate as this next era takes off. Red Hat first got involved in Kubernetes in 2014 as part of the initial project launch, and have been offering enterprise Kubernetes in the form of Red Hat OpenShift Container Platform since our version 3.0 (based on Kubernetes 1.0) launched in June 2015. As we focus in 2019, we see these trends playing a significant role in the community ecosystem and for enterprise customers.
