The Classic Use Case
Cloud autoscaling — like Kubernetes Horizontal Pod Autoscaler (HPA) or AWS Auto Scaling Groups — is the most common application of these concepts in software. Let's map the control theory vocabulary directly onto a real system:
| Control Theory Term | Autoscaling Equivalent |
|---|---|
| Setpoint (SP) | Target CPU Utilization = 50% |
| Process Variable (PV) | Average CPU across all current pods |
| Error | targetCPU − currentCPU |
| Controller | HPA scaling algorithm |
| Control Variable (CV) | Number of replicas to run |
| Disturbance | A sudden traffic spike |
Kubernetes HPA in Practice
The HPA controller runs on a configurable loop (default: every 15 seconds). Each cycle it:
1. Queries the metrics server for current CPU utilization.
2. Computes desiredReplicas = ceil(currentReplicas × (currentMetric / desiredMetric)).
3. Applies the new replica count, subject to min/max bounds.
A Kubernetes HorizontalPodAutoscaler object expresses this declaratively: it names the target Deployment, sets a minReplicas/maxReplicas bound, and lists the resource metric to track — for example, CPU utilization with a target of 50%, which is the setpoint.
Preventing Flapping: Stabilization Windows
A naive proportional controller would scale down the moment CPU drops, then scale up again when the next request burst hits — a phenomenon called flapping. Kubernetes addresses this with stabilization windows: the HPA will not scale down unless the recommendation to scale down has been stable for a configurable window (default: 5 minutes). This is a practical approximation of derivative dampening — it prevents reacting to transient dips.
Tuning autoscalers involves real trade-offs: a fast-reacting scaler (high P-gain, short stabilization window) responds quickly to spikes but risks flapping and over-provisioning costs. A slow-reacting scaler is cheaper but may let latency spike during sudden load increases. The right balance depends on your traffic patterns and cost constraints.