How Does the Kubernetes Cluster Autoscaler Work?
Learn how the Kubernetes Cluster Autoscaler adds and removes nodes, respects PodDisruptionBudgets, and differs from HPA and VPA.
Expected Interview Answer
The Cluster Autoscaler adjusts the number of nodes in a Kubernetes cluster itself — adding a node when Pods are stuck Pending due to insufficient capacity, and removing an underutilized node when its Pods could be safely rescheduled elsewhere.
On scale-up, the Cluster Autoscaler watches for Pods the scheduler cannot place because no existing node satisfies their resource requests, simulates whether adding a node from a configured node group would let that Pod schedule, and if so calls the cloud provider’s API to provision a new node, which then joins the cluster and runs the kubelet as normal. On scale-down, it periodically identifies nodes whose Pods could all be rescheduled onto other nodes and whose utilization is below a threshold for a sustained period, cordons that node to stop new Pods landing on it, drains it by evicting existing Pods respecting PodDisruptionBudgets, and then terminates the underlying instance. It explicitly respects PodDisruptionBudgets, node affinity, taints, and Pods with local storage or without a controller, and will refuse to scale down a node hosting a Pod that cannot be safely evicted. Cluster Autoscaler is distinct from HPA and VPA: those two decide how many/how big Pods should be given the current nodes, while Cluster Autoscaler decides how many nodes should exist to satisfy what HPA/VPA have already asked for.
- Automatically provisions capacity so Pending Pods can eventually schedule
- Removes idle nodes to control infrastructure cost
- Respects disruption budgets and safety constraints during scale-down
- Complements HPA/VPA by supplying the node capacity they assume exists
AI Mentor Explanation
The cluster autoscaler is like a tournament organizer who opens a brand-new ground when every existing stadium is fully booked and a match genuinely cannot be scheduled anywhere. When usage across several grounds later drops for a stretch, the organizer relocates the remaining fixtures to other stadiums, checks no live match is still in progress there, and then decommissions that extra ground to save costs. This is different from a selector adding more players to a squad — the organizer is deciding how many grounds exist in the first place, while the selector decides how many players fill them.
Step-by-Step Explanation
Step 1
Detect Pending Pods
The autoscaler notices Pods the scheduler cannot place on any current node due to insufficient resources.
Step 2
Simulate and provision
It simulates whether a new node from a configured group would fit the Pod, then calls the cloud provider API to add one.
Step 3
Monitor utilization for scale-down
It identifies sustained low-utilization nodes whose Pods could reschedule elsewhere.
Step 4
Cordon, drain, terminate
It cordons the node, evicts Pods respecting PodDisruptionBudgets, then terminates the underlying instance.
What Interviewer Expects
- Understanding scale-up is triggered by unschedulable (Pending) Pods, not raw CPU%
- Knowledge of the cordon/drain/terminate sequence for scale-down
- Awareness that PodDisruptionBudgets and local-storage Pods can block scale-down
- Ability to distinguish Cluster Autoscaler from HPA/VPA responsibilities
Common Mistakes
- Confusing Cluster Autoscaler with HPA (nodes vs Pod replicas)
- Assuming it reacts to CPU utilization directly rather than Pending Pods
- Forgetting PodDisruptionBudgets can block a node from scaling down
- Not knowing it needs cloud-provider-specific node group/pool configuration
Best Answer (HR Friendly)
“The Cluster Autoscaler manages the number of actual machines in the cluster, not the number of Pods. When Pods cannot be scheduled anywhere because we are out of capacity, it adds a new machine automatically. When machines are sitting mostly idle for a while and their workloads could safely move elsewhere, it drains and removes them to keep our cloud bill in check.”
Code Example
# Check for Pending Pods that may trigger scale-up
kubectl get pods --all-namespaces --field-selector=status.phase=Pending
# Inspect why a Pod cannot be scheduled
kubectl describe pod my-app-xyz | grep -A5 Events
# View cluster-autoscaler logs (deployed in kube-system)
kubectl logs -n kube-system deployment/cluster-autoscaler --tail=100
# Check node group scaling annotations
kubectl get nodes -o jsonpath="{.items[*].metadata.labels.eks\.amazonaws\.com/nodegroup}"Follow-up Questions
- What stops the Cluster Autoscaler from removing a node with a local-storage Pod?
- How does PodDisruptionBudget influence a scale-down decision?
- How does Cluster Autoscaler differ from Karpenter-style node provisioning?
- What happens if a Pod requests more resources than any node type can ever provide?
MCQ Practice
1. What primarily triggers a Cluster Autoscaler scale-up?
Cluster Autoscaler reacts to unschedulable Pods, simulating whether a new node would let them be placed, not raw utilization percentages.
2. What can prevent a node from being scaled down even if it is underutilized?
Cluster Autoscaler respects PodDisruptionBudgets and will not evict Pods in a way that would violate them, blocking scale-down.
3. How does Cluster Autoscaler differ from HPA?
HPA adjusts how many Pod replicas run; Cluster Autoscaler adjusts how many nodes exist to host whatever Pods need to run.
Flash Cards
What triggers Cluster Autoscaler scale-up? — Pods stuck Pending because no current node has capacity.
What is the scale-down sequence? — Cordon the node, drain it respecting PodDisruptionBudgets, then terminate it.
How does it differ from HPA/VPA? — It changes node count; HPA/VPA change Pod replica count or Pod size.
What can block scale-down? — PodDisruptionBudgets, local storage, or Pods without a controller.