Should you run Kubernetes on bare metal or on virtual machines?
Run Kubernetes on bare metal when you need every core, direct access to GPUs and network cards, or hardware virtualization for VM-based workloads, and when you can automate server provisioning. Run it on virtual machines when you want fast node replacement, nodes sized independently of the hardware, and the tools of a hypervisor you already operate. Both are common in production; the trade-off is operational effort against performance and hardware access.
Bare-metal Kubernetes means the Kubernetes node is the physical server: the kubelet and container runtime run on the host operating system with no hypervisor underneath. With virtual machines, a hypervisor such as Proxmox VE, vSphere or KVM splits each server into several nodes.
Bare metal vs virtual machines at a glance
| Factor | Bare metal | Virtual machines |
|---|---|---|
| Performance overhead | None from a hypervisor | Some CPU and memory for the hypervisor layer |
| GPUs and network cards | Direct access, all device features | PCI passthrough or vGPU, depending on the hypervisor |
| New or replacement node | Install an OS on hardware; depends on provisioning automation | Clone from a template in minutes |
| Node size | Fixed by the server, often very large | Chosen per VM |
| Hardware maintenance | Draining the node stops every Pod on the server | VMs can often live-migrate to another host first |
| Running VMs or sandboxes inside Pods | Hardware virtualization available directly | Needs nested virtualization in the VM |
| Licensing | No hypervisor license | Depends on the hypervisor; free for Proxmox VE and plain KVM |
Why teams choose bare metal
- GPU and AI workloads. Pods see the full device, and drivers, MIG partitioning and RDMA networking work as the vendor documents them. On VMs, a GPU is passed through to one VM or shared through vGPU, which uses NVIDIA’s separately licensed vGPU software. How GPUs work in Kubernetes explains the device plugin and operator setup that bare metal needs.
- Latency-sensitive networking and storage. Direct access to NICs and NVMe drives avoids virtualized I/O paths.
- Sandboxed and VM workloads. KubeVirt virtual machines and Kata Containers need hardware virtualization on the node. Bare metal provides it; VMs need nested virtualization, which costs performance.
- No hypervisor to run. One less layer to license, patch and monitor.
Why teams choose virtual machines
- Fast, disposable nodes. A VM template plus cloud-init produces a new node quickly, so replacing a broken node or upgrading the operating system means creating new VMs and deleting old ones.
- Smaller failure domains. A server with 128 cores as a single node holds many Pods, and every reboot drains all of them. Several VMs per server let you drain and replace one at a time.
- Pod density limits. Kubernetes supports no more than 110 Pods per node, which is also the kubelet’s default
maxPods. On large servers, the Pod limit can be reached long before CPU or memory is used. Splitting the server into VMs is one fix; raisingmaxPodsis another, with more load on the node. - Existing operations. Teams with a hypervisor, its backups and its monitoring in place add Kubernetes without changing how hardware is run.
How bare-metal nodes are provisioned
On bare metal, the provisioning automation a hypervisor provides has to come from elsewhere:
- Network boot and out-of-band management. PXE or iPXE boot installs the operating system, and the server’s BMC is driven through IPMI or Redfish to power-cycle and reconfigure it.
- Kubernetes-native provisioning. Metal3, a CNCF incubating project since August 2025, manages bare-metal hosts as Kubernetes resources and works with Cluster API. Tinkerbell, a CNCF sandbox project, runs provisioning workflows for physical machines.
- Immutable operating systems. Distributions built only to run Kubernetes reduce drift between servers and make reinstalls predictable. See immutable operating systems for Kubernetes nodes.
- Firmware lifecycle. BIOS, BMC, NIC and GPU firmware need updates that a VM-based setup leaves to the hypervisor host.
A common middle ground
Mixed setups are frequent. The control plane runs on small VMs, general workloads run on VM nodes, and GPU, storage-heavy or latency-sensitive workloads run on bare-metal nodes in the same cluster, selected with node labels and taints. The choice can be made per node, not per cluster. The wider question of where those servers live is covered in running Kubernetes on-premises.
How Cloudfleet fits
Cloudfleet Kubernetes Engine (CFKE) accepts bare-metal servers and virtual machines as self-managed nodes in the same cluster, so the choice can differ per node. Bare-metal nodes can also run Kata Containers, available on request, without nested virtualization.