Computer & IT
Kubernetes Pod Capacity Calculator
Calculate failure-tolerant pod capacity from schedulable nodes and the minimum of CPU-request, memory-request, and per-node pod limits.
Schedulable nodes after HA reserve-
Planned CPU budget per node-
Planned memory budget per node (GB)-
Pods per node by CPU-
Pods per node by memory-
Schedulable pods per node-
Failure-tolerant cluster pod capacity-
Cluster CPU budget (cores)-
Cluster memory budget (GB)-
Pod slots held by HA reserve-
Decision view
Node bin-packing grid and scheduler bottleneck
Node bin-packing grid and scheduler bottleneckPod tiles fill a representative node while CPU, memory, and kubelet ceilings compete for the cluster limit.
Exact scenario comparisonMemory request per pod (GB) changes while all other entered assumptions remain constant.
| Memory request per pod (GB) | Schedulable nodes after HA reserve | Planned CPU budget per node | Planned memory budget per node (GB) | Pods per node by CPU | Pods per node by memory | Schedulable pods per node | Failure-tolerant cluster pod capacity | Cluster CPU budget (cores) | Cluster memory budget (GB) | Pod slots held by HA reserve |
|---|
How to use Kubernetes Pod Capacity Calculator
- Use effective worker-node specifications.
- Enter requests from deployed manifests, not observed usage.
- Reserve the number of nodes the cluster must tolerate losing.
Calculator guide
Understanding Kubernetes Pod Capacity Calculator
Kubernetes does not schedule on raw node specifications. System reservations, policy headroom, pod requests, an HA node reserve, and the kubelet/network pod ceiling all reduce usable cluster capacity.
Detailed calculation process
Detailed Kubernetes pod-capacity calculation
The default eight-node cluster reserves one node for failure and plans to use 80% of resources remaining after system reservations.
General formula: N_s=max(1,N-N_h)C_n=(C-C_s)*uM_n=(M-M_s)*uP_c=floor(C_n/r_c)P_m=floor(M_n/r_m)P_n=min(P_c,P_m,P_k)P=P_n*N_s Each schedulable node receives independent CPU, memory, and count ceilings. The minimum is multiplied only by nodes available after HA reserve.
What each symbol means
Worked substitution with the default inputs
The default failure-tolerant capacity is 161 pods, limited by CPU requests.
Worked situations
Practical examples
- The default CPU budget supports 23 pods per node.
- Memory supports 38 and the kubelet permits 110, so CPU limits the seven-node failure-tolerant cluster to 161 pods.
Better inputs
Useful tips
- Model heterogeneous node pools separately.
- Leave daemonsets inside system reserve only when their requests are measured there.
- Review topology spread and anti-affinity after arithmetic capacity.
Before relying on the result
Limitations and common mistakes
- The result is not a scheduler simulation.
- It does not place GPUs, ephemeral storage, ports, affinities, taints, or topology rules.
- Bursty limits and noisy-neighbor behavior require runtime testing.
Reference
Key terms
- Request
- Resource quantity used by the scheduler for placement.
- Allocatable budget
- Node resource remaining after system reserve and planning utilization.
- Pod ceiling
- Lowest of CPU, memory, and kubelet/network counts.
Important note
Confirm values against kubelet allocatable resources, CNI limits, pod requests, disruption budgets, topology rules, and failure tests.
Frequently asked questions
Why is CPU capacity lower than memory capacity?
The entered pod CPU request consumes the planned per-node CPU budget first.
Should DaemonSets be entered as pods?
Account for their requested resources once per node, usually through system reserve or a separate deduction.
Can autoscaling exceed this result?
Only by adding nodes or changing requests/constraints; the entered fixed cluster cannot safely schedule beyond its bottleneck.