HPA Scale to Zero Is Not a Cost Setting
Kubernetes can now scale selected workloads to zero through the HorizontalPodAutoscaler. Treating this as a simple efficiency setting ignores the operational contract required to restore capacity.
Zero replicas are safe only when demand remains observable without running Pods, queued work survives the delay, and failed scale-up has an owned recovery path.
What matters
- Durable demand: Use external or object metrics backed by a source that retains work. CPU and memory cannot signal demand when no Pod exists.
- Cold-start budgets: Include metric collection, controller reconciliation, scheduling, image pulls, and application readiness in the acceptable processing delay.
- Buffering boundaries: Queue consumers are natural candidates. Request-driven services need an upstream component that can hold or reject traffic predictably.
- Failure visibility: Alert on unavailable metrics, stalled queues, unschedulable Pods, and readiness failures. A zero replica count alone does not distinguish efficiency from outage.
- Clear ownership: Platform teams own supported scaling patterns and metric reliability. Service teams own startup behavior, backlog limits, and recovery expectations.
Recommendation
Offer scale-to-zero as a standardized workload class, not an unrestricted HPA option. Define eligible demand sources, maximum activation latency, fallback capacity, and manual recovery before adoption.
The useful abstraction is not zero idle Pods. It is a reproducible event-driven operating model that can recreate service capacity when demand returns.