Kubernetes 1.37 shipped on August 26, 2026, under the project’s internal codename “Garhwal,” and buried inside its 67 enhancements is a feature that has nothing to do with new APIs or shinier dashboards: the ability to scale a workload down to exactly zero running pods and bring it back automatically when traffic returns. HorizontalPodAutoscaler (HPA) scale-to-zero moved to beta in this release and is enabled by default, a combination that matters far more for GPU-heavy infrastructure bills than it does for ordinary web services.
The timing is not an accident. GPU capacity has been the tightest and most expensive resource in cloud computing for two years running, and idle GPU-backed pods, the kind that sit warm and billing even when nobody is sending them a request, have become one of the most visible sources of waste inside enterprise cloud bills. Kubernetes 1.37 pairs scale-to-zero with a second major shift: Dynamic Resource Allocation (DRA) for extended resources, including GPUs, has graduated to general availability. Together the two changes give platform teams a native way to stop paying for accelerators they aren’t using, without bolting on a third-party autoscaler.
What Shipped in Kubernetes 1.37 “Garhwal”
Kubernetes 1.37 landed on a Wednesday, named after the Himalayan region of Uttarakhand, India, following the project’s tradition of geographic release names. The release notes list 67 enhancements: 16 graduated to stable, 23 moved to beta, 27 entered alpha, and one feature was deprecated. Some independent trackers count as many as 86 items if deferred or milestone-removed proposals are included, but 67 is the figure most consistently cited across release coverage as the final shipped count.
The stable graduations tell the real story of where the Kubernetes project is putting its effort. Pod-level resource allocation reached stable, letting operators set a resource budget across an entire multi-container pod instead of tuning every container separately. Pod Certificates and ClusterTrustBundles both went stable, tightening how workloads get cryptographic identity. Configurable HPA tolerance and KYAML output for kubectl also crossed the stable line. None of those changes will make headlines on their own, but they round out a release aimed squarely at production hardware efficiency rather than developer convenience features.
The Kubernetes project’s own blog post on the release, published September 3, frames the DRA changes as the headline story of the cycle, and the full release index sits on the project’s official releases page.
Why Scale-to-Zero Is the Feature Everyone’s Talking About
HorizontalPodAutoscaler has been able to scale workloads up and down since Kubernetes’ earliest releases, but it always stopped at one replica. A deployment could shrink, never disappear. That floor made sense for stateless web traffic, where keeping one warm pod costs little, but it made no sense for GPU-backed inference services, batch jobs, or bursty machine learning pipelines that might sit idle for hours between requests while still reserving an expensive accelerator.
How HPA Scale-to-Zero Works
In Kubernetes 1.37, HPA can now scale a target’s minReplicas field down to zero. When traffic or a custom metric drops below the configured threshold, the last pod terminates, and the cluster releases whatever it was holding, including a GPU device claimed through DRA. When a new request arrives, HPA scales the deployment back to one or more replicas and Kubernetes reschedules a pod onto available hardware. The mechanism is beta and on by default, which means clusters running 1.37 already have the capability without extra flags, though administrators still choose per-workload whether to configure minReplicas at zero.
Which Workloads Benefit Most
The clearest beneficiaries are GPU-backed inference endpoints with spiky or low-volume traffic, batch training jobs that run on a schedule, and internal tooling that only sees use during business hours. A model-serving endpoint that gets hit a few times an hour no longer needs to hold a GPU node in reserve around the clock. Engineering teams running dozens of fine-tuned model variants, each behind its own endpoint, stand to see the largest reduction in idle spend, since most of those variants sit unused for the majority of any given day.
Dynamic Resource Allocation Finally Reaches GA for GPUs
The second pillar of this release is DRA extended-resource support reaching general availability. DRA has existed in earlier forms since Kubernetes 1.34, but until 1.37 it required workloads to adopt a new API surface built specifically for DRA, separate from the traditional extended-resource requests like example.com/gpu that most GPU-scheduling setups already use. That GA milestone changes the migration math: a DRA driver can now satisfy an old-style extended-resource request directly, with no separate device plugin running alongside it.
That distinction matters because it removes the single biggest blocker to DRA adoption for teams with existing GPU workloads. Instead of rewriting pod specs to a new resource-claim format on day one, operators can swap in a DRA driver underneath their current YAML and get the benefits, including per-device taints and richer scheduling metadata, without touching application manifests. ResourceClaim support for grouping multiple pods under a shared allocation moved to beta in the same release, extending DRA’s reach from individual pods to entire workloads.
Device Taints, NUMA Awareness, and the End of Vendor Lock-In Scheduling
Three smaller DRA features round out the accelerator story. Device taints and tolerations became stable, mirroring the node-taint model that already lets administrators cordon off unhealthy nodes, but applied at the level of a single device. A cluster operator can now mark one degraded GPU as tainted without affecting the rest of the node, and workloads that can tolerate a slower or partially degraded device can still schedule onto it rather than sitting pending.
Kubernetes 1.37 also standardizes a NUMA-node attribute, resource.kubernetes.io/numaNode, so that different hardware vendors’ DRA drivers report GPU and NIC placement in a common format. Multi-GPU training jobs depend heavily on keeping accelerators and network interfaces on the same NUMA node to avoid cross-socket latency, and until this release that placement data varied by vendor driver. A new derivedAttributes mechanism, built on CEL expressions, lets cluster operators translate vendor-specific device metadata into shared virtual attributes, cutting down on the amount of vendor-specific scheduling logic clusters need to carry. Security researchers at Sysdig flagged a related change, a new kubelet gRPC API (KEP-4188) that returns local pod information, as one to watch closely given the node-level access it exposes.
Kubernetes 1.37 vs 1.36 vs 1.35: What Actually Changed
Kubernetes ships a minor release roughly every four months, and each of the last three cycles built toward the same goal: making the scheduler treat specialized hardware as a first-class citizen instead of an afterthought bolted onto the pod spec. The table below lines up the last three releases across the areas that matter most for GPU-heavy clusters.
| Area | Kubernetes 1.35 | Kubernetes 1.36 | Kubernetes 1.37 (Garhwal) |
|---|---|---|---|
| DRA maturity | Early-stage DRA capabilities | Partitionable devices in beta | Extended-resource support reaches GA; ResourceClaim workload support beta |
| GPU allocation | Device-plugin and early DRA patterns | Partitionable devices stay beta | DRA satisfies traditional GPU-style requests with no device plugin required |
| Autoscaling floor | HPA minimum of one replica | No scale-to-zero milestone | HPA scale-to-zero moves to beta, enabled by default |
| Resource management | Container-level resource specs dominant | Incremental refinement | Pod-level resources reach stable |
| Trust and identity | Early certificate/trust stages | Incremental maturation | Pod Certificates and ClusterTrustBundles reach stable |
| Hardware placement | Driver-specific metadata only | Groundwork for accelerator allocation | Standard numaNode attribute plus CEL-based derived attributes |
Readers who need the full breaking-changes rundown, including the networking default Kubernetes 1.37 retires after a decade in place, can find that covered separately in shattered.io’s Kubernetes 1.37 breaking-changes report. This article focuses specifically on the cost and scheduling implications of scale-to-zero and DRA GA, which that piece touches only briefly.
The GPU Cost Problem This Release Is Built to Solve
GPU instances remain the most expensive line item most infrastructure teams manage, and a GPU sitting idle behind a warm pod still bills at full rate whether it processes one request per hour or one thousand. Before 1.37, the standard workaround was to run a cluster-autoscaler that removes entire nodes once every pod on them is gone, but that only helps if a node hosts nothing but the idle workload. A shared node running several low-traffic inference services alongside one busy one never gets fully drained, so none of the idle pods actually free their GPU allocation.
Scale-to-zero attacks the problem at the pod level instead of the node level. A pod that scales to zero releases its DRA-managed GPU claim immediately, regardless of what else is running on the same node, and the scheduler can hand that device to a different workload in the meantime. That is a meaningfully different cost model than waiting for an entire node to empty out. Cost pressure from GPU memory and accelerator shortages has already pushed several cloud providers to raise prices this year, a trend shattered.io covered in its report on Nebius’s AI cloud price increases, which makes any mechanism that cuts idle GPU time increasingly valuable to platform teams watching their bills.
Cloud Provider Rollout: AKS, GKE, and EKS Timelines Diverge
None of this matters to most engineering teams until their managed Kubernetes provider ships it, and the three major clouds are not moving in lockstep. Microsoft’s Azure Kubernetes Service documentation lists Kubernetes 1.37 with an upstream release in August 2026, AKS preview availability in September 2026, and general availability targeted for October 2026, with support running through October 2027. Google’s GKE release notes confirmed on September 26, 2026, that Kubernetes 1.37 is available in GKE’s Rapid channel, an early-access track that typically precedes broader Regular and Stable channel rollout by several weeks to a few months. Amazon’s EKS had not published a confirmed 1.37 general-availability date as of this writing.
| Provider | 1.37 Availability Status (as of Sept. 27, 2026) | Target GA |
|---|---|---|
| Azure Kubernetes Service (AKS) | Preview since September 2026 | October 2026 |
| Google Kubernetes Engine (GKE) | Rapid channel since September 26, 2026 | Not yet confirmed for Regular/Stable channel |
| Amazon EKS | No confirmed 1.37 date published | Not yet confirmed |
The practical effect is that teams on AKS get first crack at production-ready scale-to-zero, GKE users can opt into the Rapid channel now if they accept some risk, and EKS customers should expect to wait longer. Anyone planning a migration should check the current version tables directly, since Microsoft’s AKS supported-versions page and Google’s GKE release notes both update on a rolling basis.
Configuring Scale-to-Zero: A Practical Example
Enabling scale-to-zero on a GPU-backed deployment does not require a new API. Teams set minReplicas to zero on an existing HorizontalPodAutoscaler object once their cluster runs 1.37 with the feature gate active.
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: inference-endpoint
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: model-inference
minReplicas: 0
maxReplicas: 8
metrics:
- type: Pods
pods:
metric:
name: requests_per_second
target:
type: AverageValue
averageValue: "10"Pairing that with a DRA-managed GPU claim means the pod’s accelerator allocation disappears along with the pod itself once traffic drops to zero, rather than sitting reserved on a node that never fully drains. Teams still need to budget for cold-start latency: the first request after a scale-to-zero event has to wait for a new pod to schedule and, if the model needs to load into GPU memory, for that load to complete.
Security and Identity: Pod Certificates and ClusterTrustBundles Go Stable
Away from the GPU headlines, Kubernetes 1.37 also hardens workload identity. Pod Certificates, which automate issuing short-lived cryptographic identities to individual pods, reached stable in this release, as did ClusterTrustBundles, a native mechanism for distributing trusted certificate-authority data across a cluster instead of relying on operators to manage trust bundles by hand. A new ulimits field under Container.SecurityContext also landed, letting teams express resource-limit policy directly in the pod’s security context rather than through init containers or node-level configuration.
Cloudsmith’s release write-up counted 86 total enhancements when including items that other trackers exclude, a reminder that release-note bookkeeping varies by source even when everyone is describing the same shipped code. Teams building automated compliance tooling around Kubernetes releases should pull enhancement counts from the same tracker consistently rather than mixing sources.
Kubernetes’ Long Road From Device Plugins to DRA
None of this happened overnight. Kubernetes has managed GPUs through a device-plugin model since roughly 2017, a system that worked but required every hardware vendor to ship and maintain a separate plugin binary with limited scheduling intelligence. DRA started life as an alpha proposal aimed at replacing that model with a general-purpose, structured way to describe and claim specialized hardware, GPUs included but also NICs, FPGAs, and other accelerators. It reached beta status around Kubernetes 1.34 and has spent the releases since then filling in the gaps, primarily backward compatibility with the extended-resource requests that years of existing manifests already depend on.
That multi-year timeline explains why 1.37’s GA milestone matters more than it might look on a changelog. GPU scheduling in Kubernetes has effectively been in a multi-year beta since device plugins first shipped, with teams patching around missing features using node labels, custom schedulers, or vendor-specific operators. Getting DRA extended-resource support to GA is the project closing that gap for the first time using a first-party mechanism rather than third-party workarounds.
How This Compares to Karpenter, KEDA, and Cloud-Native Autoscalers
Scale-to-zero and DRA GA do not replace the third-party autoscaling tools many clusters already run, they narrow the gap those tools were built to fill. KEDA, the CNCF project focused on event-driven autoscaling, has supported scaling to zero for years by wrapping HPA with custom metric adapters, and many GPU-serving platforms adopted KEDA specifically because vanilla HPA couldn’t go below one replica. With that floor now gone in Kubernetes 1.37 itself, some of KEDA’s value proposition for simple scale-to-zero cases moves into core Kubernetes, though KEDA’s much broader library of event sources for queues, streams, and external metrics remains outside what HPA does natively.
Karpenter, AWS’s node-provisioning autoscaler, operates one layer up, deciding which nodes to add or remove rather than which pods to scale. DRA’s device-level granularity complements that kind of node autoscaler well: Karpenter can still decide when to terminate an entire GPU node, while DRA and scale-to-zero handle the finer-grained job of releasing individual device claims before that node-level decision even needs to happen. Also worth linking here is shattered.io’s comparison of Kubernetes against Docker Swarm, since orchestrator choice shapes which of these autoscaling layers a team even has access to in the first place. The two approaches stack rather than compete, and teams running both should expect fewer idle GPU-hours regardless of which layer catches a given case first.
What Kubernetes 1.37 Means for FinOps Teams
FinOps practitioners have spent the last two years building dashboards and chargeback models specifically to catch idle GPU spend, because Kubernetes itself gave them no native lever to pull. Scale-to-zero changes that equation by giving platform engineers a first-party knob instead of a monitoring alert that tells finance which team to email. The practical shift is from “detect and report idle GPU cost” toward “prevent idle GPU cost from accruing in the first place,” which is a meaningfully cheaper way to run a FinOps program even before counting the direct compute savings.
That shift will not be instant. Cold-start latency on GPU-backed pods, especially those loading large models into VRAM, means teams have to balance cost savings against response-time SLAs. A scale-to-zero policy tuned too aggressively can turn a fast inference endpoint into one with multi-second latency spikes on its first request after any idle period. The same tradeoff shows up in shattered.io’s coverage of AWS AgentCore’s cold-start cuts, where a different platform tackled the same latency-versus-idle-cost balance from the serverless side rather than the Kubernetes side. Expect the next wave of FinOps tooling to focus on tuning the scale-to-zero threshold itself, treating it as a dial rather than a switch.
Risks and Rough Edges Engineers Should Watch
Beta features carry beta risk, and HPA scale-to-zero being on by default means clusters upgrading to 1.37 inherit new autoscaling behavior even for teams who never explicitly opted in. Any HPA already configured with a low minReplicas value should be reviewed before upgrading, since a workload that unexpectedly scales to zero pods can look identical to an outage from a monitoring perspective if alerting isn’t updated to account for the new floor. Teams that already tightened network policy on their clusters, along the lines described in shattered.io’s zero-trust network policy guide, should also confirm that pods rescheduled after a scale-to-zero event still land inside the correct policy boundaries.
DRA’s extended-resource GA path also depends entirely on hardware vendors shipping updated DRA drivers. A cluster running an older device-plugin-only driver from a GPU vendor gets none of the new benefits until that vendor ships DRA support, meaning real-world adoption speed depends as much on hardware vendor roadmaps as on the Kubernetes release itself. Teams evaluating the upgrade should confirm their specific GPU driver’s DRA compatibility before assuming any of the cost benefits described here apply to their fleet on day one. Clusters still running the cgroup v1 removal changes from Kubernetes 1.35 should already be on a compatible baseline, since 1.37 builds directly on top of that cgroup v2-only foundation.
What Comes Next: Predictions for Kubernetes 1.38 and Beyond
A handful of trends look likely to play out over the next two to three release cycles. First, expect partitionable-device support, which stayed in beta through both 1.36 and 1.37, to be a leading candidate for stable graduation in Kubernetes 1.38, since it is the remaining major piece of the GPU-sharing puzzle DRA hasn’t finished. Second, expect scale-to-zero to move from beta to stable within one or two releases given how aggressively it shipped enabled by default, a pattern the project has followed with other high-demand autoscaling features in recent cycles.
Third, expect GPU driver vendors to accelerate DRA driver releases now that extended-resource compatibility removes the main migration barrier for their existing customers. Fourth, expect Amazon to publish a firmer EKS 1.37 timeline within the next few weeks given that both of its major competitors already have concrete AKS and GKE rollout dates on the record. Fifth, expect the FinOps tooling ecosystem to release scale-to-zero-aware cost dashboards within two to three months, since the entire category exists to track exactly the kind of idle-resource waste this feature is designed to eliminate.
Frequently Asked Questions
What is Kubernetes 1.37 and when did it release?
Kubernetes 1.37, codenamed “Garhwal,” released on August 26, 2026. It shipped 67 enhancements: 16 graduating to stable, 23 to beta, 27 to alpha, plus one deprecation.
What does HPA scale-to-zero actually do?
It lets HorizontalPodAutoscaler reduce a deployment’s replica count all the way to zero pods when demand drops, then scale back up automatically when traffic returns. Before 1.37, HPA could never go below one running replica.
Is scale-to-zero enabled by default in Kubernetes 1.37?
Yes. The feature is in beta status but ships enabled by default, meaning clusters upgraded to 1.37 have the capability available without additional feature-gate configuration, though individual workloads must still set minReplicas to zero to use it.
What is Dynamic Resource Allocation (DRA) and why does GA matter?
DRA is Kubernetes’ structured system for allocating specialized hardware like GPUs, replacing the older device-plugin model. In 1.37, DRA’s support for traditional extended-resource requests (the same format existing GPU workloads already use) reached general availability, letting clusters adopt DRA drivers without rewriting existing pod specifications.
When will AKS, GKE, and EKS support Kubernetes 1.37?
Azure Kubernetes Service lists preview availability in September 2026 and general availability targeted for October 2026. Google Kubernetes Engine made 1.37 available in its early-access Rapid channel on September 26, 2026. Amazon EKS had not published a confirmed 1.37 date as of this article’s publication.
Does scale-to-zero replace tools like KEDA?
Not entirely. KEDA has supported scale-to-zero for years through custom metric adapters and offers a much broader set of event sources beyond what native HPA supports. Native scale-to-zero reduces the need for KEDA in simple cases but doesn’t replace its event-driven scaling library.
What are the risks of upgrading to Kubernetes 1.37?
Existing HPA configurations should be reviewed before upgrading, since the new zero-replica floor changes default autoscaling behavior. DRA’s GPU benefits also depend on hardware vendors shipping updated DRA drivers, so clusters running older device-plugin-only drivers won’t see the cost benefits until their GPU vendor updates its driver.
Does scale-to-zero add latency to GPU-backed applications?
Yes. The first request after a scale-to-zero event has to wait for a new pod to schedule and, for large models, for weights to load into GPU memory. Teams need to weigh that cold-start delay against the idle-cost savings when deciding which workloads to configure with minReplicas set to zero.
