Kubernetes Cluster Capacity Calculator
Estimate a rollout-safe Kubernetes replica ceiling from allocatable resources and pod requests, then test node loss and disruption limits.| Planning item | Result | Use | Copy |
|---|---|---|---|
| {{ row.item }} | {{ row.result }} | {{ row.use }} |
| Scenario | Safe target | Status | Operator action | Copy |
|---|---|---|---|---|
| {{ row.scenario }} | {{ row.target }} | {{ row.status }} | {{ row.action }} |
A Kubernetes workload can fit while every worker is healthy and still fail to schedule during a rollout or node drain. Capacity planning therefore needs more than a total CPU or memory number. It must account for the scheduler's resource requests, per-node pod limits, platform pods, temporary surge replicas, and the smaller pool that remains after a chosen failure.
Nodes publish allocatable CPU, memory, and ephemeral storage for pods after system reservations. The scheduler compares pod requests with that allocatable amount even when live usage is low. A pod requesting 500 millicpu reserves 0.5 CPU for scheduling; a low utilization graph does not make the request disappear.
| Capacity question | What can bind first | Common mistake |
|---|---|---|
| How many pods fit now? | CPU requests, memory requests, pod slots, optional storage, or pod IPs | Looking only at observed CPU use |
| How many replicas fit during rollout? | Steady capacity divided by the maxSurge multiplier | Leaving no room for temporary new pods |
| How many survive maintenance? | The same ceilings after selected node or largest-zone loss | Testing only the all-nodes-healthy pool |
| Will voluntary eviction proceed? | The PodDisruptionBudget (PDB) availability floor | Assuming a PDB protects against node failure |
Small pods often hit the maximum pods-per-node setting or pod-address supply before CPU or memory. Sidecars, RuntimeClass overhead, and DaemonSets can also change a workload's effective shape. Optional storage and network ceilings belong in the same minimum comparison when those resources are explicitly modeled.
Placement is not perfectly divisible. Anti-affinity, topology spread constraints, taints, selectors, uneven zones, and leftover fragments of CPU and memory can strand capacity. Planning allowances can discount the ideal pool, but they remain estimates rather than scheduler rules. The final replica ceiling should be checked against real pending pods, scheduler events, zone distribution, autoscaling policy, and a maintenance drill.
How to Use This Tool:
Model one homogeneous worker pool and one representative pod shape using scheduler-visible requests rather than usage averages.
- Choose a Workload profile only as an editable starting point. Enter schedulable worker count plus allocatable CPU, memory, and maximum pod slots per node; exclude cordoned or incompatible nodes.
- Enter average pod CPU and memory requests. Add sidecar, runtime, and other repeated pod overhead separately when those costs are not already included in the average.
- Set reserve, target utilization, rollout maxSurge, availability zones, tolerated node failures, and PDB minAvailable. These assumptions reduce the healthy ceiling into scenario-specific safe targets.
- Open advanced inputs when DaemonSets, topology constraints, imperfect bin packing, ephemeral storage, or pod-subnet addresses can bind. Use zero only for optional dimensions that are intentionally not modeled.
- Read Capacity plan to identify the limiting resource, then inspect Resilience checks. Use the smallest scenario target and verify it with actual scheduler predicates before changing a Deployment replica count.
Interpreting Results:
Safe replica ceiling is the smallest target across healthy rollout, selected node loss, largest-zone loss when more than one zone is modeled, and the percentage PDB check. The named Binding policy explains which scenario reduced the answer most.
- Read Limiter separately from Binding policy. CPU may be the smallest healthy resource while largest-zone loss is the scenario that sets the final replica target.
- Rollout peak pods includes the rounded-up surge count. Confirm that the current Deployment uses the same percentage semantics before relying on the result.
- A non-negative Desired replica goal gap means the goal fits below the modeled ceiling. It does not prove that labels, taints, volumes, affinities, or real zone placement allow every pod to schedule.
- A PDB check covers voluntary evictions. Node crashes and other involuntary disruptions can still reduce availability below minAvailable.
Technical Details:
Each active-node scenario builds independent CPU, memory, pod-slot, optional storage, and optional network ceilings. The steady capacity is the smallest active ceiling. A surge adjustment then converts steady pod capacity into a safe desired replica target.
Formula Core:
Resource budgets first subtract per-node DaemonSet requests and then apply reserve, utilization, topology, and fragmentation factors. Pod requests include any entered per-pod overhead.
| Symbol | Meaning | Unit |
|---|---|---|
| N | Active nodes in the scenario | count |
| A, D | Allocatable per node and repeated DaemonSet request per node | vCPU or GiB |
| R, O | Average pod request and added pod overhead | vCPU/pod or GiB/pod |
| r, u, t, f | Reserve, target utilization, topology reserve, and fragmentation allowance | percent |
| s | Deployment maxSurge | percent |
Memory uses the same resource equation with GiB values. Pod slots subtract DaemonSet pod count and apply utilization, topology, and fragmentation factors but not the general resource reserve. Ephemeral storage participates only when both allocatable storage and effective pod storage request are greater than zero.
Scenario Rule Core:
| Scenario | Active pool | Safe-target rule |
|---|---|---|
| Healthy rollout | All entered worker nodes | floor(steady capacity ÷ surge multiplier) |
| Selected node loss | Worker nodes − failed nodes | Recalculate all ceilings, then apply surge |
| Largest-zone loss | Worker nodes − ceiling(nodes ÷ zones) | Assumes the largest zone holds the rounded-up share |
| PDB floor | Smaller steady capacity after node or zone loss | floor(failure capacity ÷ minAvailable ratio) |
A percentage maxSurge is rounded up when reporting peak rollout pods. Percentage maxUnavailable is rounded down for the modeled unavailable count. Percentage PDB minAvailable is rounded up to report the pods that must remain available.
Accuracy Notes:
The profile values and reserve factors are planning assumptions, not Kubernetes defaults or provider guarantees. The model treats the pool as homogeneous and uses average pod requests. It does not reproduce scheduler bin packing, node affinity, topology-spread skew, taints and tolerations, storage topology, persistent-volume attachment limits, autoscaler behavior, priority and preemption, quota, or per-zone subnet differences.
- Use allocatable values from current nodes and requests from representative pod specifications.
- Compare the largest-zone estimate with actual node distribution; uneven zones can lose more or less capacity.
- Run a rollout and drain test in a representative environment before treating the ceiling as an operating limit.
Worked Examples:
Twelve workers across three zones
With 12 workers, 14 allocatable vCPU per node, 0.35 vCPU requested per pod, an 18% reserve, 76% target utilization, and 25% surge, CPU is the healthy limiter at 299 steady pods. The healthy rollout target is 239 replicas. One-node loss lowers it to 219, while the even-split largest-zone loss leaves 8 nodes and a target of 159. The final ceiling is therefore 159 replicas, bound by the zone-loss scenario rather than the healthy CPU total.
References:
- Resource Management for Pods and Containers, Kubernetes Documentation.
- Reserve Compute Resources for System Daemons, Kubernetes Documentation, updated December 2025.
- Update a Deployment Without Downtime, Kubernetes Documentation.
- Specifying a Disruption Budget for your Application, Kubernetes Documentation.
- How to scale a Kubernetes Deployment, Simplified Guide.
- How to cordon and drain a Kubernetes node, Simplified Guide.