Kubernetes 1.37 shipped on August 26, 2026, and buried in a release of 67 enhancements is one that will quietly change how a lot of teams think about idle compute. The HorizontalPodAutoscaler can now scale a workload all the way down to zero replicas, then bring it back when demand returns, and this behavior is Beta and enabled by default rather than an alpha flag most operators never flip. For anyone running spiky workloads, queue consumers, webhook receivers, batch inference jobs, or staging environments that only need to exist during business hours, this closes a real gap in the platform's own autoscaler instead of requiring a third-party layer to paper over it.
The capability itself is not brand new. Kubernetes has carried an alpha feature gate called HPAScaleToZero for a long time, and projects like KEDA have built entire businesses on filling in the rest of the picture. What changed in 1.37 is that the mechanism is now stable enough, and trusted enough by the project, to turn on by default. That matters because the decision about whether scale-to-zero is available in a cluster stops being an opt-in platform decision and becomes a workload-level configuration choice any team can reach for. It also lands at a moment when GPU and inference costs are under more scrutiny than they have been in years, which makes the timing anything but incidental.
The mechanic is narrower than the headline suggests, and understanding the boundary matters before reaching for it. A HorizontalPodAutoscaler can only set minReplicas to zero when at least one of its metrics is an External or Object type. Resource metrics, CPU and memory pulled from the kubelet, and the Pods metric type cannot support a minReplicas of zero, for a simple reason: those metrics are sampled from running containers, and a workload with zero replicas has no container to sample. There is no percentage of CPU utilization to report for a pod that does not exist.
External and Object metrics do not have that problem, because they describe something outside the pod entirely: a queue depth in SQS or Kafka, a Prometheus query result, the number of pending jobs in a database table, or the request rate reported by a load balancer. Those values exist and can be reported whether a workload currently has zero replicas or five hundred. That is precisely why scale-to-zero has always been an External or Object metric feature rather than a general HPA capability, and 1.37 does not change that boundary. What it changes is that a cluster no longer needs an alpha feature gate enabled on the API server and controller manager to use it, and it no longer needs to be treated as an experimental corner of the autoscaler that might behave unpredictably across cluster upgrades.
In practice, an HPA configured for scale-to-zero looks close to any other HPA manifest, with minReplicas set to 0 and a metrics block pointing at an External or Object source. The controller's normal reconciliation loop handles the rest: when the metric value implies zero desired replicas, it scales the Deployment or StatefulSet down to zero, and when the metric next reports a nonzero value on the following sync, it scales back up. The sync period is the detail worth internalizing, because it is the same horizontal-pod-autoscaler-sync-period that governs every other HPA decision, fifteen seconds by default. Scale-to-zero does not get a faster or more reactive path than ordinary scaling. It is subject to exactly the same polling cadence as scaling from three replicas to four.
If this sounds a lot like what KEDA has offered for years, that is because KEDA was built on the same underlying idea, and in many deployments it was quietly relying on the same alpha feature gate this release stabilizes. KEDA's actual job has never been to replace the HPA controller. It runs its own metrics adapter that implements the external.metrics.k8s.io API, and it ships dozens of scalers that know how to poll specific systems, an SQS queue, a Kafka topic's consumer lag, a cron schedule, a Prometheus expression, and translate that into a metric value the HPA controller can consume. The actual scaling decision, including the decision to go to zero, still runs through the same HorizontalPodAutoscaler object and the same controller loop that 1.37 just changed.
That relationship does not disappear now that native scale-to-zero is Beta and on by default. What changes is the operational friction around it. Teams running KEDA no longer need to worry about whether a given cluster or managed Kubernetes offering has the HPAScaleToZero alpha gate enabled, since the underlying capability their scalers depend on is now standard behavior rather than an opt-in risk. And teams who do not currently run KEDA, but already have an External or Object metric source available, a Prometheus adapter, a custom metrics API implementation, a cloud provider's own metrics adapter, can reach for scale-to-zero directly without adopting KEDA's scaler ecosystem at all. KEDA remains the better choice the moment a workload needs one of its purpose-built scalers or its event-driven wake-up path rather than pure polling, but it is no longer the only way to get a workload to zero replicas on a stock Kubernetes cluster.
None of this changes the hardest part of scale-to-zero, which is what happens to the request that arrives while a workload has no running pods. HPA's sync loop polls on an interval, it does not wake up because a request landed at a service's front door. A workload sitting at zero replicas that suddenly receives traffic will sit at zero for up to one sync period before the controller even notices the metric has changed, and then it still has to schedule a pod, pull an image if it is not cached, and let the container pass its readiness probe before it can serve anything. For a queue consumer or a batch job, that latency is a non-issue, the work sits in the queue for a few extra seconds and gets processed once a pod exists. For a synchronous HTTP service sitting behind a load balancer, that same latency is a dropped or badly delayed request, and no amount of tuning the HPA sync period below its practical floor fixes the structural problem that nothing is watching the front door while replicas sit at zero.
This is exactly the gap that request-buffering proxies exist to close, and it is worth understanding the pattern even without adopting a specific product. Knative's queue-proxy, and KEDA's HTTP Add-on, both sit in front of the actual workload, intercept the first request while the target is still at zero replicas, hold it, trigger the scale-up, and forward the request once a pod is ready rather than letting it fail or time out against an empty endpoint. If a scale-to-zero candidate is anything that receives synchronous, latency-sensitive traffic, plan for one of these patterns from the start rather than discovering the gap in production. If it is a worker that pulls from a queue, a scheduled batch job, or an internal tool nobody needs at 2 a.m., native HPA scale-to-zero can be adopted directly with no buffering layer at all, and that is most of where we expect teams to start.
Kubernetes 1.37 does not hand every workload free scale-to-zero, and it does not obsolete KEDA. What it does is remove a real piece of friction, an alpha feature gate that many platform teams were reluctant to enable in production, and it does so at a moment when idle compute cost is under more scrutiny than usual across both traditional services and the GPU-backed inference workloads so many teams are now running. Reach for it first on queue workers, batch jobs, and non-production environments, treat request-buffering as a deliberate decision for anything synchronous, and update observability assumptions before the first workload actually hits zero. For teams weighing scale-to-zero and other cost-driven infrastructure changes against the operational risk of moving too fast on a production autoscaler, that kind of rollout sequencing is core to the work our IT consultancy practice does with platform teams, and it is worth getting the sequence right rather than flipping minReplicas to zero across the fleet in one afternoon.
Before we start, please share a few details so we can follow up with you.
End this conversation? Your chat will be emailed to us.