Kubernetes 1.37 makes scale-to-zero part of the built-in HorizontalPodAutoscaler path. The HPAScaleToZero feature is now beta and enabled by default in both the API server and controller manager, so queue consumers and batch workers can release their last idle Pod without a separate event-driven autoscaler.
What changed
Before 1.37, scaling an HPA-managed workload from zero required an add-on, an external component, or an alpha feature gate. The beta implementation accepts minReplicas: 0 when the HPA uses an object or external metric that remains observable after every Pod has stopped. A new ScaledToZero condition lets the controller distinguish an automatic scale-down from an operator who manually paused a workload.
The practical consequence
Workloads backed by durable queues can stop reserving their final idle CPU or GPU. That can lower infrastructure cost when the freed capacity is actually reclaimed—for example, when a node autoscaler can remove an empty node. Kubernetes itself does not guarantee a smaller cloud bill merely because the Pod count reaches zero.
Where it does not fit
CPU and memory metrics disappear with the Pods they measure, so they cannot wake a zero-replica workload. Operators need an object or external metric plus a functioning metrics adapter. Kubernetes Services do not buffer requests while no Pods are ready, which makes direct HTTP workloads unsuitable without a separate buffering layer. Cold-start time also remains: the HPA must observe demand, schedule a Pod, and start the application.
Upgrade limits
The feature is beta, not generally available. During a version-skewed control-plane upgrade, both the API server and controller manager must support and enable it before an HPA uses minReplicas: 0. Before disabling the gate or rolling back, operators must raise the minimum replica count and restart any workload already at zero. A manually scaled-to-zero Deployment remains paused rather than being awakened by the HPA.
Benchmark status
The Kubernetes project did not publish a performance or cost benchmark with this announcement. Any savings will depend on workload shape, cold-start latency, resource requests, the metrics pipeline, and whether underlying cluster capacity is released. There is therefore no vendor benchmark here to treat as independently reproduced.