The Cluster Autoscaler Won't Save Bad Requests and Limits

The cluster autoscaler gets installed with a hopeful theory: "our capacity is unpredictable, so let the cluster size itself." Then the bill goes up, nodes sit half-empty, and pods still occasionally won't schedule. The autoscaler isn't broken. It's doing exactly what you told it, using numbers you made up.

Here's the mechanism people skip. The cluster autoscaler adds a node when pods are unschedulable because of their resource requests, and removes a node when pods could be packed elsewhere, again by requests. It never looks at what your pods actually use. It scales on the contract, not the reality.

So the failure modes are entirely about your requests:

• Requests set too high (the usual case, where someone copied a generous number "to be safe"). The scheduler thinks nodes are full when they're 30% used, the autoscaler dutifully buys more nodes to hold air, and you pay for capacity doing nothing.
• Requests missing entirely. The scheduler is gambling, the autoscaler is half-blind, and you get node pressure, evictions, and pods that won't place, while the autoscaler can't reason about pods that didn't ask for anything.

The autoscaler is a multiplier. Point it at good requests and it quietly right- sizes your cluster. Point it at fiction and it scales the fiction, faster, and with a real invoice attached.

So the order of operations matters: right-size requests against measured usage first, then turn on autoscaling. Look at what pods actually consume, set requests near that with honest limits, and only then let the cluster size itself. Reach for the Vertical Pod Autoscaler's recommendations if you want help finding the numbers.

Autoscaling doesn't fix a cluster that doesn't know what its workloads need. It faithfully automates whatever you believe, so it's worth making sure you believe something true.