Kubernetes on bare metal
Kubernetes on your own hardware removes the per-hour bill and hands you the parts a cloud provider was quietly doing for you.
First, do you need it
Kubernetes earns its complexity when you have many services, several teams, and a real need for automated rollout and recovery. For three services and two people, a systemd unit and a load balancer do the same job with a fraction of the moving parts — see running your application as a service and load balancing.
That is not a recommendation against it. It is a recommendation to be clear about which problem you are buying the cluster to solve.
Start with k3s
k3s is a full, conformant Kubernetes in a single binary, with sensible defaults and a fraction of the setup. On bare metal it is the right starting point, and you can move to a full distribution later if you ever need to.
Three control plane nodes if the cluster matters; one is fine for development and is a single point of failure in production.
The parts the cloud used to provide
- Load balancer
type: LoadBalancerdoes nothing on bare metal until you install something that implements it. MetalLB in L2 mode is the usual answer; it claims an address from a range you own and answers ARP for it. Ask us for a routed block to use for services.- Ingress
- ingress-nginx or Traefik, behind that address, terminating TLS with cert-manager — see TLS certificates.
- Storage
- No cloud volumes. Local path provisioner for data that may live on one node, Longhorn or Ceph for replicated volumes. Replicated storage over the network is where most bare-metal clusters get slow; keep databases on local NVMe where you can.
Networking
Pick a CNI and understand it: Flannel for simplicity, Calico for network policies, Cilium if you want eBPF and observability. Make sure the pod and service ranges do not collide with anything on your private network — see connecting your own servers.
Mind the MTU. Overlay networks add overhead, and a cluster where small requests work and large ones hang is nearly always this: MTU and tunnels.
Secure it like the control plane it is
- The API server must not be open to the internet. Reach it over WireGuard.
- RBAC properly, not
cluster-adminfor everything. - etcd backed up and encrypted at rest — it holds every secret in the cluster.
- Keep nodes patched; see automatic security updates.
What bare metal gives you back
No hypervisor tax, local NVMe at full speed, and an unmetered port instead of egress charges — which for a cluster moving real data is frequently the largest line on a cloud bill. Tell us the node count and shape you are planning and we will quote hardware that fits it.
Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base