Kubernetes 1.37 advances workload-aware scheduling and cluster networking

The Kubernetes project released version 1.37, codenamed Garhwal, on August 26, 2026, introducing workload-aware scheduling and networking improvements for AI and machine learning workloads. Key features include the graduation of HorizontalPodAutoscaler scale-to-zero to Beta, native gang scheduling for distributed training jobs, workload-aware preemption, and stable Dynamic Resource Allocation device taints and tolerations. The release also continues the transition from IPVS to nftables for cluster networking.

When the open-source Kubernetes cloud-native project got started more than a decade ago, AI was not a major concern. Times have changed. Kubernetes 1.37 https://kubernetes.io/blog/2026/08/26/kubernetes-v1-37-release/ is now out, extending its networking and scheduling capabilities as more organizations run AI and machine learning workloads on the platform. The new release is the second major update for the platform in 2026, following the 1.36 update that debuted in April. The release is codenamed Garhwal, after a region in northern India that Dipesh Rawat, the Kubernetes 1.37 release lead, calls home. A key part of the new 1.37 update is a networking transition that began when Kubernetes 1.35 https://www.networkworld.com/article/4107891/kubernetes-1-35-enables-zero-downtime-resource-scaling-for-production-cloud-workloads.html deprecated the IPVS kube-proxy mode and graduated in-place pod resource adjustments to general availability. For networking teams, Kubernetes 1.37 continues shifting cluster traffic handling away from IPVS and toward nftables. Scheduling also becomes more workload aware, with new capabilities built for AI and machine-learning training jobs that need groups of pods to start and scale together. Kubernetes is increasingly built around the shape of the workloads it runs, not just the individual pods inside them. “So previously it was just a pod and the scheduler depends on the pod and just schedules it,” Rawat told Network World . “Now Kubernetes as a whole is trying to move towards being workload aware.” The Linux Foundation Kubernetes has traditionally scheduled and scaled pods one at a time, with limited awareness of how those pods relate to each other. That approach works for stateless services, but it creates problems for AI workloads, where multiple pods often need to start together, share access to accelerators, and scale as a group rather than individually. It’s a challenge that the 1.37 release aims to address with multiple features that bring a workload-aware scheduling approach to the platform. HPA scale to zero KEP-2021 https://github.com/kubernetes/enhancements/issues/2021 . The HorizontalPodAutoscaler scale to zero feature graduates to Beta in 1.37 and is enabled by default. It lets a Horizontal Pod Autoscaler bring workload replicas down to zero when demand disappears, then restore them once demand returns, using object or external metrics rather than CPU or memory metrics. Rawat said the feature depends on those external signals because there is no running pod to measure CPU or memory usage once replicas hit zero. “So essentially, if you are running some high processing workloads on expensive GPUs, it’s going to save you some costs,” Rawat added. Gang scheduling KEP-4671 https://github.com/kubernetes/enhancements/issues/4671 . Sascha Grunert, principal engineer on the OpenShift Node team at Red Hat, told Network World that this feature brings native all-or-nothing pod placement for distributed training jobs. Workload-aware preemption KEP-5710 . This feature also graduates to Beta in 1.37. It lets the scheduler weigh a PodGroup, rather than individual pods, when preempting lower-priority workloads. DRA device taints and tolerations KEP-5055 . Dynamic Resource Allocation, or DRA, is how Kubernetes assigns hardware like GPUs to workloads. This feature, reaching Stable in 1.37, lets Kubernetes mark a broken or degraded device so it will not be handed to new workloads, similar to how a bad node can already be marked off-limits today. Administrators can also flag devices for exclusion based on criteria such as which driver manages them. Grunert said the feature lets degraded hardware be drained using the familiar node taint model. Kubernetes 1.37 continues moving cluster networking away from IPVS and iptables toward nftables, the newer approach built into the Linux kernel. The kube-proxy component, which is the service that routes traffic to Kubernetes Services, has supported IPVS as an alternative to iptables since Kubernetes 1.8, but IPVS has relied on iptables underneath. That dependency is one reason Kubernetes is deprecating IPVS mode in favor of nftables “The main story is the iptables-to-nftables transition,” Grunert said. He explained that clusters that don’t explicitly set a kube-proxy mode now get a deprecation warning KEP-5343 https://github.com/kubernetes/enhancements/issues/5343 . Additionally the IPVS backend is formally deprecated KEP-5495 https://github.com/kubernetes/enhancements/issues/5495 , with a roadmap to disable it in 1.40 and remove it in 1.43. “nftables offers better performance through incremental rule updates and aligns with the direction of the Linux kernel networking stack,” Grunert said. Another networking capability highlighted by Grunert is DRA Resource Claim Status with standardized network interface data KEP-4817 https://github.com/kubernetes/enhancements/issues/4817 . He noted that it provides DRA drivers a consistent way to describe attached network interfaces, which is increasingly relevant for GPU and RDMA workloads. Pod Certificates KEP-4317 https://github.com/kubernetes/enhancements/issues/4317 and ClusterTrustBundles KEP-3257 https://github.com/kubernetes/enhancements/issues/3257 enable better security in Kubernetes clusters. “Pod certificates and cluster trust certificates have gone to stable, which is essentially giving you a first-class way to share some private keys and X.509 certificates among the pods, which is a nice one,” Rawat said. Grunert noted that the two features give Kubernetes a complete native workload PKI story for the first time. “Pods can request short-lived X.509 certificates and receive cluster-scoped trust anchors through projected volumes, making mTLS possible without external tooling like cert-manager or SPIFFE/SPIRE,” he said. Beyond just the new features, the Kubernetes release team is adjusting its own process heading into future releases. Rawat said the number of Kubernetes Enhancement Proposals, or KEPs, opting into each release has been climbing, and this release brought a high volume of exception requests from contributors asking for extra time to meet deadlines. In response, for the next update, the release team decided to shorten the two week gap it typically takes between releases to clean up processes and update documentation. “So that essentially gives us two more effective weeks of development and testing,” Rawat said. AI may also help to play a role in accelerating future Kubernetes development. “So Kubernetes as a community, we have our AI policy where the contributors are free to use any AI tools for raising a PR, but they need to disclose it in the PR description that they have used AI,” Rawat said. The release team itself did not use AI tools as part of the 1.37 release process, relying instead on manual work and existing automation. “I am hoping in the future, once this adoption grows and the community has proper processes defined, we can start adopting those,” Rawat said.