Kubernetes cluster sizing calculator
How many worker nodes does your cluster actually need? Sized from pod requests, the resource kube-scheduler really allocates, with system reserves, the pods-per-node ceiling and failover capacity included, plus a comparison across common node shapes.
Cluster size
Same workload on other node shapes
| Node shape | Nodes (incl. failover) | Cluster vCPU | Cluster RAM | CPU util | RAM util |
|---|
How it's calculated
Sizing is driven by requests, not limits or actual usage. Requests are what the scheduler reserves, so they determine when a node is "full" regardless of real utilization. Each node's allocatable capacity is its raw vCPU and memory minus the system reserve, which covers kubelet, the container runtime, OS daemons and the eviction threshold; 10% is a reasonable default for mid-size nodes, more on small ones where the fixed costs weigh proportionally more.
Nodes needed is the worst of three constraints: ceil(Σ CPU requests / allocatable CPU), ceil(Σ memory requests / allocatable memory), and ceil(pods / max pods per node). The kubelet default cap is 110, and CNI or cloud-provider limits can be lower. Failover adds N+1 or N+2 spare nodes so a node failure or a rolling drain doesn't leave pods unschedulable; without it, a cluster sized exactly to fit has nowhere to reschedule.
What the model deliberately leaves out: DaemonSets (add their per-node requests to the reserve if they're heavy), significant request/usage gaps (if your requests are inflated, right-size them before buying nodes. That's the cheapest capacity you'll ever get), and burst headroom for HPA scale-ups, which you can approximate by sizing for peak replica counts. Fewer, larger nodes waste less on per-node overhead; more, smaller nodes reduce blast radius. The comparison table shows that trade-off with your own workload.