Why does the autoscaler keep swinging between too many workers and too few? Load doubles for thirty seconds, and an autoscaler sizes the pool to keep it 60% busy. With a stale metric and slow start-up it overshoots, then swings from 2 workers to 32 and back long after the load has settled. The demo needs JavaScript.
It multiplies the workers it has now by a utilisation measured before its last change landed. While new workers are still starting, the old metric says "still overloaded", so it asks again, and again. Then the fresh metric shows a pool far too big, and it cuts just as hard.
The load is steady from 40 s, and the stale run swings anyway. A full correction every interval is only stable if the controller sees the result of its last action before it makes the next one. Metric lag, scrape intervals, averaging windows and start-up time all add to that delay.
A cooldown longer than metric lag plus start-up time lets each action show up before the next. Real autoscalers go further: Kubernetes scales down on the highest recommendation of the last five minutes, so a brief lull cannot strip the pool. The cost is a slower response, so keep headroom for the ramp.
All demos