Kubernetes 1.37 introduces a more consistent way for workload controllers to describe scheduling intent. The release adds reusable workload-aware scheduling building blocks that controllers can compile into scheduler-facing Workload, PodGroup, and CompositePodGroup resources.
That matters for batch, AI/ML, and other multi-pod workloads that need more than independent pod placement. Developers can now build support for gang scheduling, topology constraints, disruption behavior, shared dynamic-resource-allocation claims, and hierarchical scheduling around common APIs rather than creating separate scheduling schemas for every controller.
What changed in Kubernetes 1.37
Kubernetes 1.37, named Garhwal, was officially released on August 26, 2026. The release includes 67 enhancements, including 16 stable, 23 beta, and 27 alpha features, according to the official Kubernetes 1.37 release announcement.
The workload-aware scheduling model provides reusable API building blocks that can be embedded in controller-specific APIs. A controller can expose scheduling configuration to its users and then compile that configuration into resources understood by the scheduling system.
The documented workloadbuilder library is intended for both built-in and external controllers. It is distributed from k8s.io/component-helpers/scheduling/schedulingv1/workloadbuilder and is described as usable by controller patterns such as JobSet or Kubeflow TrainJob. The built-in Kubernetes Job controller can also use scheduling configuration through the WorkloadWithJob feature gate.
The model supports basic and gang scheduling policies, topology constraints, disruption modes, and shared dynamic-resource-allocation claims. Gang scheduling is particularly relevant to workloads where a useful unit of execution consists of multiple pods that should be considered together. However, Kubernetes documentation does not establish that every controller supports every available policy. Controller integrations must define their own supported options.
Workload and PodGroup resources provide the common model
A Workload resource can contain templates for pod groups or composite pod groups. The API allows up to eight templates of the selected type. Templates can include scheduling and disruption-related configuration, along with an optional reference to the controller responsible for the workload.
This separates the controller-facing API from the objects used to express scheduling intent. A custom controller can retain an API that matches its workload model while using the common builder and resource types to communicate scheduling requirements.
The workload-aware scheduling building blocks are Beta in Kubernetes 1.37, but they are disabled by default. Operators must enable the GenericWorkload feature gate on all relevant Kubernetes components before using them. Feature gates are configured through the --feature-gates flag as comma-separated key-value pairs; each component supports only gates relevant to its function. The feature-gates reference lists the supported gates and their maturity information.
CompositePodGroup adds hierarchy
Kubernetes 1.37 also includes the CompositePodGroup API at scheduling.k8s.io/v1alpha3. It represents runtime groups made up of pod groups and supports parent-child hierarchy, basic or gang scheduling, topology constraints, disruption modes, priority, and preemption policy.
This creates a model for workloads with multiple scheduling levels. For example, a higher-level composite group can describe a larger workload while its children represent separate pod groups. The API validates several invalid layouts, including cycles, hierarchies deeper than four levels, and references that span multiple distinct Workloads.
CompositePodGroup is an Alpha feature, not a general availability feature. It requires the separate CompositePodGroup feature gate. Its disruption and preemption behavior is represented explicitly in the API. Disruption can apply to individual entities or to all children together, while preemption can be set to Never or PreemptLowerPriority when the relevant feature-gate state permits it.
The workloadbuilder documentation describes compilation from scheduling.k8s.io/v1alpha3 scheduling building blocks into scheduling.k8s.io/v1beta1 Workload and PodGroup objects. CompositePodGroup objects remain at v1alpha3.
Why controller authors should care
For controller developers, the main change is the availability of shared scheduling primitives. Instead of inventing a controller-specific representation for gang scheduling or disruption policy, authors can embed the reusable building blocks into their own APIs and compile them into scheduler-facing resources.
The builder also centralizes important behavior. It performs structural and controller-policy validation, enforces immutable fields on updates, and uses allow-lists so controllers explicitly declare which scheduling policies and disruption modes they support.
That allow-list model is important for compatibility and user expectations. A controller should not expose every field simply because the underlying API contains it. Its API and validation behavior need to reflect the policies it can actually implement. Controller authors also need to preserve immutable scheduling fields after resource creation and provide previously stored configuration when validating updates.
The result is an extensible framework rather than universal scheduling support for every workload type. Integration remains a controller responsibility, and the documented Job integration is specifically controlled by the WorkloadWithJob feature gate.
What administrators should consider
Administrators should treat the feature-gate requirements as a rollout dependency. The Beta workload-aware scheduling building blocks are not enabled by default, and GenericWorkload must be enabled consistently on relevant components. CompositePodGroup requires its own gate and carries Alpha status in Kubernetes 1.37.
Before enabling the APIs for production workloads, teams should test the selected feature gates together with the controllers that will create or consume Workload, PodGroup, or CompositePodGroup resources. They should also confirm which scheduling policies and disruption modes each controller supports rather than assuming that all API options are available.
Priority and preemption settings deserve operational review as well. The documented API can allow a composite group to preempt lower-priority workloads or disable preemption, depending on the configured policy and feature-gate state. These settings affect placement behavior and should be evaluated alongside the workload priorities and disruption expectations of the cluster.
What you should do
- Review the workloadbuilder documentation if you maintain an in-tree or out-of-tree workload controller.
- Identify which scheduling capabilities your controller needs: gang or basic scheduling, topology constraints, disruption behavior, or shared resource claims.
- Define an explicit allow-list of policies and disruption modes that the controller supports.
- Plan the required
GenericWorkloadfeature-gate configuration across relevant components before creating workload-aware scheduling resources. - Enable
CompositePodGroupseparately only when hierarchical scheduling is needed, and account for its Alpha maturity and four-level hierarchy limit. - Test immutable-field validation, update behavior, controller defaults, and preemption settings before adopting the feature for production workloads.
Availability and migration caveats
The workload-aware scheduling building blocks are available in Kubernetes 1.37 at Beta maturity, but they are disabled by default. CompositePodGroup is available as an Alpha feature behind its feature gate. The supplied Kubernetes documentation does not provide a complete step-by-step migration procedure from scheduling.k8s.io/v1alpha2 to v1alpha3.
It also does not establish whether existing v1alpha2 users must migrate, can continue using older versions, or need a particular conversion sequence. Teams with existing Workload or PodGroup deployments should therefore avoid assuming complete v1.36-to-v1.37 compatibility until they validate their controllers and resource usage against the relevant Kubernetes documentation.
The documented material describes validation, authorization-related API request handling, configuration, priority, and preemption behavior. It does not provide a dedicated security assessment or broader isolation guarantee for workload-aware scheduling. Feature-gate changes and preemption configuration should be treated as operationally significant without characterizing them as a security fix or vulnerability response.
