Skip to main content

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.

Difficulty
Advanced
Duration
45 minutes
Steps
6

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

  • 1
    Understand node vs pod autoscaling
  • 2
    Configure an autoscaling node group
  • 3
    Deploy the Cluster Autoscaler
  • 4
    Set pod requests to drive scaling
  • 5
    Trigger scale-up
  • 6
    Tune scale-down

Category

Cloud