How to autoscale Kubernetes nodes with the Cluster Autoscaler
The Cluster Autoscaler adds nodes when pods cannot be scheduled and removes underused ones, working alongside the HPA. Set pod requests, configure node-group bounds, and tune scale-down with PodDisruptionBudgets.
Autoscaling nodes with the Cluster Autoscaler
The HorizontalPodAutoscaler scales pods, but pods need nodes to run on. The Cluster Autoscaler watches for pods that cannot be scheduled due to insufficient capacity and adds nodes; it removes nodes that stay underused. It integrates with cloud node groups on EKS, AKS, and GKE.
Prerequisites
- A managed Kubernetes cluster with one or more node groups.
- Cloud IAM permissions for the autoscaler to resize node groups.
Steps
1. Understand node vs pod autoscaling
The HPA changes replica count; the Cluster Autoscaler changes node count. They work together: more pods may require more nodes.
2. Configure an autoscaling node group
Set minimum and maximum sizes on the node group, for example min 2 and max 10. On GKE this is often a single flag; on EKS and AKS you configure the node group plus the autoscaler.
3. Deploy the Cluster Autoscaler
Deploy the autoscaler matching your Kubernetes version, with cloud provider flags and the node-group discovery configuration appropriate for your platform. Grant it permission to modify node groups.
4. Set pod requests to drive scaling
The autoscaler relies on resource requests to decide whether a pod fits. Always set requests; otherwise scheduling and scaling decisions are unreliable.
5. Trigger scale-up
Scale a Deployment beyond current capacity:
kubectl scale deployment myapp --replicas=50
kubectl get pods | grep Pending
Pending pods cause the autoscaler to add nodes; watch with kubectl get nodes --watch.
6. Tune scale-down
Control how aggressively nodes are removed with flags like the scale-down utilization threshold and delay. Protect critical pods with a PodDisruptionBudget so scale-down does not break availability.
Verification
Scale workloads up and confirm new nodes join via kubectl get nodes. Inspect the autoscaler logs to see scale-up decisions. Scale workloads back down and confirm underused nodes are drained and removed after the configured delay.
Next Steps
Combine the Cluster Autoscaler with the HPA for end-to-end elasticity, evaluate Karpenter for faster, more flexible provisioning on AWS, and use spot or preemptible node groups to cut cost.
Prerequisites
- A managed cluster with node groups
- Cloud IAM permissions
- kubectl access
Steps
- 1Understand node vs pod autoscaling
- 2Configure an autoscaling node group
- 3Deploy the Cluster Autoscaler
- 4Set pod requests to drive scaling
- 5Trigger scale-up
- 6Tune scale-down