What Is Cluster Autoscaling?
The Cluster Autoscaler (CA) adds or removes worker nodes from a cluster based on whether there are Pods that cannot be scheduled due to insufficient resources, and whether existing nodes are underutilized enough to be safely drained and removed. Unlike HPA and VPA, which operate on Pods within existing node capacity, CA operates at the infrastructure layer, calling cloud-provider APIs (Auto Scaling Groups on AWS, VMSS on Azure, or Managed Instance Groups on GCP) to actually provision or terminate virtual machines. It is the piece that lets HPA scale a Deployment past whatever capacity currently exists in the cluster.
Cricket analogy: It is like a franchise's front office signing an additional player from the transfer market when the existing squad genuinely cannot cover an injury crisis, versus the captain merely rotating the players already on the roster, which is what HPA does within existing capacity.
The Scale-Up and Scale-Down Loop
On scale-up, CA runs a loop (default every 10 seconds) checking for Pods in Pending state with a FailedScheduling event, then simulates whether adding a node from a configured node group would let the scheduler place them, taking into account taints, tolerations, node affinity, and topology spread constraints, not just raw CPU/memory. If a node group's simulated addition would fit the pending Pods, CA calls the cloud provider API to increase that group's desired size. On scale-down, CA identifies nodes whose Pods could all be rescheduled elsewhere (respecting PodDisruptionBudgets) and whose utilization has stayed below a threshold (default 50%) for a sustained period (default 10 minutes), then cordons and drains that node before terminating the underlying instance.
Cricket analogy: It is like team management running a check before every session on whether any net-bowler slot is unfilled, and only signing a new net bowler if the simulated roster with that addition would actually cover the gap, then later releasing a net bowler only after confirming for a sustained period they are not needed.
# Example: constraining which node groups CA can scale, via annotations on
# an autoscaling group / node pool (cloud-provider specific tags)
# AWS ASG tags:
# k8s.io/cluster-autoscaler/enabled = true
# k8s.io/cluster-autoscaler/my-cluster = owned
# k8s.io/cluster-autoscaler/node-template/label/workload-type = gpu
apiVersion: v1
kind: Pod
metadata:
name: gpu-training-job
spec:
nodeSelector:
workload-type: gpu
tolerations:
- key: "nvidia.com/gpu"
operator: "Exists"
effect: "NoSchedule"
containers:
- name: trainer
image: my-registry/trainer:latest
resources:
requests:
cpu: "4"
memory: 16Gi
nvidia.com/gpu: "1"Expanders and Multi-Node-Group Clusters
When a cluster has multiple node groups that could all satisfy a pending Pod, CA uses an 'expander' strategy to choose which one to grow: least-waste picks the group that would leave the least unused CPU/memory after the Pod is placed, random picks arbitrarily to spread risk across zones, most-pods picks the group that can schedule the largest number of pending Pods, and priority lets operators rank node groups explicitly, useful for preferring cheaper spot-instance groups before falling back to on-demand groups.
Cricket analogy: It is like a selector choosing which reserve player to call up from several eligible options, sometimes picking whoever fits the exact gap left with least disruption to the rest of the squad, similar to the least-waste strategy choosing the node group that leaves the least idle capacity.
Cluster Autoscaler only reacts to Pending Pods and low node utilization; it does not know about future demand. For predictable spikes like a product launch, combine CA with a scheduled scale-up of node group minimums, or a low-priority 'placeholder' Deployment that reserves headroom capacity and gets preempted when real workloads need it.
CA respects PodDisruptionBudgets when draining a node for scale-down, but Pods without a controller (bare Pods), Pods using local storage, and Pods in kube-system without a safe-to-evict annotation can block a node from ever being scaled down. Audit these before relying on CA to reclaim cost.
- Cluster Autoscaler adds/removes nodes; HPA/VPA operate within existing node capacity.
- Scale-up triggers on unschedulable (Pending) Pods; scale-down triggers on sustained low node utilization.
- CA simulates scheduling, accounting for taints, affinity, and topology spread, not just raw resource totals.
- Scale-down respects PodDisruptionBudgets and drains nodes gracefully before termination.
- Expanders (least-waste, random, most-pods, priority) decide which node group grows when several qualify.
- CA cannot predict future demand; scheduled spikes need proactive strategies like placeholder Pods.
- Certain Pods (bare Pods, local storage, unevictable kube-system Pods) can block scale-down entirely.
Practice what you learned
1. What condition triggers a Cluster Autoscaler scale-up event?
2. What is the default utilization threshold and duration CA uses before considering a node for scale-down?
3. Which of the following can block Cluster Autoscaler from scaling down a node?
4. What does the 'priority' expander strategy allow operators to do?
5. Why is Cluster Autoscaler alone insufficient for a predictable traffic spike like a product launch?
Was this page helpful?
You May Also Like
Horizontal Pod Autoscaling
Learn how Kubernetes automatically scales the number of Pod replicas in and out based on CPU, memory, and custom metrics.
Vertical Pod Autoscaling
Understand how VPA right-sizes container CPU and memory requests automatically based on observed usage history.
Node Affinity and Taints
Learn how node affinity pulls Pods toward specific nodes while taints and tolerations repel or dedicate nodes for specific workloads.