Kubernetes 1.37 graduates gang scheduling to beta and adds CompositePodGroup

September 8, 2026. The Kubernetes team published the post detailing the next milestone of Workload-Aware Scheduling (WAS) in version 1.37, code-named Garhwal. The Workload and PodGroup APIs — which carry gang scheduling — graduate to beta, as do workload-aware preemption and shared DRA ResourceClaims across PodGroups. The release also introduces a new building block, the CompositePodGroup API, for expressing hierarchies of Pod groups. Why it matters: Kubernetes is openly betting on AI/ML and distributed-computing workloads, and is finally shipping a native base where a third-party scheduler was previously required.

Gang scheduling graduates to beta

Gang scheduling answers a specific need of distributed workloads: a group of Pods must be scheduled together or not at all. For a distributed training job, starting half the workers without the coordinator is pointless — you need the “all-or-nothing” guarantee. The Workload and PodGroup APIs that encode this semantics graduate to beta in 1.37.

The milestone comes with API changes worth knowing:

• Versioning. The Workload and PodGroup APIs are promoted to v1beta1, one step from general availability. For early adopters testing the alpha, v1alpha2 is entirely replaced by v1alpha3 — a transition that introduces breaking changes meant to clean up the structure around the disruptionMode field.
• Native queueing. Until now, each member Pod of a PodGroup was queued individually. In 1.37, only the top-level PodGroup object is queued: all its Pods share the same queueing behavior, laying the groundwork for advanced queueing strategies.
• Mutable minCount. The minCount field, which sets the minimum number of Pods required to schedule a group, was strictly immutable. It becomes mutable: a controller can adjust the minimum size of a gang on the fly, and elastic workloads can degrade or expand their scope without interrupting already-scheduled Pods.

That last point tells the story best: Kubernetes is not only targeting rigid HPC, but also AI workloads that scale up and down with demand.

Workload-aware preemption matures

Workload-aware preemption (WAP) decides which Pods to evict when a new group does not fit in the cluster. In 1.37, its separate feature gate is merged into the generic GenericWorkload gate — a sign the feature is treated as a foundation of gang scheduling rather than an isolated experiment.

Two changes alter real behavior:

• A single algorithm run. In 1.36, the scheduler simulated the removal of victims then re-ran the algorithm on every attempt to “reprieve” a victim, checking that the preemptor still fit. In 1.37, the algorithm runs only once: the preemptor’s Pods are assumed placed from that output, then the reprieval checks whether a victim can stay in place. That is a direct performance win on large clusters.
• The PodGroup becomes a protected victim. In 1.36, the default preemption for single Pods ignored PodGroups and did not respect their disruptionMode: a Pod could be evicted alone, even when its group required all-or-nothing. 1.37 fixes this — default preemption now respects the PodGroup’s disruptionMode.

The disruptionMode field is also renamed to decouple it from the PodGroup object: the PodGroup mode becomes all, and the Pod mode becomes single. A new preemptionPolicy field appears on the PodGroup (behind the PodGroupPreemptionPolicy gate) to authoritatively decide whether a group may trigger preemption.

CompositePodGroup: hierarchies arrive

In 1.36, WAS established a clean split between the static template (Workload) and the runtime group state (PodGroup), but scheduling policies remained limited to a single flat group. The CompositePodGroup API, introduced in 1.37, extends the model to hierarchical requirements.

In practice, a workload can now be organized as a tree of CompositePodGroup and PodGroup objects, each node carrying policies and constraints that apply to the groups beneath it — much as a PodGroup governs a flat group of Pods, but across multiple levels. The scheduler treats that hierarchy as one scheduling unit and tries to satisfy the requirements of every group in the tree.

The point is opening the door to workload structures currently handled by extension APIs such as JobSet and LeaderWorkerSet (LWS): heterogeneous clusters where different roles (leader, workers, auxiliaries) have distinct topology constraints but must start and stop together. To ease adoption, 1.37 ships a set of controller integration APIs and the workloadbuilder Go library — standardized building blocks that simplify how out-of-tree controllers integrate. The native Job controller was also upgraded to fully consume the expanded APIs.

Why Kubernetes is betting on batch

This sequence of posts — gang scheduling, HPA scale-to-zero, DRA, workload-aware scheduling — draws a strategy: Kubernetes wants to become the default platform for AI/ML and high-performance computing, not just stateless web. Native gang scheduling, group-aware preemption and CompositePodGroup hierarchies attack territory currently held by solutions like Volcano and Kueue.

The difference is standardization. A third-party scheduler brings its own API, its own objects and its own lifecycle. The native path promises the same all-or-nothing semantics, but carried by the Workload/PodGroup APIs that the ecosystem is starting to adopt as a common denominator.

What to put in place

It is all still beta: deploy on test clusters, not critical production. Three actions:

• Enable the feature gates. Gang scheduling, workload-aware preemption and CompositePodGroup sit behind gates (including GenericWorkload and PodGroupPreemptionPolicy). Check the exact 1.37 matrix before enabling.
• Prepare the v1alpha2 → v1alpha3 migration. If you have Workload/PodGroup objects in alpha, the replacement of v1alpha2 by v1alpha3 is breaking around disruptionMode. Rework your manifests before upgrading.
• Benchmark against your current scheduler. If you run Volcano or Kueue, compare on your real workloads: does native cover the gang scheduling, elasticity (mutable minCount) and hierarchy you need? Migrating too early to a beta means accepting future API changes.

Verdict

If you run AI/ML, HPC or distributed batch workloads on Kubernetes, 1.37 is the right moment to start seriously evaluating native WAS: beta gang scheduling, group-aware preemption and the CompositePodGroup API cover most of the cases for which you currently pay for a third-party scheduler. If your estate is stateless web or classic microservices, native WAS brings nothing urgent — stay on the standard scheduler and let the beta mature. In either case, remember that the native promise is standardization, not raw performance: the switch criterion should be simplifying your stack, not a scheduling-latency gain you have not measured.

References

• Kubernetes Blog — Kubernetes v1.37: Advancing Workload-Aware Scheduling, September 8, 2026
• kubernetes/kubernetes — GitHub repository