Cluster Autoscaler Calculator
Calculate how many nodes the Cluster Autoscaler will add or remove under load.
About Cluster Autoscaler Calculator
When pods can't be scheduled due to insufficient cluster capacity, the Cluster Autoscaler estimates how many nodes to add: nodes_needed = ceil(pending_pods × pod_request ÷ (node_capacity × scale_up_threshold)). The scale-up threshold leaves intentional headroom on new nodes rather than packing them to exactly 100%, reducing the chance of an immediate second scale-up event.
Formula
nodesNeeded = ceil(pendingPods × podRequest / (nodeCapacity × scaleUpThreshold%))
- P
- Number of pending pods
- R_p
- Per-pod CPU request in millicores
- C_n
- Node CPU capacity in millicores
- U
- Scale-up threshold percentage
- N
- New nodes needed
Worked example
With the default values below, Cluster Autoscaler Calculator returns New Nodes Needed of 7. Change any input above and every figure here is recalculated in your browser.
Inputs used
- Pending Podsaccepts 0–1,000,000 pods
- 40 pods
- Pod CPU Requestaccepts 1–64,000 millicores
- 500 millicores
- Node CPU Capacityaccepts 1–512,000 millicores
- 4,000 millicores
- Scale-Up Thresholdaccepts 1–100 %
- 80 %
Results
- New Nodes Needed
- 7 nodes
- Pods per New Node
- 6 pods
- Projected Utilization After Scale-Up
- 71.4%
- Total Pending CPU Demand
- 20,000 millicores
Step by step
- 1Total pending CPU demand= 20,000m
- 2Usable capacity per node= 3200m
- 3Nodes needed: ceil(pending × request ÷ usable capacity)= 7 nodes
Assumptions and limits
- The result is derived only from the 4 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
- Figures are rounded for display to 1 decimal place, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.
How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.
Frequently Asked Questions
Why does the Cluster Autoscaler leave headroom on new nodes?
Packing nodes to exactly 100% at scale-up time leaves no room for pod overhead, DaemonSets, or slight scheduling variance, which can trigger another scale-up almost immediately — a lower threshold avoids this churn.
What if pending pods have different resource requests?
Use a weighted average request size across all pending pods, or run this calculation separately for each distinct pod resource profile / node group combination for more accuracy.
Does the Cluster Autoscaler scale down as aggressively?
No — scale-down uses a longer evaluation window (default 10 minutes of low utilization) and respects pod disruption budgets, so scale-down is intentionally more conservative than scale-up.
How does node instance type affect this calculation?
Larger instance types raise node_capacity, reducing nodes_needed but increasing the 'blast radius' if a single node fails — there's a tradeoff between bin-packing efficiency and fault isolation.