Advanced Disciplines
HPA, VPA, and the Limits of Elasticity
Elasticity is not free. It is a control system built on noisy signals and hard limits.
Text
Authored as doctrine; evaluated as operations.
Doctrine
Autoscaling is a control loop. Like any loop, it can oscillate, saturate, and destabilize upstream systems.
Kubblai doctrine: scaling policies must be governed, observed, and bounded.
HPA realities
HPA depends on metric quality and delay. If your metrics are late, smoothed, or missing, scaling decisions become guesswork.
Scaling up can cause new bottlenecks (DB, caches, queues). Scaling down can create latency spikes.
- Use stabilization windows.
- Set maxReplicas as a safety rail.
- Scale on signals tied to SLOs, not vanity metrics.
VPA realities
VPA can improve request accuracy but may require restarts depending on mode. It can fight HPA if misapplied.
Use VPA where restarts are acceptable and behavior is well understood.
Elasticity has limits
CPU is not always the limiting resource. Network, storage IOPS, external APIs, and database locks do not scale linearly. Elasticity must respect the constraints of the system.
A platform that scales compute into a fixed backend is manufacturing failure.
Canonical Link
Canonical URL: /library/hpa-vpa-and-the-limits-of-elasticity
Related Readings
Advanced Disciplines
LibraryThe Scheduler and the Ethics of Placement
Placement is policy made physical. When you schedule, you are allocating failure domains, cost, and contention.
Advanced Disciplines
LibraryCluster Autoscaling and the Economics of Expansion
Adding nodes is not ‘scale.’ It is a controlled expansion of failure domains, cost, and operational surface area.
Canonical Texts
LibraryIncident Response as a Trial of Faith
Incidents reveal the true governance of your platform: who can act, what can be changed, and whether your system can recover with discipline.