The scheduler gains a larger unit of work
Kubernetes contributors published a detailed account of version 1.37 workload-aware scheduling on September 8, after the broader v1.37 release on August 26. The change addresses a mismatch between ordinary Pod scheduling and distributed jobs. A conventional scheduler can place each Pod independently. A training run or tightly coupled batch job may instead need several workers, a coordinator and scarce accelerators to become available together before useful work begins.
Independent placement can leave two jobs each holding part of a cluster while neither has enough remaining capacity to start. Kubernetes now has Beta Workload and PodGroup APIs that let a controller describe Pods as a scheduling unit. Gang scheduling can require a minimum count to fit before any assignments are committed. This is a coordination mechanism, not a blanket performance optimization. It can prevent partial placement, but it does not make computation or networking faster.
The distinction between the two objects is functional. A Workload stores reusable templates and scheduling intent. A controller creates runtime PodGroup objects from those templates, and Pods identify their group through a schedulingGroup reference. Kubernetes 1.37 promotes the core APIs to scheduling.k8s.io/v1beta1. Beta signals a more mature interface than Alpha, but the GenericWorkload feature gate remains disabled by default and must be enabled across relevant cluster components.
Gang scheduling trades partial progress for coordination
During a PodGroup scheduling cycle, the scheduler evaluates members against a shared, changing snapshot of cluster capacity. It checks whether the proposed placements satisfy the group's policy, such as a gang minCount. If the group is feasible, assignments proceed to binding. If it is not, the group is treated as unschedulable rather than leaving a newly placed subset behind. That atomic decision is the central benefit for jobs whose processes must start together.
The default algorithm still has a search limitation. It processes Pods in a particular order, so a heterogeneous group may be rejected even when a different order would reveal a valid placement. Inter-Pod affinity, anti-affinity and topology-spread relationships can create the same problem. Kubernetes documentation says homogeneous groups without those dependencies are expected to find a placement when one exists, but it does not make that assurance for more complicated groups. Every member must also use the same schedulerName.
An alternative placement algorithm, introduced earlier and still Alpha in 1.37, can generate candidate node sets, test group feasibility and score feasible placements through plugins. That provides room for domain-specific policies, but it is another gated interface rather than a universal solver. Operators should read a scheduling failure as the outcome of the configured algorithm, not proof that the cluster has no physically possible arrangement.
Preemption and device claims follow the group boundary
Preemption now follows the same group boundary. Workload-aware preemption reaches Beta under the GenericWorkload gate and replaces ordinary per-Pod preemption during a PodGroup scheduling attempt. The scheduler searches cluster-wide for lower-priority victims that could free enough capacity for the group. It ranks potential victims using priority, workload type, group size and start time, while a group's disruption mode determines whether one member or the whole group may be displaced.
This approach avoids making room for one worker when the rest of its job still cannot run. It also expands the effect of a preemption decision across nodes. To control computational cost, the scheduler first simulates removing potential victims, evaluates placement and then tries to reprieve as many victims as possible. The documentation cautions that another placement might require fewer evictions. Group-aware therefore describes the decision boundary, not guaranteed optimality or minimal disruption.
Shared Dynamic Resource Allocation claims for PodGroups also graduate to Beta. A ResourceClaim created from a template can be reserved once for a group and referenced by all of its Pods, which is relevant when a workload coordinates access to accelerators or other managed devices. Version 1.37 also changes disabled-gate behavior: when a Pod claim matches a group claim but the feature is off, Kubernetes creates no claim instead of unexpectedly creating one per Pod and risking a flood of reservations.
Hierarchies can express workers, drivers and topology
Flat groups do not capture every distributed application. A large run may have several worker groups plus a driver, with the whole job constrained to one availability zone and each subgroup constrained to a rack. Version 1.37 introduces CompositePodGroup for this hierarchy. The scheduler can evaluate the root and its descendants as one unit, apply a minimum number of child groups at one level and a minimum number of Pods at the leaves, then resolve topology constraints from parent to child.
CompositePodGroup remains Alpha, disabled by default and dependent on the scheduling.k8s.io/v1alpha3 API. Its hierarchical algorithm is greedy and processes child groups in a fixed order. Kubernetes warns that it can miss a feasible placement and, even when successful, need not find the cluster-wide optimum. The status conditions are also incomplete in this release: the API exposes them, but the scheduler does not yet populate the CompositePodGroup condition field.
Early adopters also face an API transition. Kubernetes replaced v1alpha2 with v1alpha3 and changed the structure around disruptionMode. That incompatibility is permissible for an Alpha API, but it matters to manifests, controllers and stored assumptions. The project's stated goals for v1.38 include moving the core Workload and PodGroup APIs to general availability and CompositePodGroup toward Beta. Those are plans, not completed stability guarantees.