Cluster Autoscaler - Stop Manually Scaling Kubernetes Nodes Like It's 2015

The Kubernetes Cluster Autoscaler is an open-source component that automatically adjusts the size of a Kubernetes cluster based on workload demands. As of late 2025, we're running 1.32.x in production - don't use bleeding edge unless you enjoy debugging at 3am. This version includes DRA support improvements, parallelized cluster snapshots, and the default expander changed to least-waste (which actually works better than random, shocking).

Maintained by SIG Autoscaling, this thing watches for pods that can't get scheduled and spins up nodes. When nodes sit empty burning money, it kills them. Simple concept, complex execution that will make you question your life choices.

Your clusters are either burning money on empty nodes or failing to schedule pods when you actually need capacity. There's no middle ground. Manual scaling means paying someone to watch dashboards 24/7 and make capacity decisions. Static provisioning means either over-provisioning (expensive) or under-provisioning (downtime). The autoscaler attempts to thread this needle automatically.

It talks to AWS, GCP, or Azure APIs to spin up and terminate instances. The "simulation" sounds impressive until you figure out it's just checking if your pod requirements match available node types before actually doing anything. Works great until your spot instances disappear mid-scale.

How This Thing Actually Works

You have to pre-configure every fucking node type you might want through node groups. It can't just create the perfect instance for your workload - you're stuck manually configuring every possible server combo you might need. Each node group maps to cloud constructs like AWS ASGs, GCP instance groups, or Azure VM Scale Sets.

Every 10 seconds this thing checks for stuck pods and decides whether to burn more money on new nodes. It scales on what pods ask for, not what they actually use, so a pod requesting 4 CPU cores but using 200m still triggers massive scale-ups. Get your resource requests wrong and you're fucked.

What Actually Breaks (And Will Ruin Your Weekend)

Scaling Takes Forever: AWS says 2-5 minutes but I've waited 12 minutes for a single t3.medium during a fucking Tuesday afternoon. GCP is faster but fails weirder. Scale-down takes 30+ minutes because it's terrified of killing anything important.

API Rate Limits: Hit AWS scaling limits during traffic spikes? Your autoscaler just stops working while your app melts down. The error just says "failed to update" - thanks AWS, real useful.

Spot Instance Chaos: Your "cost-optimized" spot instances disappear during Black Friday, leaving pods stuck pending while the autoscaler tries to replace nodes that no longer exist. We learned this the hard way.

The Node Group Configuration Hell: Miss one instance type configuration and watch pods sit pending because the autoscaler can't provision the right resources. GPU workloads are especially brutal - you need separate node groups for every GPU type.

This is why I use Karpenter now - got tired of waiting 7+ minutes for nodes. Here's how it compares to alternatives so you can pick your poison.

The Cluster Autoscaler runs as a Deployment in kube-system, and here's the fun part: it's not horizontally scalable. One replica only. Leader election exists but you still get a single point of failure for your entire cluster's scaling. If this pod crashes during a traffic spike, your cluster stops scaling until it restarts.

Cloud Provider Integration

Every cloud provider screws this up differently:

• AWS: Talks to Auto Scaling Groups and EKS managed node groups. Works until you hit service quotas or API rate limits during peak scaling.
• GCP: Uses Instance Groups and GKE node pools. Faster than AWS but occasionally just fails silently with quota exceeded errors.
• Azure: Integrates with VM Scale Sets and AKS node pools. The most unpredictable of the big three - sometimes takes 15+ minutes to provision nodes.
• 15+ others: Including DigitalOcean, Hetzner, OpenStack, each with their own special ways to fail.

How Scaling Decisions Actually Work

The "simulation" sounds fancy until you understand it's just checking if your pod requirements match available node types before doing anything:

1. Scale-up logic: Finds pending pods and figures out which node group can fit them. If none match, pods stay pending forever.
2. Node selection: Uses your expander policy (random, least-waste, priority) to pick which node group gets scaled. The "least-waste" default actually works better than random.
3. Scale-down checks: Waits for the scale-down-delay-after-add (default 10 minutes), then checks if nodes are underutilized and can safely drain their workloads.

This process prevents some stupid decisions but still fails spectacularly when your resource requests are wrong or your pod disruption budgets are too restrictive.

What Actually Happens In Production

Those parallelized cluster snapshots in recent versions help with evaluation speed, but the real bottleneck is still your cloud provider APIs. Large clusters (1000+ nodes) work better now, but you're still limited by API quotas and the fundamental physics of spinning up VMs.

Real scaling times (not their marketing bullshit):

• AWS: They say 3-7 minutes but I've waited 12 minutes for a t3.medium on a random Tuesday
• GCP: Usually 2-4 minutes but quota errors come out of nowhere
• Azure: 5-15 minutes and completely unpredictable - sometimes fast, sometimes you're waiting forever
• Scale-down: 30+ minutes because it's paranoid as hell about everything

The stuff that breaks:

• Node stuck terminating: Nodes get stuck in "terminating" state for 20+ minutes while pods can't schedule anywhere else. Usually caused by DaemonSets without proper tolerations or pods with local storage that can't be evicted.
• API rate limits: We hit the 5 req/sec AWS limit during Black Friday and scaling just stopped. No warnings, no alerts, just silence while everything burned.
• Memory pressure during evaluation: The autoscaler itself can OOM on very large clusters (1000+ nodes). Set resource limits of at least 300MB for clusters over 100 nodes, 1GB+ for huge clusters. The parallelized snapshots in recent versions help but don't eliminate this.
• Spot instance interruptions: 2-minute warnings aren't enough time to gracefully handle pod rescheduling. You need Node Termination Handler or similar tooling to properly drain nodes before they disappear.
• Resource fragmentation: Large clusters get fragmented allocation that wastes resources. Small pods steal nodes that bigger workloads need. The least-waste expander helps but doesn't fix the core problem.

OK, so it breaks in predictable ways. Here's the questions you'll be googling at 3am: