Should Kubernetes nodes be physical machines or virtual machines? The debate usually happens on performance grounds, which is the least interesting axis.
The performance question, briefly
Virtualization overhead on modern hardware is small for most workloads. A few percent, and less than the variance you get from noisy neighbours, NUMA placement, or a badly set CPU governor.
Where it stops being small: workloads needing device passthrough, accelerators, very high packet rates, or latency guarantees measured in microseconds. There, bare metal is the answer and the discussion is over.
For everything else, the overhead is not the deciding factor and pretending it is avoids the real decision.
What virtualization actually buys you
Node lifecycle you already know how to do. Build a node from a template in minutes. Resize it. Snapshot before an upgrade. Move it off a host that needs maintenance. Your team does this every day for everything else.
Better packing. Control plane nodes are small and there must be three of them. On bare metal that is three physical machines that are mostly idle. Virtualized, they share hosts with other things.
Multiple clusters without multiple hardware purchases. Development, staging, production, and the throwaway cluster for testing an upgrade. On bare metal each one is a capital request.
That last point is decisive for most enterprises. The discipline that makes Kubernetes survivable — test every upgrade on a representative cluster first — requires cheap clusters. Virtualization makes clusters cheap.
Reuse of existing operational machinery. Backup, monitoring, capacity management, DR. All of it already exists for VMs.
What bare metal buys you
One less layer. Fewer places for a problem to hide, one fewer support matrix, no question about whether a performance anomaly is the hypervisor.
Full access to the hardware. Devices, accelerators, local NVMe at native speed, precise NUMA control.
No hypervisor licence. In the current licensing climate this is not a small consideration, and for some organisations it is the whole argument.
Density at scale. At hundreds of nodes, the packing advantage of virtualization matters less and the overhead adds up to real hardware.
How I would decide
Take bare metal if the workload needs hardware directly, if you are operating at large scale with a dedicated platform team, or if hypervisor licensing has made the layer expensive enough to eliminate.
Take virtualized if you are an enterprise with an existing virtualization platform and team, if you need several clusters, or if the honest answer to “who rebuilds a failed node at 2am” is “whoever is on call for infrastructure generally”.
The second describes most organisations adopting Kubernetes, and they frequently choose bare metal because a reference architecture said so, then discover that node lifecycle is now a hardware provisioning exercise.
The hybrid that often wins
Control plane virtualized, workers bare metal where the workload needs it. Control plane nodes are small, numerous, and benefit most from easy lifecycle. Workers doing accelerated work benefit most from direct hardware.
This is more moving parts, and it puts each component where it belongs. Worth considering rather than treating the question as all-or-nothing.
The question that settles it
Not “which is faster”. Ask: when a node needs rebuilding on a Tuesday afternoon, what happens, and who does it? Follow that answer honestly and the architecture usually decides itself.