ANo virtual layer
Nothing between your pods and the hardware
No hypervisor takes a share of the processor or sits in the disk and network path. What you measure on the node is what your containers get, which makes requests and limits easier to set.
Bare metal for containers
Kubernetes on bare metal that you run yourself
Kubernetes on bare metal means every node in your cluster is a whole dedicated server, with no hypervisor between your pods and the hardware. Primcast rents those servers by the month with root access and an unmetered port, so you can install Docker, k3s, RKE2 or kubeadm and run the cluster your way.
A server that is already racked is handed over about 30 minutes after your order is approved. No contract: you pay one month at a time.
01Why bare metal
Why your containers run better on a server of their own
Containers already share one kernel, so a virtual machine underneath adds a second layer that does nothing for you. On a dedicated server your workloads get the processor, memory, disks and network card directly.
BOne tenant
No neighbour slowing your nodes down
Nobody else runs anything on your server. A busy stranger cannot eat the disk queue or the memory bandwidth your database pod was counting on, so latency stays where you left it.
CFlat bill
Traffic that nobody counts
Each server comes with an unmetered port that is not shared, 1 Gbps or 500 Mbps depending on the line. Image pulls, replication between nodes and traffic to your users never turn up as a per-gigabyte charge.
DFull control
Root, a reinstall button and a way back in
You get root on every server and can reinstall the system from the control panel at no charge. Rack servers and blades also have a browser console with power control, for the day a network change locks you out.
02Pick your path
Docker on one dedicated server, or bare metal Kubernetes?
Start from the job. A handful of services on one machine needs Docker and nothing more. Several machines that should heal themselves need Kubernetes, and then the question is who looks after the control plane.
| Path | Good for | Control plane | Where to go |
|---|---|---|---|
| Docker on a dedicated server | A few apps with Docker Compose, a build runner, a staging copy of production | None needed | Any server below |
| Your own Kubernetes cluster | Teams who want to pick the distribution, the network plugin and the upgrade dates | You run it, on your own servers | This page |
| Managed Kubernetes | Teams who want kubectl and their own workers, without looking after etcd | We run it; your servers are the workers | Managed Kubernetes |
Only need one small machine? A Cloud VPS runs Docker too. Want virtual machines and containers side by side on your own hardware? Look at Proxmox servers.
03Sizing
What a bare metal Kubernetes node needs
The kubeadm documentation sets the floor: 2 GB of memory on every machine and at least 2 processor cores on a control-plane node. Any dedicated server clears that easily, so size for your workloads, and plan for three control-plane nodes if the cluster has to survive losing one.
| Role | Minimum | Ports to open between your nodes |
|---|---|---|
| Control plane | 2 cores, 2 GB memory | 6443, 2379-2380, 10250, 10257, 10259 |
| Worker | 2 GB memory | 10250, 10256, 30000-32767 |
| Every node | A unique hostname, MAC address and product UUID | Full network reach to the other nodes |
A small cluster that works
One control-plane node and two workers is enough to learn on and to run staging. Put etcd on servers with solid-state drives: it is sensitive to disk write latency, and a slow disk slows every change in the cluster.
A cluster that survives a failed server
Three control-plane nodes keep etcd in quorum when one of them goes down. Add workers for capacity, and put GPU servers in the same cluster for inference or encoding jobs, kept apart from other pods with labels and taints.
04Setting it up
Your own cluster in an evening
Here is the usual order of work with kubeadm. k3s and RKE2 fold steps 2 and 3 into one install script, and the rest stays the same.
-
01
Order the servers
Pick servers from the list below and choose a current Ubuntu or Debian image at checkout. Racked servers arrive about 30 minutes after approval; a server built to your spec takes 4 to 24 hours when the parts are in hand.
-
02
Prepare every node
Install a container runtime such as containerd, keep the clocks in sync, and turn swap off unless you have set the kubelet up for it. Then install kubeadm, kubelet and kubectl from the Kubernetes package repository.
-
03
Start the control plane
Run
kubeadm initon the first control-plane server, then thekubeadm joinline it prints on each worker. Your kubeconfig is on that first server. -
04
Add a network plugin
Pods cannot talk until a network plugin is in. Cilium, Calico and Flannel are the usual choices; Cilium and Calico also enforce NetworkPolicy.
-
05
Close the doors
Allow the ports in the table above only from your own nodes' addresses, and keep the API port open only to the people who run the cluster.
-
06
Let traffic in
Bare metal has no cloud load balancer, so a tool such as MetalLB hands Services of type LoadBalancer extra IPv4 addresses ordered with your servers. An ingress controller then serves your sites on 80 and 443.
Only need Docker? Install Docker Engine from Docker's own repository for your distribution, check it with docker run hello-world, and run your stack with Docker Compose. That is the whole setup.
05Servers
Dedicated servers for Docker and Kubernetes
Every server below can be a Docker host or a node in a self-managed Kubernetes cluster. Prices and specs come straight from the catalogue; open one to see its options and order it.
06Before you order
What you get, and what stays your job
On this path we look after the hardware and the network, and you look after everything from the operating system up. Here is where that line sits.
Comes with every server
- The whole machine, with root access and nobody else on it
- An unmetered port that is not shared, plus one IPv4 and one IPv6 address
- Free reinstalls of the operating system from the control panel
- A browser console and power control on rack servers and blades
- Credits under the service agreement when the network is down or a failed part is not replaced in time
Good to know
- We do not install, upgrade or watch your cluster on this path. If you want that, see managed Kubernetes.
- No DDoS protection is sold with any server.
- Most cartridge servers have power control but no console, so pick a rack server or blade for your control plane.
- ARM servers run Docker and Kubernetes, but only images built for arm64.
07Questions
Questions people ask about containers on bare metal
01Is Kubernetes faster on bare metal than on virtual machines?
Usually, yes, because nothing sits between your pods and the hardware. A virtual machine adds a hypervisor in the processor, disk and network path and often shares the host with other customers. On a dedicated server your containers get the whole machine, and their performance does not change when someone else gets busy.
02Can I run Docker on a dedicated server?
Yes. You have root, so you install Docker Engine from Docker's repository for your distribution and run your containers or a Docker Compose stack straight away. Many people start that way and add Kubernetes once they have more than one server.
03Do you install and manage Kubernetes for me?
Not on this page's servers: you choose the distribution and run the cluster yourself. If you would rather not look after the control plane, our managed Kubernetes runs it for you in New York while your own dedicated servers stay the workers, with root kept on each one.
04How many servers do I need for a Kubernetes cluster?
One server can run a single-node cluster with k3s or kubeadm, which is fine for development. For a cluster that keeps running when a machine fails, use three control-plane nodes so etcd keeps its quorum, plus as many workers as your workloads need.
05How do LoadBalancer services work on bare metal?
There is no cloud load balancer to call, so you install one in the cluster. MetalLB is the common choice: it gives each Service of type LoadBalancer one of the extra IPv4 addresses you ordered with your servers and announces it on the network.
06Is traffic between my nodes or to my users metered?
No. Nothing counts the traffic on a dedicated server. Each one has its own port, 1 Gbps or 500 Mbps depending on the line, and image pulls, replication and user traffic all go through it for the same monthly price.
07How quickly can I have the servers?
A server that is already racked is ready about 30 minutes after your order is approved, with the operating system you picked. A server built to your own spec takes 4 to 24 hours when we have the parts. The approval itself, payment and fraud checks, comes first and is the part that varies.
08What help do I get if something breaks?
Our AI chat answers in seconds and can check your account and servers for you, and a person takes over whenever you ask. We fix hardware and network problems; questions inside your cluster are yours to solve, though we are happy to point you in the right direction.
Build your cluster on servers of your own
Rent the servers by the month, keep root on every one, and run Docker or Kubernetes the way you want it. No contract, no counted traffic.