Kubernetes · Orchestration under pressure
How does cluster autoscaler decide to add or remove nodes?
Short answer
Cluster autoscaler adds nodes when pods are unschedulable due to insufficient resources, and removes underutilized nodes when their pods can be rescheduled elsewhere.
Cluster autoscaler watches for pending pods and simulates whether adding a node from a configured node group would make them schedulable. On scale-down it checks whether a node's pods can move and whether disruption budgets allow eviction. Providers differ in node group configuration and scaling speed.
- Pods without resource requests can prevent accurate scale-up decisions
- Node affinity and taints can make a node group ineligible
- Scale-down respects PodDisruptionBudgets and local storage constraints
- Autoscaler is not instantaneous; provisioning can take minutes
- Karpenter takes a different approach, provisioning right-sized nodes directly from pod requirements
kubectl get pods -A --field-selector=status.phase=Pending
kubectl describe pod pending-pod -n production
kubectl get nodes -o custom-columns=NAME:.metadata.name,CPU:.status.allocatable.cpuCapacity planning still matters. Set minimum node counts for baseline traffic, use overprovisioning pods for fast burst capacity, and ensure scale-down does not remove nodes that host critical daemons or local data. Autoscaling reduces waste but does not remove the need for headroom during rollouts and failures.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1What triggers cluster autoscaler to add a node?
- 2Why might scale-down be blocked?
- 3How does cluster autoscaler interact with HPA?
- 4When would Karpenter be a better choice?
Say it in the interview
Cluster autoscaler adds nodes when pending pods cannot fit, and removes nodes when their workloads can be safely moved. It respects disruption budgets and node group constraints, so it is not instant and not magic. I make sure pods have requests and that node groups match their affinity and taints. For bursty workloads I keep baseline capacity and use overprovisioning rather than relying solely on reactive scaling.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Kubernetes mock interview and get scored feedback on depth, clarity and confidence.