Cluster Autoscaler Calculator
Calculate how many additional nodes the Cluster Autoscaler needs to add to schedule a backlog of pending pods.
Inputs
Number of pods currently unschedulable due to insufficient capacity.
Average CPU request per pending pod.
Allocatable CPU capacity of each new node.
Target max utilization per node after scale-up, to leave headroom instead of exact packing.
New Nodes Needed
7nodes
Pods per New Node
6pods
Projected Utilization After Scale-Up
71.4%
Total Pending CPU Demand
20,000millicores
Step by step
Total pending CPU demand
40 × 500m
= 20,000m
Usable capacity per node
4000m × 80%
= 3200m
Nodes needed: ceil(pending × request ÷ usable capacity)
ceil(40 × 500 ÷ 3200)
= 7 nodes
How it works
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
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.