Kubernetes 1.37 moves the core Workload and PodGroup APIs to v1beta1, introduces the CompositePodGroup API, and refines preemption logic, all aimed at making gang‑scheduling and workload‑aware scheduling (WAS) practical for production workloads. Engineers building AI/ML pipelines, large batch jobs, or high‑performance services need to understand these changes to adjust controllers, tune scheduling behavior, and avoid unexpected disruptions.
Workload‑Aware Scheduling Updates
The release graduates the Workload and PodGroup APIs from alpha to beta, signalling a stable contract for developers. The previous v1alpha2 version is fully replaced by v1alpha3, which cleans up the disruptionMode field and introduces breaking changes that may require controller code updates. The new CompositePodGroup API adds a hierarchical model, allowing multi‑level topology constraints and coordinated gang scheduling for complex workloads such as JobSet or LeaderWorkerSet.
API Versioning and New CompositePodGroup
With the promotion to v1beta1, the APIs are one step away from GA, encouraging production use. The CompositePodGroup API expands the scheduling vocabulary, letting operators describe nested groups of Pods with distinct preemption policies. This directly supports higher‑order controllers that previously had to implement custom logic for multi‑tier job orchestration.
Queueing and Elasticity Changes
PodGroup objects now enter the scheduler queue as a single entity rather than as individual Pods, ensuring consistent queueing semantics for all members of a gang. The minCount field, which defines the minimum number of Pods required for a group to be admitted, is now mutable. Controllers can raise or lower the required size of a gang on the fly, enabling elastic scaling without forcing a full reschedule of already‑running Pods.
Preemption Optimizations
The separate WorkloadAwarePreemption feature gate has been merged into the GenericWorkload gate, making preemption a core part of the scheduling stack. The algorithm now simulates victim removal once and reuses that result, rather than re‑running the scheduler for each potential victim. This reduces scheduling latency and improves overall cluster throughput. Additionally, PodGroups can now be considered as preemption victims, extending the preemption model to gang‑level decisions.
Controller Integration and Tooling
To lower the barrier for out‑of‑tree controllers, Kubernetes 1.37 ships a set of controller integration APIs and the workloadbuilder Go library. The native Job controller has been updated to consume the expanded WAS APIs, offering richer scheduling policies, flexible disruption modes, and topology‑aware placement for batch workloads. Teams can adopt these libraries to avoid reinventing integration code.
Related CloudNinjas coverage: Kubernetes.
What This Means For Practitioners
- Review controller code for compatibility with
v1alpha3and update any references to the oldv1alpha2schema. - Evaluate whether your workloads can benefit from CompositePodGroup to express hierarchical constraints.
- Leverage mutable
minCountto implement elastic gang scaling without full pod churn. - Test the new preemption path in staging to verify that the single‑run algorithm meets latency expectations.
- Consider adopting the
workloadbuilderlibrary for custom controllers to align with the native Job controller integration.