By Kubernetes 1.37 “Garhwal” shipped August 26 with 67 enhancements — but three changes matter more than the rest. HPA can now scale workloads down to zero replicas without any third-party tooling, DRA’s GPU resource management graduated to GA, and gang scheduling for distributed AI training landed in beta. If you run GPU inference or training clusters, this release deserves a slot in your upgrade queue.
HPA Scale-to-Zero Is Now Native — and KEDA Just Became Optional
This is the headline feature. Horizontal Pod Autoscaler now supports scaling workloads all the way to zero replicas and back up again, and it’s beta, enabled by default in 1.37.
The classic problem: once a workload reaches zero replicas, there are no pods producing CPU or memory metrics, so HPA has no signal to scale back up. A dead-end. Kubernetes solves this by shifting to object or external metrics that exist independently of running pods — queue depth, message backlog, Prometheus counters. Your queue is still accumulating work whether your consumer pods are up or not.
externalRules:
- seriesQuery: ‘{__name__=“queue_consumer_lag”,name!=“”}’
metricsQuery: sum(<<.Series>>{<<.LabelMatchers>>}) by (name)
resources:
overrides:
namespace:
resource: namespaceThe practical upshot: if you’re running queue consumers on Kafka, SQS, or RabbitMQ, this pattern now works natively without installing anything extra. The cost savings are most significant when those consumers hold GPU or dedicated-CPU reservations — idle pods disappear entirely when the queue is empty.
There is a catch. Scaling from zero involves a cold start: HPA detects the external metric, schedules the pod, application boots. For workloads that need to respond immediately to HTTP traffic, this does not work — Kubernetes Services do not buffer requests while no pods are ready. You still need a queuing or buffering layer in front for that pattern. For pure batch consumers, it’s a non-issue.
As for KEDA: native HPA covers the basic queue-depth scale-to-zero pattern well. KEDA still wins when you need advanced event sources (Azure Service Bus, GitHub webhooks, cloud-native triggers) or HTTP-native scaling. But for teams running vanilla queue consumers on Prometheus metrics, KEDA just became optional. That is not a small deal.
DRA Goes GA: GPU Resource Management Is Production-Ready
Dynamic Resource Allocation has been climbing the maturity ladder since Kubernetes 1.35. In 1.37, three DRA features crossed the GA line.
DRA Extended Resource Support is now stable. GPU workloads using the traditional extended resource API (example.com/gpu) continue working unmodified while the backend allocation moves to DRA under the hood. No rewrite required. This is the adoption path the Kubernetes team intended: existing workloads stay intact, DRA handles the mechanics.
DRA Device Taints and Tolerations hit GA, mirroring the familiar node taint model. DRA drivers can now flag degraded or under-maintenance hardware, triggering automatic eviction of affected pods unless their ResourceClaim explicitly tolerates the taint. Cluster admins can apply taints cluster-wide via DeviceTaintRule without reconfiguring individual drivers. Maintenance windows on GPU nodes just got considerably less painful.
Standard NUMA Node Device Attribute graduated to stable. The attribute resource.kubernetes.io/numaNode is now the common standard across all vendors. Previously, each GPU or NIC driver invented its own naming convention, which made cross-vendor NUMA co-placement effectively impossible. Fixed.
The cumulative message: teams running GPU inference clusters or heterogeneous hardware can now rely on DRA in production. The three-release journey from alpha in 1.35 to stable in 1.37 is complete.
Gang Scheduling Arrives in Beta
Kubernetes 1.37 promotes gang scheduling to beta. The premise is simple: for a distributed training job requiring eight GPU pods, Kubernetes either schedules all eight or none. No partial allocations, no wasted GPUs sitting idle waiting for the rest of the group to find resources.
The Job controller now auto-generates a Workload representation, giving the scheduler visibility into the full resource footprint of a pod group before committing any resources. This matters for PyTorch, JAX, and other distributed training frameworks where a partial worker count is not just inefficient — it’s functionally useless.
Kubernetes is not subtle about the direction here. Between DRA, gang scheduling, and scale-to-zero, 1.37 is a deliberate move to position the platform as a first-class AI orchestration layer — not just a container runner that happens to schedule GPUs.
Three Breaking Changes That Will Block Your Upgrade
Before you upgrade, audit these three issues:
- cgroup v1 now hard-fails. Kubelet refuses to initialize on cgroup v1 nodes. If you haven’t migrated to cgroup v2, the upgrade stops here.
- IPVS deprecation clock is running. Formal deprecation in 1.37. Disabled by default in 1.40. Removed in 1.43. Start your nftables migration assessment now — 1.40 is the real deadline.
- Static pods can no longer reference Secrets or ConfigMaps. If your ops setup uses static pod manifests with secret references, those manifests break on upgrade.
Also on the deprecation list: kube-dns. CoreDNS has been the default since Kubernetes 1.13, and kube-dns must be migrated before 1.40 or DNS resolution in your cluster stops working.
The Performance Wins Are Free
1.37 also ships meaningful internal improvements that require no config changes. The API server’s internal type conversion gets a 5.7x speedup and 3.3x memory reduction — for a 1,000-pod list, allocations drop from 21,000 to 5. CBOR serialization for custom resources runs 8x faster than JSON on encode and 2x faster on decode.
Two long-running items also finally reach stable: the Metrics API (metrics.k8s.io) after nine years in beta, and KYAML — the stricter, less ambiguous YAML subset used with kubectl get -o kyaml.
The full release notes are on the Kubernetes blog. For teams running queue-based processing or GPU workloads, 1.37 is more than a routine upgrade — the three headline features are cohesive and point toward a platform that is deliberately taking ownership of AI workload orchestration at the infrastructure level.
