Kubernetes autoscaling is a control loop—not a promise of infinite capacity_

Kubernetes HPA periodically changes desired replicas from observed metrics. It cannot compensate for missing requests, slow startup, downstream limits, or a database that saturates first.

Teams often enable CPU-based scaling after a load test fails. That can multiply an inefficient workload or move the bottleneck into a dependency.

What changes in practice_

Choose a metric connected to demand, set realistic min/max bounds, test startup and scale-down behavior, and watch the full request path.

• Size requests before trusting utilization.
• Load-test the dependency chain.
• Design for scale-down as carefully as scale-up.

Our take_

The durable advantage is not adopting the newest tool first. It is building the identity, state, evidence, and operating boundaries that let a real team own the system after launch.