Kubernetes virtual machines still coexist by design in many production architectures — not because those environments are behind, but because Kubernetes was never built to do a virtual machine's job. The industry shorthand says otherwise: VM gave way to container, container gave way to Kubernetes, and the virtualization layer is what got left behind. That sequence is clean, and it's wrong about what actually changed.
The Replacement Story That Never Happened
The real enterprise stack was never VM → container → Kubernetes. It's closer to physical infrastructure → virtualization → operating environment → Kubernetes → workload — layers stacked on top of each other, not replacing each other in sequence. What changed with Kubernetes adoption is which layer makes application-level decisions. Kubernetes became an application control plane above the compute substrate — the system deciding where workloads run, when they're reconciled, and how they discover their dependencies. It did not become a substitute for the virtualization architecture underneath it.
That distinction matters because the same misdiagnosis shows up whenever an organization plans a platform transition around the wrong artifact. The VMware exit conversation hits the identical failure mode — teams fixate on replacing the hypervisor and miss that the operating model built around it is the thing that actually has to transfer. Kubernetes-versus-VM thinking makes the same mistake in reverse: assuming that because Kubernetes owns the application layer now, the virtualization layer underneath has nothing left to do.
Kubernetes' own architecture makes the underlying point directly: a Kubernetes node can be virtual or physical. Virtualization and Kubernetes were never competing implementations of the same layer — they can coexist, but Kubernetes doesn't require virtualization to function. Kubernetes changed the control plane above the compute substrate. Virtualization is one possible infrastructure boundary underneath that control plane, not the workload scheduler Kubernetes replaced.
What Actually Moved
Kubernetes brought application placement, workload reconciliation, and service discovery into a common higher-level control plane, while application-specific operators and external platform tooling can still participate around it. Before Kubernetes was the default, those responsibilities were split across VM and application tooling, platform scripts, and manual operator judgment — functional, but fragmented, and never owned by one system end to end. That fragmentation is exactly what the Virtualization Control Plane Architecture stage of the learning path maps in detail.
| Responsibility | Before Kubernetes Was Dominant | Mature Kubernetes Model |
|---|---|---|
| Application placement | VM/platform administrators, manual or scripted | Kubernetes scheduler / control plane |
| Application lifecycle | VM and application-specific tooling | Kubernetes controllers |
| Workload reconciliation | External or platform tooling | Kubernetes control plane |
| OS/kernel isolation | VM/hypervisor boundary | Still a VM or container boundary, architecture-dependent |
| Physical compute abstraction | Hypervisor | Still the virtualization/infrastructure layer |
| Node lifecycle | Infrastructure/platform operations | Kubernetes plus underlying infrastructure tooling |
Read the bottom three rows carefully. The underlying responsibilities didn't disappear or become Kubernetes responsibilities just because Kubernetes took over workload scheduling — the virtualization layer still provides compute abstraction and, where VMs are used, a distinct infrastructure boundary, while Kubernetes operates above that boundary and manages the cluster's workload state. That's a separation of responsibility, not a takeover.
What Stayed Underneath — and Why
The temptation in any Kubernetes virtual machines discussion is to frame this as "Kubernetes clusters run on VMs" and treat that as the article's punchline. It isn't, and leaning on it that way undersells the argument — of course a scheduler needs something to schedule onto. The more useful point is that different layers solve different isolation and lifecycle problems, and that's exactly why the arrangement is architecturally coherent rather than a leftover habit.
What the infrastructure layer still provides underneath a mature Kubernetes environment — whether that layer is virtualized or not:
A stronger OS/kernel isolation boundary — when workloads are placed inside VMs, on top of the isolation containers already provide
Underlying infrastructure lifecycle — hardware, hypervisor, VM provisioning, and capacity, which Kubernetes' own node lifecycle depends on but doesn't replace
A substrate Kubernetes may run on — including infrastructure hosting control-plane and worker nodes
An additional isolation boundary — where security, regulatory, or contractual requirements call for one
A placement option for workloads — whose operating, storage, isolation, or lifecycle requirements don't map cleanly to the chosen container platform
The infrastructure boundary between the application control plane and physical compute
The same principle shows up wherever a scheduling layer depends on infrastructure it doesn't directly control. GPU scheduling in Kubernetes runs into it immediately — the scheduler can't make good placement decisions until the infrastructure underneath it is actually ready, and no amount of scheduler sophistication substitutes for that. It's the same argument the market made about the hypervisor itself: a layer becoming commoditized isn't the same as a layer becoming irrelevant. Commoditized and invisible-to-the-application-team are not the same as gone.
The Division of Labor in a Mature Environment
The table above showed what changed over time — where responsibility used to sit versus where it sits now. This one shows where that responsibility actually lands, workload by workload, in an environment that's already made the transition. It's a snapshot of current-state architecture, not another version of the same before/after comparison.
| Workload / Function | Primary Control Plane | Likely Infrastructure Boundary |
|---|---|---|
| Stateless application | Kubernetes | VM or bare metal |
| Ephemeral batch workload | Kubernetes | VM or bare metal |
| Stateful distributed application | Kubernetes + application operator | VM or bare metal, depending on requirements |
| Legacy application | VM/platform tooling | VM |
| Kubernetes control plane itself | Kubernetes | VM or bare metal |
| Infrastructure services | Infrastructure/platform tooling | VM, bare metal, or dedicated appliance |
"Likely" is doing real work in that second column — this isn't a prescriptive matrix to apply uniformly across an estate. It's a description of where the boundary tends to sit once the layer separation above is actually understood, which is the more useful thing to walk into a platform-architecture decision with than a binary "container or VM" checklist.
Where Architects Get This Wrong
⚠ Common Mistake: Treating Kubernetes adoption as equivalent to virtual machine elimination. The correct model is narrower: Kubernetes adoption abstracts the application control plane above the infrastructure layer — it doesn't remove the infrastructure layer's job.
Most of the confusion in Kubernetes virtual machines architecture shows up well after the platform decision is made, not during it: premature VM-to-container migrations that hit a workload the container model genuinely can't serve; capacity planning that assumes Kubernetes adoption automatically eliminates an equivalent amount of VM capacity; treating every workload as containerizable by default instead of by evaluation; and — the one that catches teams furthest into a project — overlooking that Kubernetes itself has real infrastructure requirements that don't disappear just because the cluster is the thing making application decisions now.
It's the same assumption that shows up when Kubernetes gets treated as a VMware exit ramp on its own: adopting Kubernetes changes what runs the application layer, but it doesn't answer the infrastructure-layer question a VMware exit actually has to resolve. Conflating the two produces a migration plan that's solved the wrong problem.
Architect's Verdict
Kubernetes did not remove the virtualization layer. It made that layer less relevant to application scheduling while making its infrastructure role more explicit — and those are two very different outcomes that keep getting collapsed into one.
The real problem in Kubernetes virtual machines architecture isn't that architects believe VMs are gone. It's that reduced visibility gets read as reduced relevance, and that misreading drives migration timelines, capacity models, and containerization targets that don't match what the infrastructure actually needs to keep providing underneath the cluster.
The VM didn't lose its place in the stack. It lost visibility to the application layer.
Originally published at rack2cloud.com
Top comments (0)