Photo by ThisisEngineering on Unsplash. Source: https://unsplash.com/photos/woman-in-white-long-sleeve-shirt-using-black-laptop-computer-ZPeXrWxOjRQ (Unsplash License).

Executive Summary

Workload-aware scheduling stopped being experimental surface area in Kubernetes this cycle. The v1.37 update promotes the Workload and PodGroup APIs to beta, moves workload-aware preemption to beta alongside them, and does the same for shared DRA ResourceClaims across a PodGroup. The API group advances to scheduling.k8s.io/v1beta1, one step below general availability. Every gate involved still ships disabled by default.

The graduation is the signal, not the feature list. Gang scheduling and topology awareness are the two capabilities large training jobs and disaggregated inference need, and the project spent two releases building them inward from Pod-by-Pod placement. The scheduler now queues groups instead of loose Pods, evaluates a hierarchy as a single unit, and treats shared accelerator claims as a group concern. Teams running AI infrastructure should test the beta gates now, because the alpha APIs layered on top have already landed.

Kubernetes v1.37 shipped on August 26, 2026. It moved the core of workload-aware scheduling to Beta, including gang scheduling, the Workload and PodGroup APIs, workload-aware preemption, and shared Dynamic Resource Allocation claims for a group of Pods. The release notes list all four under features graduating to Beta.

A training job is one unit of work spread across hundreds of accelerators. Place ninety percent of it and you get nothing. The old scheduler had no notion of that. It placed Pods one at a time and left the rest pending indefinitely.

What moved to Beta in Kubernetes 1.37, and the scheduling hierarchy already in Alpha
What moved to Beta in Kubernetes 1.37, and the scheduling hierarchy already in Alpha

A partially scheduled training job delivers nothing

Gang scheduling fixes that. The scheduler gathers every Pod in a group and admits them together, or admits none of them. A group is captured as a PodGroup with a scheduling policy of gang and a minCount, the floor below which the whole group stays pending.

Preemption got sharper too. The scheduler now weighs a PodGroup as one unit when it needs to evict lower priority work. That stops the old behavior of killing a few Pods without freeing enough capacity for the job to make progress.

The queue holds groups now, not loose Pods

Before v1.37, member Pods of a group entered the scheduling queue one at a time even when they belonged together. Now only the group object is queued. Every Pod in the group inherits the same queueing behavior, and that sets up the finer queueing policies the scheduling team wants next.

The Workload and PodGroup API definitions live in the Workload API and PodGroup API docs. Two details changed inside them. The minCount field became mutable, so controllers can grow or shrink the minimum gang size while a job runs. And shared Dynamic Resource Allocation claims let a group reserve accelerators through one claim set instead of a separate claim per Pod.

That elasticity matters for workloads that should degrade instead of collapse. A job that loses a rack can keep running at a smaller size without restarting the Pods that already landed.

Hierarchy arrived in Alpha while Beta is still switched off

v1.37 adds a CompositePodGroup API in alpha. It lets a workload describe a tree of groups, where a parent group constrains its children. A parent can demand that two child groups be schedulable together, then pin the whole tree to one availability zone and the workers to racks inside that zone.

That hierarchy is the shape JobSet and LeaderWorkerSet already push through their own APIs. It also fits disaggregated inference, where a prefill stage and a decode stage need to sit close to each other. Multi-level topology constraints land with the same alpha gate, so a workload can carry a zone rule at the root and a rack rule at the leaves.

Scheduler preemption for in-place Pod resize also arrived in Alpha. When a running Pod asks for more CPU than the node can spare, the scheduler can evict lower priority Pods to create the headroom. The kubelet previously parked that request as Deferred with no way out.

For controller authors, Kubernetes shipped a workloadbuilder Go library. It compiles a controller’s own view of a workload into the right scheduling objects and reports validation problems at the exact field that caused them. It needs no feature gate at all.

The direction is settled. Kubernetes is being rebuilt around accelerators, and the Beta APIs are the foundation the rest now sits on. Every gate here still ships disabled by default, so nothing changes in your cluster until you enable it.

Spin up a test cluster and turn on the beta gates before the general availability push arrives. The alpha work layered on top is already waiting, and the teams that learn these objects early will be the ones who can run a job across a thousand accelerators without hand-holding the scheduler.

Where this sits in the wider market

Scheduling is the layer that decides whether expensive accelerators ever run at rate. The AI Infrastructure report covers the four layers under an enterprise AI platform, including why power and scheduling decide capacity long before the model does.

Related reading. Kubernetes 1.37 switched native histograms on by default covers the observability half of the same release. Why Kubernetes for AI is not Kubernetes for apps explains why the placement problem changed shape.

By Tech Thought Leaders

Independent analysis of cloud-native infrastructure, virtualization and data centre economics.

One thought on “Kubernetes 1.37 Is Rebuilding the Scheduler for Accelerators, Not Web Services”

Leave a Reply

Your email address will not be published. Required fields are marked *

Get the next one before it is old news

Independent analysis of cloud-native infrastructure, Kubernetes and data centre economics. No vendor spin.