Should I run Kubernetes on bare metal or on VMs?

When is bare metal the better place for Kubernetes?

When you have at least three servers and your workloads want the hardware itself. Three machines give three etcd members on three separate failure domains. Pods reach the NVMe drives with no virtual disk layer, which suits databases on local volumes. There is one kernel to patch and one network stack to debug.

The network stays simple too. Each node holds its server's own IPv4, so k3s ServiceLB or an ingress controller answers on real addresses. Our guide on how to run Kubernetes on bare metal servers has the steps.

The weak spot is recovery. There is no IPMI or KVM-over-IP console for customers: you request reboots and reinstalls in the dashboard and the team performs them. A bad network change on a bare node can end in a reinstall. A replacement server is quick, live within the hour, but rebuilding a node still takes work. Keep enough capacity to lose one node for hours, not minutes.

When are VMs the better choice?

When you have one or two machines, several clusters to run, or Talos in mind. A Proxmox host turns one server into a staging cluster, a production cluster and a test bed. Each VM can be snapshotted before an upgrade and rolled back after a failed one.

• Talos Linux. It boots only from its own ISO, PXE script or disk image. A Proxmox VM mounts the ISO, so Talos works here only in VMs.
• A console of last resort. The host has none, but every VM has one in the Proxmox web interface. A broken guest network is fixed from that console, not by a reinstall.
• Pod density. Kubernetes v1.37 is designed for no more than 110 pods per node. Splitting Lumen 32 (32 cores / 64 threads) into VMs gives each VM its own 110.

Sidero's Proxmox guide sizes Talos control-plane VMs at 2 or more cores and 4 GB. Workers get 4 or more cores and 8 GB. It sets the CPU type to host for AVX-512 and x86-64-v2, and notes that this blocks live migration.

Is a three-VM cluster on one server highly available?

No: it survives a crashed VM, not a dead server. etcd keeps quorum while two of three members run, so one VM can fail. When the host fails, all three members go at once.

The Kubernetes high-availability guide names this risk for stacked control planes: losing a node loses an etcd member and a control-plane instance together. On one host, that node is the whole cluster. Three VMs on one machine are a quorum, not redundancy. Use it for staging, labs and Talos trials, and keep production on three machines.

Can I combine both: Kubernetes VMs on a Proxmox cluster?

Yes: three Proxmox hosts with one control-plane VM each is the most flexible design. Each host is its own failure domain, and VMs keep their snapshots and consoles. The price is two clustering layers, corosync for Proxmox and etcd for Kubernetes, and both want low latency. Keep the three hosts in one city.

VMs on different hosts need a shared network. Proxmox SDN builds one with a VXLAN zone, but its documentation warns that VXLAN alone has no encryption. Carry it over WireGuard or another VPN between hosts. VXLAN also takes 50 bytes per packet, so guests use an MTU of 1450.

Our guide on building a Proxmox cluster with rented dedicated servers covers quorum and corosync on public addresses.

Does a hypervisor slow Kubernetes down?

It adds a layer, and Lumenfer has measured nothing, so we give no figure. A VM sees virtual CPUs, a virtual disk and a virtual network card. CPU features reach the guest only when the CPU type passes them through. Memory assigned to one VM is gone for the others and for the host.

Test your own deployment on a bare node and on a VM before you commit. Our guide to finding honest benchmarks explains how to measure a rented server yourself.

Which Lumenfer plans fit each design?

Bare metal needs three servers; VMs can start with one large one. Prices are per server; 6- and 12-month terms cost less per month.

13 of 18 no-KYC crypto hosts in Lumenfer's check of 30 October 2026 sold any dedicated server with a 2022-or-newer CPU and NVMe only. Those servers made up 113 of 229 comparable plans. Every plan is on what a Lumenfer server costs, and the migration case is in whether to move from AWS to bare metal.