Kubernetes Pod Capacity & Node Sizing Calculator (Requests, Bin-Packing & Cost)
How many pods fit on a node and how many nodes does a deployment need? From node CPU and memory, system and kubelet reservations, DaemonSet overhead and your pod requests, get pods per node (the binding resource), nodes for N replicas with headroom, wasted capacity from bin-packing, requests-vs-limits ratio, and monthly cost per pod and per replica.
How it works
allocatable = node − system/kubelet reserved · free = allocatable − DaemonSets · pods per node = min(⌊free CPU ÷ request⌋, ⌊free memory ÷ request⌋, max-pods) · nodes = ⌈replicas ÷ pods per node × (1 + headroom)⌉ · cost per replica = nodes × node cost ÷ replicas
The scheduler places a pod only where its requested CPU and memory both fit, so a node's capacity for a given workload is the smaller of the two counts after the operating system, kubelet and the per-node agents have taken their share, and whichever resource runs out first leaves the other partly idle. That stranded capacity, the fixed per-node overhead and the headroom needed to survive a failed node or a rolling update are why a cluster bought by adding up requests always comes out larger, and why matching the node's memory-to-CPU ratio to the pods' is worth real money. Limits do not enter the count at all; they only govern what happens when pods burst.
Worked example
An 8 vCPU / 32 GiB node reserving 0.3 vCPU and 2 GiB for the system and 0.4 vCPU / 1 GiB for DaemonSets leaves 7.3 vCPU and 29 GiB; pods requesting 0.5 vCPU and 1.5 GiB fit 14 by CPU and 19 by memory, so 14 pods, CPU-bound, with 8 GiB of memory stranded. Sixty replicas need 4.3 nodes — 5 exactly, 6 with 25% headroom — about $1,500 a month or $25 per replica; a compute-optimised 8 vCPU / 16 GiB node would waste far less memory.
Frequently asked questions
Should I count limits or requests?
Requests — the scheduler only looks at requests. Limits govern throttling (CPU) and OOM kills (memory) at runtime. Overcommitting on CPU limits is normal; overcommitting memory limits invites evictions.
How much headroom is enough?
Enough to lose one node (1/N of capacity) plus the surge of a rolling update (maxSurge, default 25% of a deployment). For small clusters that means 30–50%; for large ones 15–25%. Cluster autoscalers reduce the need to pre-buy it.
Related calculators
Game mechanics, hardware figures and platform rates change with patches, firmware and contracts — values here reflect commonly published figures at the time of writing. Check the current game version, your drive's datasheet or your distributor's statement for exact numbers.