Managed Kubernetes hides the control plane, the load balancers and the storage behind an API and bills for every gigabyte that leaves. On bare metal, compute is cheaper and egress is flat, but those pieces become yours. The decisions in order, with a costed three-server cluster at the end.
Running Kubernetes on dedicated servers trades one bill for another kind of work. Managed Kubernetes in the cloud hides the control plane, the load balancers and the storage behind an API, and charges for compute and every gigabyte that leaves. On rented bare metal, compute is far cheaper and egress is a flat rate, but those three hidden pieces become yours to build. None of them is hard. All of them need deciding before the first workload goes live. This guide covers the decisions in order: cluster shape, distribution, load balancing, storage and networking, with a costed example at the end.
The case for it is mostly arithmetic. A dual EPYC 9554 with 128 cores and 512 GB of RAM rents for €959 a month on our 1 Gbps tier, with no per-gigabyte egress charge. Cloud egress, by contrast, is metered: cost per terabyte of bandwidth shows a list price of $90 per terabyte at the first AWS tier. For a cluster that serves real traffic, egress alone can exceed the cost of the servers.
You also get the whole machine: no noisy neighbours, local NVMe without network-storage latency, and the full memory bandwidth of each socket.
What you give up is elasticity measured in seconds. A cloud cluster can add a node while a traffic spike is still building; a dedicated server takes up to an hour to activate when the configuration is in stock, longer when it is not. Bare-metal clusters are sized for the peak and run with headroom, rather than scaled on demand. If your load swings tenfold within a day, keep a cloud node pool for the swing, or keep spare capacity on the metal.
Kubernetes keeps its state in etcd, which needs a majority of members — a quorum — to accept writes. With three members, the cluster survives one failure; with five, it survives two. Two members is worse than one, because losing either stops the cluster.
That gives two sensible shapes:
Keep every control-plane member in the same location. etcd is sensitive to latency between its members, and a quorum spread across cities is slower and more fragile.
On a small team, k3s or Talos usually wins: fewer moving parts to patch.
On a cloud cluster, a Service of type LoadBalancer gets an external address in seconds. On bare metal it stays <pending> forever unless something answers for it. The options:
Ask your provider exactly how additional IPs are delivered before choosing. It decides which of these designs is possible.
For databases, the best pattern is often neither replicated option: local NVMe volumes, with the database replicating itself through an operator such as CloudNativePG for PostgreSQL. You get local-disk speed, and failover the database understands.
Replicated storage traffic shares the port with your users. Three replicas of a busy volume can move more data between nodes than the application sends to the internet, which is the strongest argument for the 10 Gbps tier on storage-heavy clusters.
Pick a CNI by what you need. Flannel is simple and enough for many clusters; Calico and Cilium add network policies, and Cilium adds eBPF-based load balancing and observability.
Unless your servers share a private network, node-to-node traffic crosses public addresses. Encrypt it: Flannel, Calico and Cilium all offer a WireGuard mode, and it costs little on modern CPUs. Lower the pod MTU accordingly, or let the CNI do it.
Then close everything the internet does not need: the API server on 6443 only from your own addresses, and the kubelet on 10250 and etcd on 2379–2380 only from other nodes. A bare-metal cluster has no cloud security group in front of it; the host firewall is the security group.
Three dual Xeon E5-2699 v4 servers — 88 threads and 256 GB of RAM each — cost €897 a month together on the 1 Gbps tier: 264 threads, 768 GB of memory and 3 Gbps of guaranteed, unmetered bandwidth. Moving the same three machines to 10 Gbps for storage replication and heavier traffic costs €2,247 a month.
For CPU-bound or memory-bandwidth-bound workloads, three dual EPYC 9254 servers (96 threads, 256 GB, 10 NVMe bays each) cost €2,037 a month at 1 Gbps. EPYC vs Xeon explains which of those two families suits which workload.
For steady workloads with real traffic, usually by a wide margin, because compute costs less and egress is not metered. The saving is paid for in operations work: you run the control plane, load balancing and storage yourself.
Three, so etcd keeps a quorum when one server fails. Each can run both the control plane and workloads. Add workers as load grows.
k3s for the quickest path on a few servers, Talos Linux for an immutable, API-managed setup, and kubeadm if you want upstream Kubernetes and plan to choose every component yourself.
Something has to announce the service addresses. MetalLB does it with ARP in layer 2 mode or with BGP; kube-vip is an alternative. Which one works depends on how your provider routes additional IPs.
Yes. Small VPS instances make a good separate control plane, with dedicated servers as workers. Keep them in the same city, and encrypt node traffic if it crosses public addresses.
Both give you root over SSH, and on day one they feel the same. The difference shows when you load a kernel module, run Docker, tune the network or install anything that is not Linux. How KVM and containers work, what only your own kernel allows, and the one command that tells you which you have.
Low prices come from three places: paid-off hardware, a thin network, or missing essentials. Only the first is a good trade. What a 2016 dual Xeon gives up against a new EPYC, the network fine print to read, price per thread against a VPS, and four checks to run on delivery.
Port speed, guaranteed rate and traffic allowance are three different numbers, and VPS plan pages love to blur them. What a guaranteed gigabit moves in a month, why bandwidth costs CPU as well, how to test a plan with iperf3, and where a VPS stops and a dedicated server starts.