With Kubernetes v1.37, developers can now leverage native HorizontalPodAutoscaler (HPA) capabilities to scale workloads all the way down to zero replicas using external or object metrics. This foundational change eliminates the need for add-ons or alpha feature gates and is enabled by default, promising substantial cloud resource savings and more efficient batch or queue-based processing.
- Native support for scaling workloads to zero using external/object metrics
- Significant cloud resource and cost savings for batch and queue consumers
- Requires durable queue or external buffering for request-driven workloads
Infrastructure signal
Kubernetes v1.37 has integrated HorizontalPodAutoscaler support to scale workloads down to zero replicas by default, moving this capability out of alpha and into the core API. Before this release, scaling from zero required supplemental components or manual feature gating. The new method depends on external or object metrics that exist independent of active pods, such as queue length, enabling autoscaling decisions even when no pods are running.
This feature is especially beneficial for workloads that reserve costly resources like dedicated CPUs or GPUs, allowing removal of idle pods to cut infrastructure spend significantly. The trade-off is increased cold-start delays when scaling back up, as new pods must be scheduled and initialized after a period of zero instances. Kubernetes Services do not buffer requests during scale-to-zero states for HTTP and similar workloads, necessitating separate buffering mechanisms.
Developer impact
For developers, this update streamlines autoscaling configurations by eliminating reliance on external systems or alpha gates to achieve scale-to-zero behavior. External metrics adapters like Prometheus Adapter remain critical to expose queue length or similar metrics through the External Metrics API for HPA consumption. This approach allows precise control of minimum and maximum replica counts and smoother scaling transitions guided by configurable stabilization windows.
Deployment management practices need adjustments, as scaling to zero through HPA means workloads must start with at least one replica manually and that manual zero scaling will pause autoscaling. Developers should prepare for longer cold-start intervals post-scaling and design application workflows tolerant to delayed pod spin-up, particularly for long-wait queue consumers. Careful tuning of scale-down behavior ensures stability during transient workload drops.
What teams should watch
Platform and operations teams should focus on implementing robust external metrics pipelines, especially securing reliable Prometheus adapters or equivalent systems, since missing metrics will prevent scaling from zero and impact availability alerts through active HPA status conditions. Clear observability into these metrics and HPA scaling decisions is critical to maintaining workload reliability and cost control.
Teams responsible for HTTP and request-driven services must assess buffering strategies to handle request queuing outside of Kubernetes Services when pods scale down fully. Additionally, development and devops teams should update deployment automation and monitoring to differentiate between manual pauses and HPA-driven zero replicas, understanding the ScaledToZero status conditions to avoid unnecessary manual intervention or confusion during autoscaling evaluation.