Sizing a production OpenShift cluster

There’s a real gap between the minimums that let the installer succeed and the specs that survive production load. Build to the documented floor and you’ll have a cluster that installs cleanly and then struggles under real workloads. Here’s both, and the one number that matters more than any other.

Watch on YouTube ↗

Installer minimums vs a realistic baseline

	Red Hat documented minimum	Realistic production baseline
Control plane (×3)	4 vCPU, 16 GB	8 vCPU, 32 GB, dedicated
Worker (×N)	2 vCPU, 8 GB	8–16 vCPU, 32–64 GB, sized to workload
Node storage	~100–120 GB	120 GB+ OS, plus separate PV storage

The documented numbers are floors, not targets. Treat them as “will the installer run,” not “will this hold up.”

The number that matters most: etcd disk latency

Caution

The single most important production decision on the control plane isn’t CPU or RAM — it’s etcd disk performance. etcd needs low-latency storage: SSD/NVMe with 99th-percentile fsync under ~10 ms. Slow or shared disks are the number-one cause of control-plane instability. Give etcd a dedicated fast disk wherever you can, and keep masters dedicated — don’t schedule app workloads on them.

Three control-plane nodes, always — etcd needs an odd number for quorum, and 3 tolerates one failure. Going to 5 only earns its keep on very large clusters (roughly 100+ nodes); below that it’s just more etcd overhead.

Reserve headroom you’ll actually lose

Each node gives up roughly 1–2 vCPU and 2–4 GB RAM to the kubelet, CRI-O, monitoring, logging and networking daemons before your pods get anything. Size above your workload, not exactly to it.

And on failure domains: if your workers span three zones/racks and you want to survive losing one, you can only safely run the fleet at ~60–65% utilisation — otherwise a zone loss triggers eviction storms as the survivors can’t absorb the displaced pods. “Is six workers enough?” depends entirely on target utilisation: six at 40% is a different cluster from six at 85%. Size for N+1, ideally N+failure-domain, headroom.

What quietly pushes requirements up

• Monitoring, logging and the internal registry are heavy. Running them on your app workers means contention; this is the main argument for dedicated infra nodes (covered in the topology guide).
• OpenShift Data Foundation (ODF/Ceph) for in-cluster storage wants its own 3 nodes with extra RAM (16–24 GB on top of baseline) and dedicated raw disks.
• Service mesh, GPU workloads, heavy CI/CD all change the maths materially.

Beyond compute

Production isn’t just node specs:

• Three control-plane nodes across three failure domains for HA.
• Load balancing for the API (ports 6443, 22623) and for ingress (80, 443).
• DNS for api, api-int, and *.apps, plus reverse DNS on bare metal.
• Registry access for every node — internet, or a mirror for disconnected installs.

Get the etcd disk right and give yourself utilisation headroom, and most other sizing choices become adjustable rather than load-bearing.