Autoscaling

Autoscaling in Kubernetes is a control loop stacked on a control loop: the HPA watches a metric and adjusts replica count, the scheduler places those replicas, and the cluster autoscaler watches for unschedulable pods and adds nodes. Every layer depends on the one below reporting truthfully — an HPA scaling on a metric that doesn't reflect real load, or replicas whose requests don't reflect real usage, produces scaling decisions that look active but don't fix anything.

Autoscaling amplifies whatever signal you point it at — a good signal gives you elastic capacity, a bad one gives you expensive noise. Get requests right first; every autoscaler downstream is only as accurate as the numbers it's reading.

1. Scale on the metric that actually predicts saturation

CPU utilization is the default HPA metric because it's always available, not because it's usually the right one. A queue-processing service saturates on queue depth; an API saturates on request latency or in-flight requests; a memory-bound service doesn't reflect load in CPU at all. Scaling on the wrong metric means the HPA reacts late or not at all to the thing that's actually hurting users.