Kubernetes Did Not Replace Virtual Machines — It Changed

Kubernetes did not replace virtual machines; it altered the control plane above compute resources. Many production architectures still use virtual machines alongside Kubernetes, not because they are obsolete, but because Kubernetes was not designed to perform the tasks of a virtual machine. The popular belief that virtual machines were superseded by containers, which in turn were replaced by Kubernetes, oversimplifies the actual changes that occurred.

The true enterprise stack is more complex, encompassing physical infrastructure, virtualization, an operating environment, Kubernetes, and the workloads themselves. These layers build upon each other, rather than replacing one another sequentially. The core change brought about by Kubernetes adoption is the introduction of an application control plane positioned above the compute substrate.

This control plane is responsible for decisions related to where workloads run, when they are reconciled, and how they discover their dependencies. However, Kubernetes does not function as a substitute for the underlying virtualization architecture.

A common misinterpretation arises when organizations plan platform transitions based on the wrong element. For example, discussions about migrating from VMware to Kubernetes often mistakenly focus on replacing the hypervisor, overlooking the fact that the operating model built around it is crucial to the transition. Similarly, assuming that Kubernetes now controls the application layer implies that the virtualization layer beneath it is no longer needed.

However, Kubernetes' architecture allows for both virtual and physical nodes, demonstrating that virtualization and Kubernetes can coexist without one necessitating the other.

Kubernetes primarily transformed the control plane, shifting responsibilities such as application placement, workload reconciliation, and service discovery to a higher-level control plane. Application-specific operators and external platform tools can still operate alongside Kubernetes without being replaced. Before Kubernetes became the default choice, these responsibilities were scattered across various VM and application tooling, platform scripts, and manual operator judgments, leading to fragmentation and a lack of cohesive management.

Kubernetes addresses this fragmentation by providing a unified control plane for these responsibilities.

The responsibilities before Kubernetes's ascendance included VM or platform administrators handling application placement, manual or scripted methods for workload reconciliation, and the use of VM and application-specific tooling. With the introduction of Kubernetes, application lifecycle management shifted to Kubernetes controllers, while external or platform tooling continued to support workload reconciliation.

The underlying OS/kernel isolation boundary remains essential, even when workloads are placed inside VMs, and the hypervisor or VM boundary still exists, depending on the underlying infrastructure.

The underlying responsibilities didn't vanish or become solely Kubernetes' responsibility just because it took over workload scheduling. The virtualization layer still provides compute abstraction and serves as a distinct infrastructure layer when VMs are utilized, while Kubernetes manages the cluster's workload state above this boundary. This separation of responsibilities, rather than a takeover, forms the basis of a coherent and efficient architecture.

Kubernetes clusters running on VMs should not be framed as the conclusion of the discussion. Instead, the more significant point is that different layers address distinct isolation and lifecycle challenges, making the arrangement architecturally coherent rather than a relic of outdated practices. The infrastructure layer that underpins a mature Kubernetes environment, regardless of whether it is virtualized or not, includes stronger OS/kernel isolation, underlying infrastructure lifecycle management, a substrate (such as infrastructure hosting control-plane and worker nodes), additional isolation boundaries for security or regulatory requirements, and a placement option for workloads whose operational requirements don't align with the chosen container platform.

The infrastructure boundary between the application control plane and physical compute remains essential, highlighting the continued relevance of the virtualization layer even as Kubernetes takes over application-level responsibilities.