Kubernetes 1.37 has promoted HorizontalPodAutoscaler (HPA) scale-to-zero support to beta and enabled it by default. The change sounds small—a workload can now set minReplicas: 0—but it closes a long-standing gap in the platform’s native autoscaling model. Queue consumers, batch processors, and accelerator-backed services no longer need a permanently idle pod merely to remain visible to the built-in HPA.
The practical result is not “serverless Kubernetes” in one field. It is a narrower and more useful capability: core Kubernetes can stop an idle workload completely and later restore it when an independent demand signal appears. That can cut waste significantly for sporadic jobs and expensive GPU workers. It also moves the hard part of scale-to-zero away from replica control and toward the surrounding system—metrics reliability, durable buffering, startup latency, and safe upgrade procedures.
What Kubernetes 1.37 Changes
Before Kubernetes 1.37, teams that wanted HPA-managed scale-to-zero generally needed an add-on, an external autoscaling component, or the alpha feature gate first introduced in Kubernetes 1.16. With the beta graduation, the HPAScaleToZero gate is enabled by default on the API server and controller manager. An HPA using the autoscaling/v2 API can declare zero as its minimum replica count when it is configured with an object or external metric.
That metric restriction is fundamental. CPU and memory utilization are measured from running pods. Once the last pod disappears, so does the signal needed to wake the workload. An external metric such as queue depth, outstanding messages, or another demand indicator exists independently of the workers. The HPA can continue observing it while the deployment is at zero and calculate a new replica count when demand returns.
Kubernetes also needs to distinguish between two states that look identical at the workload level: zero replicas because the autoscaler intentionally removed the last pod, and zero replicas because an operator manually paused the deployment. Version 1.37 uses a ScaledToZero condition in HPA status. When the HPA scales a target down from one or more replicas, it records that it owns the zero state. Later reconciliation loops may then keep evaluating the configured external or object metric and wake the workload. A target manually set to zero without that condition remains paused.
This detail preserves an existing and important operational convention. Teams can still stop a workload manually without having the autoscaler immediately undo the action. Conversely, an automatically idled workload can recover without a person or separate controller intervening. When it scales up again, the condition changes to false with the reason NotScaledToZero.
Why the Feature Matters Now
Cloud costs increasingly reflect the difference between nominal capacity and useful work. A single minimum replica may be cheap for an ordinary stateless service, but the economics change for fleets of infrequently used consumers, tenant-specific workers, or pods that reserve dedicated CPUs, large memory allocations, or GPUs. In those cases, the “keep one alive” tax is repeated across workloads and clusters.
Native HPA support also matters because it reduces the number of controllers that platform teams must own. Event-driven autoscaling projects remain valuable and often provide broader trigger catalogs or higher-level behavior, but a team with a straightforward external metric can now stay within a standard Kubernetes API and controller. That improves portability and gives cluster operators one fewer control loop to reconcile during incidents.
The change arrives as part of Kubernetes 1.37, a release with 67 enhancements, including 23 beta graduations. Yet scale-to-zero stands out because it changes the minimum viable architecture for a common class of workloads. The feature does not merely optimize an existing running service; it permits a service to have no running pods while remaining under autoscaler control.
The Metric Becomes Part of the Availability Path
Scaling from zero makes the external metrics pipeline an availability dependency. The HPA commonly obtains such data through the Kubernetes External Metrics API, often backed by an adapter that translates a monitoring-system query into the API shape the controller expects. If that adapter cannot return the metric, the HPA has no evidence that capacity is needed.
For a running workload, a broken metric pipeline may leave existing pods serving while autoscaling is impaired. For a workload at zero, the same failure can prevent recovery altogether. Kubernetes reports the problem through HPA conditions—for example, ScalingActive=False with a reason such as FailedGetExternalMetric—but the queued work will still wait until the signal is restored or an operator adds capacity manually.
Platform teams should therefore test the external metric as an application dependency, not just an observability convenience. The useful preflight check is whether the metric can be read through the Kubernetes API that the HPA itself uses. Dashboards showing a value directly from a monitoring backend are not enough if the adapter’s discovery rules, labels, authorization, or aggregation layer are wrong.
The demand signal also needs semantics that match the scaling target. Queue length is intuitive, but a target of one replica per fixed number of messages assumes something about processing rate and startup time. A lag metric may better reflect partitions or consumer groups. Whatever signal is chosen must remain present at zero, identify the correct namespace and workload, and avoid disappearing precisely when the system becomes idle.
Scale-to-Zero Does Not Buffer Traffic
The strongest fit is work that can wait safely outside the pod. A durable message queue naturally holds tasks while the HPA observes demand, schedules a pod, and the application starts. Batch processors and asynchronous GPU jobs can often tolerate this delay, especially when the cost of idle capacity is high.
Request-driven HTTP services are different. A Kubernetes Service routes traffic only to ready endpoints; it does not store requests until a pod appears. If an HTTP workload reaches zero, a request arriving during the cold start needs a separate buffering or activation layer. Without one, reducing replicas to zero trades infrastructure savings for failed or delayed requests in a way the Service abstraction alone cannot solve.
Cold-start time includes more than container launch. The HPA control loop must observe the updated metric, the scheduler must place the pod, the node must have sufficient resources, images may need to be pulled, volumes may need to attach, and readiness checks must pass. GPU workloads add constraints such as scarce device capacity and specialized node pools. Teams should measure this entire activation path at realistic cluster load rather than treating image startup time as the only latency.
The default HPA downscale stabilization window remains five minutes. That is a sensible brake against deleting the last worker after a brief dip in demand, but it also limits how quickly savings appear. Operators can tune spec.behavior.scaleDown, provided they test both cost and churn. Aggressive downscaling can create a cycle of cold starts when work arrives in bursts.
A Safe Adoption Checklist
The beta label and default-enabled feature gate make experimentation easier, but production adoption should begin with workloads whose failure mode is delayed work rather than dropped traffic. A disciplined rollout should include the following steps:
- Choose a durable workload. Start with queue consumers or batch processors whose input survives while no pod is running.
- Prove metric continuity. Confirm that the selected object or external metric remains queryable when the deployment has zero pods.
- Exercise the Kubernetes metrics path. Query the External Metrics API through the API server and alert on adapter errors, stale data, and missing series.
- Measure end-to-end activation. Record time from demand arrival to a ready worker and set service-level objectives that account for the cold start.
- Retain a recovery procedure. Operators should know how to recognize FailedGetExternalMetric and manually restore at least one replica when the metric path is unavailable.
- Tune conservatively. Keep the default downscale stabilization window initially, then change it only with workload traces and cost data.
Teams should also start a target with at least one replica. Manually setting a deployment to zero has historically paused autoscaling, and Kubernetes preserves that behavior. The HPA can wake a target only after it has performed the scale-down and recorded ownership through the status condition.
Upgrade and Rollback Need Coordination
Version-skewed control planes deserve special care. The API server accepts the HPA specification, while the controller manager implements the condition-aware scaling behavior. During an upgrade, operators should wait until both components support the feature and have it enabled before creating HPAs with a zero minimum. A controller manager without the new behavior may interpret zero as a manual pause and leave the workload dormant.
The rollback path is equally explicit. Before disabling the feature gate or returning to a Kubernetes version without the condition-based implementation, change affected HPAs to a minimum of at least one and scale any targets currently at zero back up. This is the kind of stateful operational detail that should be encoded in cluster upgrade runbooks, not discovered during an emergency rollback.
Managed Kubernetes users will also need to verify when their provider exposes Kubernetes 1.37 and whether control-plane settings, metrics adapters, and supported version skew align with the upstream behavior. The feature being enabled by default upstream does not eliminate provider rollout schedules or the need to validate add-on compatibility.
What to Watch During the Beta
The long journey from the original alpha work in Kubernetes 1.16 to beta in 1.37 reflects the edge cases hidden inside an apparently simple replica count. Kubernetes 1.36 introduced the status condition and controller behavior needed to separate autoscaled zero from manual pause; 1.37 adds the default-enabled beta experience and broader integration and end-to-end coverage.
Operational feedback will determine the path to general availability. The most valuable evidence will come from failures: metrics adapters restarting while targets are idle, labels changing and orphaning a series, upgrade skew across control-plane components, and demand bursts arriving faster than cold capacity. Those cases will show whether the status model and diagnostics are sufficient for routine production use.
For practitioners, the central lesson is straightforward. Kubernetes now owns the mechanics of reducing an HPA target to zero and recognizing when it should wake again. It does not own the durability of incoming work, the reliability of the demand signal, or the latency of bringing capacity online. Teams that design those pieces deliberately can remove meaningful idle cost with a standard API. Teams that treat minReplicas: 0 as a cost switch risk moving the bill into latency and recovery work.
