{"slug": "kubernetes-v1-37-advancing-workload-aware-scheduling", "title": "Kubernetes v1.37: Advancing Workload-Aware Scheduling", "summary": "Kubernetes v1.37 promoted its core Workload and PodGroup APIs, gang scheduling, Workload-Aware Preemption, and shared DRA ResourceClaims for PodGroups to Beta, with the Workload and PodGroup APIs moving to v1beta1, one step from General Availability. The release introduces the new CompositePodGroup API for multi-level topology constraints, gang scheduling, and preemption policies, plus controller integration APIs and the workloadbuilder Go library, and replaces v1alpha2 with v1alpha3 in a breaking change around disruptionMode. The minCount field is now mutable for elastic workloads, PodGroups are queued as a single top-level object rather than per-Pod, and the WorkloadAwarePreemption feature gate merged into GenericWorkload.", "body_md": "AI/ML and complex batch workloads continue to push the boundaries of Kubernetes scheduling. Following the foundational workload-centric enhancements introduced in previous releases, Kubernetes v1.37 delivers the next major milestone in the Workload-Aware Scheduling (WAS) journey. In this release, the core Workload and PodGroup APIs—enabling gang scheduling—along with Workload-Aware Preemption (WAP) and shared DRA ResourceClaims for PodGroups, all graduate to Beta, solidifying their role in the Kubernetes ecosystem.\n\nTo address the hierarchical scheduling requirements of modern high-performance distributed workloads, v1.37 introduces the new [CompositePodGroup](https://kubernetes.io/docs/concepts/workloads/compositepodgroup-api/) API.\nThis new API allows expressing multi-level topology constraints, gang scheduling, and preemption policies for complex, heterogeneous groups of Pods. Crucially, this architectural expansion unlocks native scheduling support for advanced workload structures commonly managed by higher-order extension APIs such as JobSet and LeaderWorkerSet (LWS).\n\nAlongside these API additions, v1.37 focuses on streamlining adoption by introducing a new set of *controller integration APIs* and the `workloadbuilder` Go library. These provide standardized building blocks that significantly simplify how out-of-tree controllers can integrate with WAS capabilities.\nUtilizing these new tools, the native Job controller integration has been upgraded to fully consume the expanded WAS APIs—enabling advanced scheduling policies, flexible disruption modes, and topology-aware scheduling for standard batch workloads.\n\nKubernetes v1.37 delivers a major milestone: [Workload](https://kubernetes.io/docs/concepts/workloads/workload-api/) / [PodGroup](https://kubernetes.io/docs/concepts/workloads/podgroup-api/) APIs and *gang scheduling*\nare officially graduating to Beta. This graduation signals that native, \"all-or-nothing\"\nscheduling for workloads is solidifying for wider adoption.\n\nKey updates to the API and gang scheduling algorithm in this release include:\n\nThe core Workload and PodGroup APIs have been promoted to v1beta1, meaning they are now one step away from\nGeneral Availability (GA). For early adopters who have been testing these features,\ntake note of the alpha versioning transition: v1alpha2 has been entirely replaced by v1alpha3.\nThis transition introduces breaking changes designed to clean up the API structure around `disruptionMode`.\n\nA significant under-the-hood improvement in v1.37 makes the PodGroup a first-class citizen in the scheduling queue. Previously, even if belonging to a PodGroup, all member Pods were queued individually. Now, only the top-level PodGroup object is queued. This ensures all Pods share the same queueing behavior and lays the groundwork for more advanced PodGroup queueing strategies in the future.\n\nIn earlier iterations, the `minCount` field, which dictates the minimum number of Pods required\nto successfully schedule a PodGroup, was strictly immutable. In v1.37, `minCount` is now mutable.\nThis API change unlocks flexibility for elastic workloads. Controllers can now dynamically\nadjust the minimum required size of a gang on the fly, allowing workloads to gracefully degrade\nor expand without interrupting already-scheduled Pods.\n\nIn Kubernetes v1.37 the separate\n`WorkloadAwarePreemption` [feature gate](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/)\nfor *workload-aware preemption* was merged into the `GenericWorkload` feature gate,\nbecoming a core part of the gang scheduling effort.\n\nWhile the core concepts of workload-aware preemption stay the same, there are some differences between the v1.36 and v1.37 releases:\n\nTo check whether a preemptor can fit in the cluster thanks to preemption, the scheduler simulates the removal of all potential victims and re-runs the scheduling algorithm. After that it tries to reprieve as many victims as possible. In the v1.36 release, the scheduling algorithm was run for each victim reprieval, verifying whether with the victim reprieved, the algorithm can still find a valid placement for the preemptor. In v1.37, the scheduling algorithm is run only once and the preemptor Pods are assumed based on its output. Later, the reprieval checks whether a victim can still run in its place with the preemptor assumed.\n\nOne of the limitations of v1.36 was the fact that the default preemption for single Pods\nwas not aware of PodGroups and was not respecting their `disruptionMode` fields, allowing\nfor disruption of single Pods even when the PodGroup had `disruptionMode: {all: {}}` set.\nKubernetes v1.37 removes this limitation; the default preemption now respects the PodGroup\n`disruptionMode` field.\n\n`disruptionMode` fields\nDuring the promotion of the API to Beta, the `disruptionMode` field was changed to decouple\nits naming from the PodGroup object, allowing consistent naming across PodGroups and CompositePodGroups.\nThe modes changed as follows: `PodGroup` became `all`, and `Pod` became `single`.\n\n`preemptionPolicy`\nIn v1.36, the PodGroup does not have a `preemptionPolicy` field. The PodGroup can perform\npreemption as long as none of the Pods forming it has `preemptionPolicy: Never` set. In v1.37,\nwhen the [`PodGroupPreemptionPolicy`](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/#PodGroupPreemptionPolicy)\nfeature gate is enabled, a PodGroup also has a `preemptionPolicy` field. It serves as an authoritative field for whether\na PodGroup can perform preemption.\n\nIn Kubernetes v1.36, workload-aware scheduling established a clean separation between static workload templates (Workload) and runtime group state (PodGroup), but the supported scheduling policies were limited to a single, flat group. The CompositePodGroup API, introduced in Kubernetes v1.37, extends this model to support hierarchical scheduling requirements.\n\nThis API allows its consumers to express multi-level scheduling requirements by organizing a workload in a tree-shaped hierarchy consisting of CompositePodGroup and PodGroup objects. Each CompositePodGroup carries policies and constraints that apply to other groups (CompositePodGroups and/or PodGroups), similar to how PodGroups govern scheduling behavior for a flat group of Pods. The scheduler treats such a hierarchy as a single scheduling unit and aims to satisfy the requirements specified by every group within that hierarchy.\n\nTo express multi-level scheduling requirements, you define a hierarchy of templates in a Workload object. Controllers then create the corresponding CompositePodGroup and PodGroup objects from that hierarchy.\n\nTo support this, the Workload API is extended with the `spec.compositePodGroupTemplates` field. Each CompositePodGroupTemplate defines a template for a parent CompositePodGroup and directly nests the templates (`podGroupTemplates` and/or `compositePodGroupTemplates`) from which its child groups derive.\n\nBelow is a sample Workload object that defines a two-level template hierarchy:\n\n```\napiVersion: scheduling.k8s.io/v1beta1\nkind: Workload\nmetadata:\n name: example-workload\n annotations:\n kubernetes.io/description: \"Two-level workload hierarchy requiring 4 worker Pods and 1 driver Pod to schedule together.\"\nspec:\n compositePodGroupTemplates:\n - name: workload-root\n schedulingPolicy:\n gang:\n minGroupCount: 2\n podGroupTemplates:\n - name: workers\n schedulingPolicy:\n gang:\n minCount: 4\n - name: driver\n schedulingPolicy:\n gang:\n minCount: 1\n```\n\nAfter creating `example-workload`, a controller can stamp out the corresponding runtime group objects from these templates:\n\nA root CompositePodGroup that references the `workload-root` template in `example-workload` and carries its group-level scheduling policy (gang scheduling with `minGroupCount: 2`):\n\n```\napiVersion: scheduling.k8s.io/v1alpha3\nkind: CompositePodGroup\nmetadata:\n name: example-root-group\n annotations:\n kubernetes.io/description: \"Root group coordinating gang scheduling across child worker and driver PodGroups.\"\nspec:\n workloadRef:\n workloadName: example-workload\n templateName: workload-root\n schedulingPolicy:\n gang:\n minGroupCount: 2\n```\n\nTwo child PodGroup objects (`example-workload-workers` and `example-workload-driver`) that reference their respective leaf templates in `example-workload` and link to the root group via `parentCompositePodGroupName`:\n\n```\napiVersion: scheduling.k8s.io/v1beta1\nkind: PodGroup\nmetadata:\n name: example-workload-workers\n annotations:\n kubernetes.io/description: \"Worker group requiring at least 4 Pods to be scheduled together.\"\nspec:\n parentCompositePodGroupName: example-root-group\n workloadRef:\n workloadName: example-workload\n templateName: workers\n schedulingPolicy:\n gang:\n minCount: 4\n---\napiVersion: scheduling.k8s.io/v1beta1\nkind: PodGroup\nmetadata:\n name: example-workload-driver\n annotations:\n kubernetes.io/description: \"Driver group requiring 1 Pod to schedule alongside the workers.\"\nspec:\n parentCompositePodGroupName: example-root-group\n workloadRef:\n workloadName: example-workload\n templateName: driver\n schedulingPolicy:\n gang:\n minCount: 1\n```\n\nTo schedule a hierarchical workload, `kube-scheduler` evaluates the entire group tree as a unified scheduling unit:\n\n`minGroupCount` of child groups when using the gang policy), while each leaf PodGroup must satisfy its own Pod-level policy (for example, placing at least `minCount` of member Pods when using the gang policy).\nKubernetes v1.37 extends workload-aware preemption to support CompositePodGroup hierarchies as well. Specifically, if a CompositePodGroup cannot be scheduled due to insufficient capacity in the cluster, the scheduler can invoke preemption to evict lower-priority workloads in order to fit the Pods belonging to that CompositePodGroup.\n\nA CompositePodGroup can be selected for preemption as well. To specify the desired behavior during preemption, workload owners can specify an appropriate `disruptionMode` in the CompositePodGroup spec:\n\n`single`` all`\nIn Kubernetes v1.37, topology-aware scheduling expands to support complex, multi-level workload hierarchies and delivers performance improvements for existing single-level deployments.\n\nIn Kubernetes v1.36, we introduced foundational topology-aware scheduling, allowing you to define co-location constraints directly on a PodGroup. While effective for single-level groupings, complex distributed workloads—such as large-scale AI/ML training, JobSet deployments, or disaggregated inference via LeaderWorkerSet (LWS)—often require co-location across multiple levels of cluster infrastructure simultaneously.\n\nFor example, an entire workload may need to run within a single availability zone, while different parts of that workload (such as specific worker groups or driver processes) require strict co-location within specific server racks.\n\nIn Kubernetes v1.37, alongside the new CompositePodGroup API (`scheduling.k8s.io/v1alpha3`), topology-aware scheduling expands to support *multi-level topology-aware scheduling*. You can now express complex co-location requirements by specifying topology constraints at different levels of a group hierarchy.\n\nDuring hierarchical scheduling, the `kube-scheduler` resolves multi-level topology constraints in a **top-down** manner. Specifically, topology domains that are considered during the scheduling of a child group are confined within a topology domain that corresponds to the placement assumed by the parent group.\n\nUsing the updated Workload API (`scheduling.k8s.io/v1beta1`), you can configure multi-level topology constraints directly within `compositePodGroupTemplates`. In the example below, the parent template constrains the overall workload to a single availability zone (`topology.kubernetes.io/zone`), while child templates for `workers` and `driver` constrain their respective Pods to server racks (`topology.example.com/rack`) within that selected zone:\n\n```\napiVersion: scheduling.k8s.io/v1beta1\nkind: Workload\nmetadata:\n name: multi-level-tas-workload\n namespace: job-ns\n annotations:\n kubernetes.io/description: \"Workload defining zone-level co-location for the root group and rack-level co-location for child groups.\"\nspec:\n compositePodGroupTemplates:\n - name: root\n schedulingPolicy:\n gang:\n minGroupCount: 2\n schedulingConstraints:\n topology:\n - key: topology.kubernetes.io/zone\n podGroupTemplates:\n - name: workers\n schedulingPolicy:\n gang:\n minCount: 8\n schedulingConstraints:\n topology:\n - key: topology.example.com/rack\n - name: driver\n schedulingPolicy:\n gang:\n minCount: 1\n schedulingConstraints:\n topology:\n - key: topology.example.com/rack\n```\n\nWhen a controller creates an instance of this workload at runtime, it spawns the corresponding runtime objects from these templates:\n\n`root` template, carrying the availability zone topology constraint and the hierarchical gang scheduling policy.`tas-workload-workers` and `tas-workload-driver`), each referencing the root CompositePodGroup as their parent group via the `parentCompositePodGroupName` spec field:\n\n```\napiVersion: scheduling.k8s.io/v1alpha3\nkind: CompositePodGroup\nmetadata:\n name: tas-workload-root\n namespace: job-ns\n annotations:\n kubernetes.io/description: \"Root group constraining the entire workload to a single availability zone.\"\nspec:\n workloadRef:\n workloadName: multi-level-tas-workload\n templateName: root\n schedulingPolicy:\n gang:\n minGroupCount: 2\n schedulingConstraints:\n topology:\n - key: topology.kubernetes.io/zone\n---\napiVersion: scheduling.k8s.io/v1beta1\nkind: PodGroup\nmetadata:\n name: tas-workload-workers\n namespace: job-ns\n annotations:\n kubernetes.io/description: \"Worker group requiring 8 Pods co-located within a single rack in the selected zone.\"\nspec:\n parentCompositePodGroupName: tas-workload-root\n workloadRef:\n workloadName: multi-level-tas-workload\n templateName: workers\n schedulingPolicy:\n gang:\n minCount: 8\n schedulingConstraints:\n topology:\n - key: topology.example.com/rack\n---\napiVersion: scheduling.k8s.io/v1beta1\nkind: PodGroup\nmetadata:\n name: tas-workload-driver\n namespace: job-ns\n annotations:\n kubernetes.io/description: \"Driver group requiring 1 Pod placed in a rack within the selected zone.\"\nspec:\n parentCompositePodGroupName: tas-workload-root\n workloadRef:\n workloadName: multi-level-tas-workload\n templateName: driver\n schedulingPolicy:\n gang:\n minCount: 1\n schedulingConstraints:\n topology:\n - key: topology.example.com/rack\n```\n\nDuring scheduling, the scheduler evaluates multiple candidate availability zones across the cluster for `tas-workload-root`. For each candidate zone, it subdivides the nodes by rack topology to explore feasible rack placements for `tas-workload-workers` and `tas-workload-driver` strictly within that zone, systematically evaluating multiple combinations across available zones and racks before making a scheduling decision.\n\nBy allowing topology constraints to be modeled hierarchically, Kubernetes v1.37 provides a structured way to express multi-level co-location requirements across complex cluster infrastructures.\n\nAlongside the Alpha introduction of multi-level hierarchies, Kubernetes v1.37 reduces the cost of placement evaluation for existing single-level topology-aware scheduling. We are continuously working to optimize the efficiency of placement evaluation algorithms in `kube-scheduler` and plan to deliver further performance improvements in future releases.\n\nKubernetes v1.37 introduces new standard building blocks so that every controller can expose the same scheduling primitives in their own APIs, and share the same logic for translating them into scheduling objects. These primitives express specific scheduling behaviors — such as policies or disruption logic — while leaving the field naming flexible for each controller. A prime example of this is the native Job controller, which we detail in the next section.\n\nTypes prefixed with `WorkloadPodGroup` describe a leaf group of Pods; types prefixed with\n`WorkloadCompositePodGroup` describe a group of groups. A controller embeds them verbatim into\nits own API, under whatever field name fits its domain:\n\n`WorkloadPodGroupSchedulingPolicy` — either `basic`, meaning standard Pod-by-Pod scheduling, or `gang` with a `WorkloadPodGroupSchedulingConstraints` — the topology constraints (`topology[].key`) the group's Pods must be co-located within.` WorkloadPodGroupDisruptionMode` — `WorkloadPodGroupResourceClaim` — the ResourceClaims shared across the group.\nOnly the shapes are shared, so controllers retain full autonomy over how they name and nest these fields in their own APIs.\n\n**The `workloadbuilder` library** turns that intent into the scheduling objects. A controller describes its workload as a tree of `WorkloadItem` nodes — a node with children compiles to a `CompositePodGroupTemplate`, a node without children to a `PodGroupTemplate` — and attaches its own defaults plus the user-supplied building blocks to each node. From there, `Validate()` reports problems back at the exact field path within the controller's own API, `BuildWorkload()` compiles the tree into a Workload, and `NewPodGroup()` and `NewCompositePodGroup()` stamp out the runtime group objects.\n\nValidation is deny-by-default: a controller declares the policies and disruption modes it actually supports through `AllowedPolicies` and `AllowedDisruptionModes`, and anything outside those lists is rejected. Building blocks added in future releases therefore stay unavailable until a controller explicitly opts into them.\n\nFor hierarchical workloads where a parent controller owns the Workload and delegates group creation to its children, `NewBuilderFromExistingWorkload` lets a child materialize only its own PodGroup from the parent's Workload.\n\nNeither the building blocks nor the library have a feature gate of their own; they become user-visible through whichever controller adopts them. The native Job controller is the first to do so, and we detail it in the next section.\n\nBuilding upon the new *controller integration* APIs, the Job API now features an explicit `.spec.scheduling` field, so you can declare how a Job should be scheduled instead of relying on the Job controller to infer it from the Job's shape. This expands support well beyond static, indexed, and fully-parallel Jobs.\n\n`.spec.scheduling` is composed of the building blocks described above:\n\n`schedulingPolicy` — `schedulingConstraints` — the topology domain the Job's Pods must be co-located within.`resourceClaims` — the ResourceClaims shared by all of the Job's Pods.\nFor example:\n\n```\napiVersion: batch/v1\nkind: Job\nmetadata:\n name: distributed-training-job\n annotations:\n kubernetes.io/description: \"Distributed Job using explicit WAS scheduling with gang policy and zone topology constraints.\"\nspec:\n parallelism: 8\n completions: 8\n scheduling:\n schedulingPolicy:\n gang: {} # minCount omitted → defaults to parallelism (8)\n schedulingConstraints:\n topology:\n - key: topology.kubernetes.io/zone\n disruptionMode:\n all: {}\n template:\n spec:\n containers:\n ...\n```\n\nOmitting `.spec.scheduling`, or omitting `schedulingPolicy` within it, selects the `basic` policy, which behaves exactly like standard Job scheduling today.\n\nFor every Job it manages, the controller compiles this configuration into a Workload and a PodGroup\nowned by the Job, and sets `.spec.schedulingGroup.podGroupName` on each Pod it creates so the scheduler\ntreats them as one group. Once created, `.spec.scheduling` is immutable, with one exception:\n`schedulingPolicy.gang.minCount` can be updated, which lets you resize a running gang.\n\nAs the core WAS APIs mature, so do their integrations with [Dynamic Resource Allocation](https://kubernetes.io/docs/concepts/resource-management/dynamic-resource-allocation/)\n(DRA). Kubernetes v1.36 introduced the [`DRAWorkloadResourceClaims`](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/#DRAWorkloadResourceClaims)\nfeature gate. The associated feature allows [ResourceClaims](https://kubernetes.io/docs/concepts/resource-management/dynamic-resource-allocation/dra-api/#resourceclaims-templates)\nto be replicated and reserved for entire PodGroups and shared by all their\nmember Pods:\n\n```\napiVersion: scheduling.k8s.io/v1beta1\nkind: PodGroup\nmetadata:\n name: training-job-workers-pg\nspec:\n ...\n resourceClaims:\n - name: pg-claim\n resourceClaimTemplateName: my-claim-template\n---\napiVersion: v1\nkind: Pod\nmetadata:\n name: topology-aware-workers-pg-pod\nspec:\n ...\n schedulingGroup:\n podGroupName: training-job-workers-pg\n resourceClaims:\n - name: pg-claim\n resourceClaimTemplateName: my-claim-template\n```\n\nIn Kubernetes v1.37, the `DRAWorkloadResourceClaims` feature gate graduated to Beta.\n\nWhile the API and core functionality of the feature remain unchanged, one change\neliminates some potentially surprising behavior when disabling the feature.\nPreviously when one of a Pod's `spec.resourceClaims` referenced a\nResourceClaimTemplate and matched one of its PodGroup's `spec.resourceClaims`\nand the `DRAWorkloadResourceClaims` feature gate was **disabled**, a ResourceClaim was created for the Pod instead\nof the PodGroup. In that scenario in v1.37, no ResourceClaim is created at all.\nThis change prevents Kubernetes from creating a flood of ResourceClaims from a\nResourceClaimTemplate and potentially exhausting DRA resources when a\nclaim intended to be shared by a whole PodGroup is replicated for each and every\nPod in the group.\n\nFor more information, see the [feature documentation](https://kubernetes.io/docs/concepts/resource-management/dynamic-resource-allocation/dra-api/#workload-resource-claims).\n\nThe [Workload-Aware Scheduling Working Group](https://www.kubernetes.dev/community/community-groups/wg/workload-aware-scheduling/) (WG WAS) is currently finalizing its plans for the Kubernetes v1.38 release cycle. While the roadmap is still taking shape (stay tuned!), the following key initiatives are already planned:\n\nMany of the workload-aware scheduling improvements are now available as Beta features in v1.37, while new advanced capabilities are introduced in Alpha. Both Beta and Alpha features here are disabled by default and require manual enablement.\n\n**Beta features:**\n\n`GenericWorkload`` kube-apiserver`, `kube-controller-manager` and `kube-scheduler`.\nEnsure your manifests are updated to use the `scheduling.k8s.io/v1beta1`\n`DRAWorkloadResourceClaims`` kubelet`.\n**Alpha features:**\n\n**Topology-aware scheduling:** Enable the\n[`TopologyAwareWorkloadScheduling`](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/#TopologyAwareWorkloadScheduling)\nfeature gate on the `kube-apiserver` and `kube-scheduler`.\n\n**CompositePodGroup API:** Enable the\n[`CompositePodGroup`](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/#CompositePodGroup)\nfeature gate on the `kube-apiserver`, `kube-controller-manager` and `kube-scheduler`, and ensure the `scheduling.k8s.io/v1alpha3` API version is enabled.\nNote that enabling `CompositePodGroup` on the `kube-controller-manager` also requires the [`TopologyAwareWorkloadScheduling`](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/#TopologyAwareWorkloadScheduling) feature gate to be enabled.\n\n**Workload API integration with the Job controller:** Enable the\n[`WorkloadWithJob`](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/#WorkloadWithJob)\nfeature gate on the `kube-apiserver` and `kube-controller-manager`.\n\n**PodGroup `preemptionPolicy`:** Enable the\n[`PodGroupPreemptionPolicy`](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/#PodGroupPreemptionPolicy)\nfeature gate on the `kube-apiserver` and `kube-scheduler`.\n\n**Controller integration APIs:**\n\nThe new `workloadbuilder` library is available to developers building both out-of-tree and in-tree controllers who want to integrate with WAS. It does not require a feature gate. You can explore the library and find usage examples directly in the [`kubernetes/component-helpers`](https://github.com/kubernetes/component-helpers/tree/master/scheduling/schedulingv1/workloadbuilder) repository.\n\nWe encourage you to try out workload-aware scheduling in your test clusters and share your experiences to help shape the future of Kubernetes scheduling. You can send your feedback by:\n\nTo dive deeper into the architecture and design of these features, read the KEPs:", "url": "https://wpnews.pro/news/kubernetes-v1-37-advancing-workload-aware-scheduling", "canonical_source": "https://kubernetes.io/blog/2026/09/08/kubernetes-v1-37-advancing-workload-aware-scheduling/", "published_at": "2026-09-08 18:30:00+00:00", "updated_at": "2026-10-06 07:47:41.849018+00:00", "lang": "en", "topics": ["ai-infrastructure", "mlops", "developer-tools", "artificial-intelligence"], "entities": ["Kubernetes", "Kubernetes v1.37", "Workload API", "PodGroup API", "CompositePodGroup API", "Workload-Aware Preemption", "JobSet", "LeaderWorkerSet"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/kubernetes-v1-37-advancing-workload-aware-scheduling", "markdown": "https://wpnews.pro/news/kubernetes-v1-37-advancing-workload-aware-scheduling.md", "text": "https://wpnews.pro/news/kubernetes-v1-37-advancing-workload-aware-scheduling.txt", "jsonld": "https://wpnews.pro/news/kubernetes-v1-37-advancing-workload-aware-scheduling.jsonld"}}