[转载] Kubernetes v1.37：工作负载感知调度继续演进

举报
yd_266879620 发表于 2026/11/04 16:01:05 2026/11/04
【摘要】 AI/ML 和复杂批处理工作负载不断推动 Kubernetes 调度能力的边界。 继先前版本引入以工作负载为中心的基础增强之后， Kubernetes v1.37 为工作负载感知调度（Workload-Aware Scheduling，WAS）的演进带来了下一个重要里程碑。 在此版本中，支持编组调度的核心 Workload 和 PodGroup API、 工作负载感知抢占（Workload-...

本文为授权转载，非本账号原创。

原文：Kubernetes v1.37：工作负载感知调度继续演进（参考地址：https://kubernetes.io/zh-cn/blog/2026/09/08/kubernetes-v1-37-advancing-workload-aware-scheduling/）

原作者及译者：借由 Antoni Zawodny (Google), Bartosz Rejman (Google), Heba Elayoty (Microsoft), Jon Huhn (Microsoft), Maciej Skoczeń (Google), Maciej Wyrzuc (Google), Matt Matejczyk (Google) | 译者 Paco Xu (DaoCloud) | 2026.09.08

来源：Kubernetes 官方中文博客；许可：CC BY 4.0（参考地址：https://creativecommons.org/licenses/by/4.0/）。保留原作者和译者署名，正文仅做适配博客编辑器的排版与链接格式转换，未改写技术内容。

内容不代表原作者或 Kubernetes 项目对本账号的认可或背书。

AI/ML 和复杂批处理工作负载不断推动 Kubernetes 调度能力的边界。 继先前版本引入以工作负载为中心的基础增强之后， Kubernetes v1.37 为工作负载感知调度（Workload-Aware Scheduling，WAS）的演进带来了下一个重要里程碑。 在此版本中，支持编组调度的核心 Workload 和 PodGroup API、 工作负载感知抢占（Workload-Aware Preemption，WAP）， 以及面向 PodGroup 的共享动态资源分配（Dynamic Resource Allocation，DRA） 的 ResourceClaim 均进阶到 Beta， 进一步巩固了它们在 Kubernetes 生态系统中的作用。

为满足现代高性能分布式工作负载的分层调度需求， v1.37 引入了新的 CompositePodGroup（参考地址：https://kubernetes.io/zh-cn/docs/concepts/workloads/compositepodgroup-api/） API。 这一新 API 可以为复杂的异构 Pod 组表达多级拓扑约束、编组调度和抢占策略。 更重要的是，这项架构扩展为通常由 JobSet 和 LeaderWorkerSet（LWS）等高阶扩展 API 管理的高级工作负载结构提供了原生调度支持。

除新增这些 API 外，v1.37 还引入了一组新的控制器集成 API 和 workloadbuilder Go 库， 以降低这些特性的采用门槛。这些组件提供标准化构建块， 显著降低了树外控制器集成 WAS 能力的复杂度。 借助这些新工具，原生 Job 控制器的集成也已升级，能够充分利用扩展后的 WAS API， 从而为标准批处理工作负载启用高级调度策略、灵活的干扰模式和拓扑感知调度。

编组调度以及 Workload/PodGroup API（参考地址：https://kubernetes.io/zh-cn/blog/2026/09/08/kubernetes-v1-37-advancing-workload-aware-scheduling/#%e7%bc%96%e7%bb%84%e8%b0%83%e5%ba%a6%e4%bb%a5%e5%8f%8a-workload-podgroup-api）

Kubernetes v1.37 带来了一个重要里程碑： Workload（参考地址：https://kubernetes.io/zh-cn/docs/concepts/workloads/workload-api/） / PodGroup（参考地址：https://kubernetes.io/zh-cn/docs/concepts/workloads/podgroup-api/） API 和编组调度正式进阶到 Beta。 这次进阶意味着，面向工作负载的原生“全有或全无”调度正在逐步稳定， 可以得到更广泛的采用。

此版本中 API 和编组调度算法的主要更新包括：

进阶到 Beta 以及 API 版本变更（参考地址：https://kubernetes.io/zh-cn/blog/2026/09/08/kubernetes-v1-37-advancing-workload-aware-scheduling/#%e8%bf%9b%e9%98%b6%e5%88%b0-beta-%e4%bb%a5%e5%8f%8a-api-%e7%89%88%e6%9c%ac%e5%8f%98%e6%9b%b4）

核心 Workload 和 PodGroup API 已进阶到 v1beta1， 这意味着它们距离正式可用（GA）仅有一步之遥。 一直在测试这些特性的早期采用者请注意 Alpha 版本的转换： v1alpha2 已被 v1alpha3 完全取代。 此次转换引入了破坏性变更，旨在简化并理顺 disruptionMode 相关的 API 结构。

原生 PodGroup 入队（参考地址：https://kubernetes.io/zh-cn/blog/2026/09/08/kubernetes-v1-37-advancing-workload-aware-scheduling/#%e5%8e%9f%e7%94%9f-podgroup-%e5%85%a5%e9%98%9f）

v1.37 在底层实现了一项重要改进，使 PodGroup 成为调度队列中的一等对象。 以前，即使 Pod 属于某个 PodGroup，所有成员 Pod 仍会分别入队。 现在，只有顶层 PodGroup 对象会入队。 这确保所有 Pod 共享相同的入队行为，并为未来更高级的 PodGroup 入队策略奠定基础。

通过可变的 minCount 实现动态弹性（参考地址：https://kubernetes.io/zh-cn/blog/2026/09/08/kubernetes-v1-37-advancing-workload-aware-scheduling/#%e9%80%9a%e8%bf%87%e5%8f%af%e5%8f%98%e7%9a%84-mincount-%e5%ae%9e%e7%8e%b0%e5%8a%a8%e6%80%81%e5%bc%b9%e6%80%a7）

在早期版本中，minCount 字段用于指定成功调度 PodGroup 所需的最少 Pod 数量， 并且严格不可变。在 v1.37 中，minCount 现在可以修改。 这一 API 变更为弹性工作负载带来了更大灵活性。 控制器现在可以动态调整编组所需的最小规模， 使工作负载能够平滑降级或扩展，而不会中断已经调度的 Pod。

工作负载感知抢占（参考地址：https://kubernetes.io/zh-cn/blog/2026/09/08/kubernetes-v1-37-advancing-workload-aware-scheduling/#%e5%b7%a5%e4%bd%9c%e8%b4%9f%e8%bd%bd%e6%84%9f%e7%9f%a5%e6%8a%a2%e5%8d%a0）

在 Kubernetes v1.37 中，用于工作负载感知抢占的独立 WorkloadAwarePreemption 特性门控（参考地址：https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/feature-gates/） 已合并到 GenericWorkload 特性门控中， 成为编组调度工作中的核心组成部分。

虽然工作负载感知抢占的核心概念保持不变， 但 v1.36 和 v1.37 版本之间仍存在一些差异：

性能和最优性（参考地址：https://kubernetes.io/zh-cn/blog/2026/09/08/kubernetes-v1-37-advancing-workload-aware-scheduling/#%e6%80%a7%e8%83%bd%e5%92%8c%e6%9c%80%e4%bc%98%e6%80%a7）

为了判断集群能否通过抢占为抢占者腾出空间， 调度器会模拟移除所有潜在被抢占者并重新运行调度算法， 随后尝试使尽可能多的被抢占者免于抢占。 在 v1.36 中，每尝试豁免一个被抢占者，调度器都会重新运行一次调度算法， 以确认保留该对象后仍能为抢占者找到有效的放置方案。 在 v1.37 中，调度算法只运行一次，并根据其输出假定（Assume）抢占者 Pod 的放置位置。 后续的豁免检查只需判断，在抢占者 Pod 已被假定放置的情况下， 被抢占者能否继续留在原位置运行。

作为被抢占者的 PodGroup（参考地址：https://kubernetes.io/zh-cn/blog/2026/09/08/kubernetes-v1-37-advancing-workload-aware-scheduling/#%e4%bd%9c%e4%b8%ba%e8%a2%ab%e6%8a%a2%e5%8d%a0%e8%80%85%e7%9a%84-podgroup）

v1.36 的一个局限是，单个 Pod 的默认抢占无法感知 PodGroup， 也不会遵从其 disruptionMode 字段； 即使 PodGroup 设置了 disruptionMode: {all: {}}，单个 Pod 仍可能被干扰。 Kubernetes v1.37 消除了这一限制： 默认抢占现在会遵从 PodGroup 的 disruptionMode 字段。

重命名 disruptionMode 字段（参考地址：https://kubernetes.io/zh-cn/blog/2026/09/08/kubernetes-v1-37-advancing-workload-aware-scheduling/#%e9%87%8d%e5%91%bd%e5%90%8d-disruptionmode-%e5%ad%97%e6%ae%b5）

在 API 进阶到 Beta 的过程中，disruptionMode 字段发生了变更， 使其命名不再与 PodGroup 对象耦合， 从而可以在 PodGroup 和 CompositePodGroup 中使用一致的名称。 模式名称变更如下：PodGroup 改为 all，Pod 改为 single。

支持 preemptionPolicy（参考地址：https://kubernetes.io/zh-cn/blog/2026/09/08/kubernetes-v1-37-advancing-workload-aware-scheduling/#%e6%94%af%e6%8c%81-preemptionpolicy）

在 v1.36 中，PodGroup 没有 preemptionPolicy 字段。 只要组成 PodGroup 的所有 Pod 都没有设置 preemptionPolicy: Never， PodGroup 就可以执行抢占。 在 v1.37 中，启用 PodGroupPreemptionPolicy（参考地址：https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/feature-gates/#PodGroupPreemptionPolicy） 特性门控后，PodGroup 也会具有 preemptionPolicy 字段。 该字段是决定 PodGroup 能否执行抢占的权威字段。

CompositePodGroup API（参考地址：https://kubernetes.io/zh-cn/blog/2026/09/08/kubernetes-v1-37-advancing-workload-aware-scheduling/#compositepodgroup-api）

在 Kubernetes v1.36 中，工作负载感知调度在静态工作负载模板（Workload） 和运行时组状态（PodGroup）之间建立了清晰的分离， 但所支持的调度策略仅限于单个扁平组。 Kubernetes v1.37 引入的 CompositePodGroup API 扩展了这一模型， 以支持分层调度需求。

此 API 允许使用者将工作负载组织为由 CompositePodGroup 和 PodGroup 对象组成的树形层次结构， 从而表达多级调度需求。 每个 CompositePodGroup 都携带适用于其他组（CompositePodGroup 和/或 PodGroup）的策略与约束， 这类似于 PodGroup 管理扁平 Pod 组调度行为的方式。 调度器会将这样的层次结构视为单个调度单元， 并力求满足该层次结构中每个组所指定的要求。

定义工作负载层次结构（参考地址：https://kubernetes.io/zh-cn/blog/2026/09/08/kubernetes-v1-37-advancing-workload-aware-scheduling/#%e5%ae%9a%e4%b9%89%e5%b7%a5%e4%bd%9c%e8%b4%9f%e8%bd%bd%e5%b1%82%e6%ac%a1%e7%bb%93%e6%9e%84）

要表达多级调度需求，你需要在 Workload 对象中定义模板层次结构。 然后，控制器根据该层次结构创建对应的 CompositePodGroup 和 PodGroup 对象。

为此，Workload API 新增了 spec.compositePodGroupTemplates 字段。 每个 CompositePodGroupTemplate 都为父 CompositePodGroup 定义一个模板， 并直接嵌套用于派生其子组的模板 （podGroupTemplates 和/或 compositePodGroupTemplates）。

下面的 Workload 对象示例定义了一个两级模板层次结构：

apiVersion: scheduling.k8s.io/v1beta1
kind: Workload
metadata:
  name: example-workload
  annotations:
    kubernetes.io/description: "要求 4 个 Worker Pod 和 1 个 Driver Pod 一起调度的两级工作负载层次结构。"
spec:
  compositePodGroupTemplates:
    - name: workload-root
      schedulingPolicy:
        gang:
          minGroupCount: 2
      podGroupTemplates:
        - name: workers
          schedulingPolicy:
            gang:
              minCount: 4
        - name: driver
          schedulingPolicy:
            gang:
              minCount: 1

创建 example-workload 后，控制器可以根据这些模板生成对应的运行时组对象：

  1. 一个根 CompositePodGroup，它引用 example-workload 中的 workload-root 模板， 并携带其组级调度策略（设置了 minGroupCount: 2 的编组调度）：

    apiVersion: scheduling.k8s.io/v1alpha3
kind: CompositePodGroup
metadata:
  name: example-root-group
  annotations:
    kubernetes.io/description: "协调工作器和驱动 PodGroup 子组进行编组调度的根组。"
spec:
  workloadRef:
    workloadName: example-workload
    templateName: workload-root
  schedulingPolicy:
    gang:
      minGroupCount: 2

  1. 两个 PodGroup 子对象（example-workload-workers 和 example-workload-driver）， 它们分别引用 example-workload 中对应的叶级模板， 并通过 parentCompositePodGroupName 链接到根组：

    apiVersion: scheduling.k8s.io/v1beta1
kind: PodGroup
metadata:
  name: example-workload-workers
  annotations:
    kubernetes.io/description: "要求至少 4 个 Pod 一起调度的工作器组。"
spec:
  parentCompositePodGroupName: example-root-group
  workloadRef:
    workloadName: example-workload
    templateName: workers
  schedulingPolicy:
    gang:
      minCount: 4
---
apiVersion: scheduling.k8s.io/v1beta1
kind: PodGroup
metadata:
  name: example-workload-driver
  annotations:
    kubernetes.io/description: "要求 1 个 Pod 与工作器一起调度的驱动组。"
spec:
  parentCompositePodGroupName: example-root-group
  workloadRef:
    workloadName: example-workload
    templateName: driver
  schedulingPolicy:
    gang:
      minCount: 1

多级编组调度的工作原理（参考地址：https://kubernetes.io/zh-cn/blog/2026/09/08/kubernetes-v1-37-advancing-workload-aware-scheduling/#%e5%a4%9a%e7%ba%a7%e7%bc%96%e7%bb%84%e8%b0%83%e5%ba%a6%e7%9a%84%e5%b7%a5%e4%bd%9c%e5%8e%9f%e7%90%86）

为了调度分层工作负载，kube-scheduler 会将整个组树作为统一的调度单元进行评估：

  • 递归评估：调度器从根 CompositePodGroup 开始向下遍历层次结构， 直至叶级 PodGroup 对象。 在每一层，只有其子组满足调度策略时，父 CompositePodGroup 才会被视为可调度 （例如，使用编组策略时至少放置 minGroupCount 个子组）； 同时，每个叶级 PodGroup 必须满足自己的 Pod 级策略 （例如，使用编组策略时至少放置 minCount 个成员 Pod）。
  • 全有或全无调度：一旦找到满足根 CompositePodGroup 要求的有效子组组合， 整个层次结构中的 Pod 就会以原子方式完成调度和绑定。 如果根组无法满足策略约束，整个层次结构会保持不可调度状态，且不会绑定任何 Pod， 从而避免部分调度上线和死锁问题。

CompositePodGroup API 的工作负载感知抢占（参考地址：https://kubernetes.io/zh-cn/blog/2026/09/08/kubernetes-v1-37-advancing-workload-aware-scheduling/#compositepodgroup-api-%e7%9a%84%e5%b7%a5%e4%bd%9c%e8%b4%9f%e8%bd%bd%e6%84%9f%e7%9f%a5%e6%8a%a2%e5%8d%a0）

Kubernetes v1.37 扩展了工作负载感知抢占，使其也支持 CompositePodGroup 层次结构。 具体而言，如果 CompositePodGroup 因集群容量不足而无法调度， 调度器可以调用抢占机制来驱逐优先级较低的工作负载， 从而容纳属于该 CompositePodGroup 的 Pod。

CompositePodGroup 本身也可以被选为抢占对象。 为了指定抢占期间的预期行为，工作负载所有者可以在 CompositePodGroup 规约中设置适当的 disruptionMode：

  • single：允许 CompositePodGroup 中的各个子组被独立抢占和干扰。 未设置 disruptionMode 时采用此行为。
  • all：在整个 CompositePodGroup 层次结构中强制执行“全有或全无”的干扰语义。 如果后代子树中的任何 Pod 必须被抢占，调度器会一起驱逐整个层次结构中的所有 Pod。

拓扑感知调度（参考地址：https://kubernetes.io/zh-cn/blog/2026/09/08/kubernetes-v1-37-advancing-workload-aware-scheduling/#%e6%8b%93%e6%89%91%e6%84%9f%e7%9f%a5%e8%b0%83%e5%ba%a6）

在 Kubernetes v1.37 中，拓扑感知调度扩展为支持复杂的多级工作负载层次结构， 同时提升了现有单级部署的性能。

多级拓扑感知调度（参考地址：https://kubernetes.io/zh-cn/blog/2026/09/08/kubernetes-v1-37-advancing-workload-aware-scheduling/#%e5%a4%9a%e7%ba%a7%e6%8b%93%e6%89%91%e6%84%9f%e7%9f%a5%e8%b0%83%e5%ba%a6）

在 Kubernetes v1.36 中，我们引入了基础性的拓扑感知调度， 允许你直接在 PodGroup 上定义共置约束。 这种方式对单级分组非常有效，但复杂的分布式工作负载 （例如大规模 AI/ML 训练、JobSet 部署， 或通过 LeaderWorkerSet（LWS）实现的解聚推理） 通常需要同时在集群基础设施的多个层级上实现共置。

例如，整个工作负载可能需要在单个可用区内运行， 而工作负载的不同部分（例如特定工作器组或驱动进程） 则要求严格共置在特定服务器机架内。

在 Kubernetes v1.37 中，伴随着新的 CompositePodGroup API（scheduling.k8s.io/v1alpha3）， 拓扑感知调度也扩展为支持多级拓扑感知调度。 现在，你可以在组层次结构的不同层级上指定拓扑约束， 从而表达复杂的共置要求。

自顶向下解析拓扑约束（参考地址：https://kubernetes.io/zh-cn/blog/2026/09/08/kubernetes-v1-37-advancing-workload-aware-scheduling/#%e8%87%aa%e9%a1%b6%e5%90%91%e4%b8%8b%e8%a7%a3%e6%9e%90%e6%8b%93%e6%89%91%e7%ba%a6%e6%9d%9f）

在分层调度期间，kube-scheduler 以自顶向下的方式解析多级拓扑约束。 具体而言，调度子组时所考虑的拓扑域， 会被限制在与父组假定放置位置相对应的拓扑域之内。

配置和运行时执行（参考地址：https://kubernetes.io/zh-cn/blog/2026/09/08/kubernetes-v1-37-advancing-workload-aware-scheduling/#%e9%85%8d%e7%bd%ae%e5%92%8c%e8%bf%90%e8%a1%8c%e6%97%b6%e6%89%a7%e8%a1%8c）

借助更新后的 Workload API（scheduling.k8s.io/v1beta1）， 你可以直接在 compositePodGroupTemplates 中配置多级拓扑约束。 在以下示例中，父模板将整个工作负载限制在单个可用区 （topology.kubernetes.io/zone）内， 而 workers 和 driver 子模板则将各自的 Pod 限制在所选可用区内的服务器机架 （topology.example.com/rack）中：

apiVersion: scheduling.k8s.io/v1beta1
kind: Workload
metadata:
  name: multi-level-tas-workload
  namespace: job-ns
  annotations:
    kubernetes.io/description: "为根组定义可用区级共置，并为子组定义机架级共置的工作负载。"
spec:
  compositePodGroupTemplates:
  - name: root
    schedulingPolicy:
      gang:
        minGroupCount: 2
    schedulingConstraints:
      topology:
      - key: topology.kubernetes.io/zone
    podGroupTemplates:
    - name: workers
      schedulingPolicy:
        gang:
          minCount: 8
      schedulingConstraints:
        topology:
        - key: topology.example.com/rack
    - name: driver
      schedulingPolicy:
        gang:
          minCount: 1
      schedulingConstraints:
        topology:
        - key: topology.example.com/rack

当控制器在运行时创建此工作负载的实例时， 它会根据这些模板生成相应的运行时对象：

  1. 引用 root 模板的根 CompositePodGroup， 携带可用区拓扑约束和分层编组调度策略。
  2. 两个 PodGroup 子对象（tas-workload-workers 和 tas-workload-driver）， 各自通过规约中的 parentCompositePodGroupName 字段， 将根 CompositePodGroup 引用为父组：
apiVersion: scheduling.k8s.io/v1alpha3
kind: CompositePodGroup
metadata:
  name: tas-workload-root
  namespace: job-ns
  annotations:
    kubernetes.io/description: "将整个工作负载限制在单个可用区内的根组。"
spec:
  workloadRef:
    workloadName: multi-level-tas-workload
    templateName: root
  schedulingPolicy:
    gang:
      minGroupCount: 2
  schedulingConstraints:
    topology:
    - key: topology.kubernetes.io/zone
---
apiVersion: scheduling.k8s.io/v1beta1
kind: PodGroup
metadata:
  name: tas-workload-workers
  namespace: job-ns
  annotations:
    kubernetes.io/description: "要求将 8 个 Pod 共置在所选可用区的单个机架内的工作器组。"
spec:
  parentCompositePodGroupName: tas-workload-root
  workloadRef:
    workloadName: multi-level-tas-workload
    templateName: workers
  schedulingPolicy:
    gang:
      minCount: 8
  schedulingConstraints:
    topology:
    - key: topology.example.com/rack
---
apiVersion: scheduling.k8s.io/v1beta1
kind: PodGroup
metadata:
  name: tas-workload-driver
  namespace: job-ns
  annotations:
    kubernetes.io/description: "要求将 1 个 Pod 放置在所选可用区内某个机架中的驱动组。"
spec:
  parentCompositePodGroupName: tas-workload-root
  workloadRef:
    workloadName: multi-level-tas-workload
    templateName: driver
  schedulingPolicy:
    gang:
      minCount: 1
  schedulingConstraints:
    topology:
    - key: topology.example.com/rack

在调度期间，调度器会为 tas-workload-root 评估集群中的多个候选可用区。 对于每个候选可用区，调度器按照机架拓扑对节点进行分组， 以探索在该可用区内严格放置 tas-workload-workers 和 tas-workload-driver 的可行机架方案；在作出调度决策之前， 调度器会系统地评估可用区和机架间的多种组合。

通过允许以分层方式对拓扑约束建模， Kubernetes v1.37 提供了一种结构化方法， 用于表达复杂集群基础设施中的多级共置要求。

单级拓扑感知调度（TAS）的性能改进（参考地址：https://kubernetes.io/zh-cn/blog/2026/09/08/kubernetes-v1-37-advancing-workload-aware-scheduling/#%e5%8d%95%e7%ba%a7%e6%8b%93%e6%89%91%e6%84%9f%e7%9f%a5%e8%b0%83%e5%ba%a6-tas-%e7%9a%84%e6%80%a7%e8%83%bd%e6%94%b9%e8%bf%9b）

除了以 Alpha 形式引入多级层次结构外， Kubernetes v1.37 还降低了现有单级拓扑感知调度的放置评估开销。 我们正在持续优化 kube-scheduler 中放置评估算法的效率， 并计划在未来版本中进一步提升性能。

控制器集成 API（参考地址：https://kubernetes.io/zh-cn/blog/2026/09/08/kubernetes-v1-37-advancing-workload-aware-scheduling/#%e6%8e%a7%e5%88%b6%e5%99%a8%e9%9b%86%e6%88%90-api）

Kubernetes v1.37 引入了新的标准构建块， 让每个控制器都能在自己的 API 中公开相同的调度原语， 并共享将这些原语转换为调度对象的同一套逻辑。 这些原语表达特定的调度行为（例如策略或干扰逻辑）， 同时允许各个控制器灵活地命名字段。 原生 Job 控制器就是一个典型示例，下一节将对其进行详细介绍。

以 WorkloadPodGroup 为前缀的类型描述叶级 Pod 组； 以 WorkloadCompositePodGroup 为前缀的类型描述由多个组组成的组。 控制器将这些类型原样嵌入自己的 API 中， 并可以使用适合其领域的任意字段名称：

  • WorkloadPodGroupSchedulingPolicy：可以是表示标准逐 Pod 调度的 basic， 也可以是带 minCount 的 gang；对应的 CompositePodGroup 类型则使用 minGroupCount。
  • WorkloadPodGroupSchedulingConstraints：用于限定组内 Pod 共置范围的拓扑约束 （topology[].key）。
  • WorkloadPodGroupDisruptionMode：取值为 single 或 all， 其抢占语义如本文前面所述。
  • WorkloadPodGroupResourceClaim：整个组共享的 ResourceClaim。

共享的只是这些结构，因此控制器仍能完全自主决定 如何在自己的 API 中命名和嵌套这些字段。

workloadbuilder 库会将这些意图转换为调度对象。 控制器将其工作负载描述为由 WorkloadItem 节点组成的树： 带子节点的节点会被编译为 CompositePodGroupTemplate， 没有子节点的节点会被编译为 PodGroupTemplate； 控制器还会为每个节点附加自己的默认值和用户提供的构建块。 随后，Validate() 会在控制器自身 API 中精确对应的字段路径上报告问题， BuildWorkload() 将这棵树编译为 Workload， 而 NewPodGroup() 和 NewCompositePodGroup() 则生成运行时组对象。

校验遵循默认拒绝原则：控制器通过 AllowedPolicies 和 AllowedDisruptionModes 声明其实际支持的策略和干扰模式，列表以外的任何值都会被拒绝。 因此，在控制器显式选择采用之前，未来版本新增的构建块都将保持不可用。

对于由父控制器拥有 Workload、并将组创建工作委派给子控制器的分层工作负载， NewBuilderFromExistingWorkload 允许子控制器仅从父控制器的 Workload 中实例化自己的 PodGroup。

这些构建块和库都没有自己的特性门控； 它们会通过采用它们的控制器呈现给用户。 原生 Job 控制器是第一个采用它们的控制器，下一节将详细介绍。

与 Job 控制器集成（参考地址：https://kubernetes.io/zh-cn/blog/2026/09/08/kubernetes-v1-37-advancing-workload-aware-scheduling/#%e4%b8%8e-job-%e6%8e%a7%e5%88%b6%e5%99%a8%e9%9b%86%e6%88%90）

基于新的控制器集成 API，Job API 现在提供显式的 .spec.scheduling 字段， 因此你可以声明 Job 应如何调度， 而不必依赖 Job 控制器根据 Job 的结构来推断调度方式。 这使支持范围远远超出了静态 Job、带索引的 Job 和完全并行的 Job。

.spec.scheduling 由上述构建块组成：

  • schedulingPolicy：basic 表示标准的逐 Pod 调度， gang 表示全有或全无调度。
  • schedulingConstraints：Job 的 Pod 必须共置于其中的拓扑域。
  • disruptionMode：Job 的 Pod 是可以逐个抢占（single）， 还是只能作为整体抢占（all）。
  • resourceClaims：由 Job 的所有 Pod 共享的 ResourceClaim 列表。

例如：

apiVersion: batch/v1
kind: Job
metadata:
  name: distributed-training-job
  annotations:
    kubernetes.io/description: "使用显式 WAS 调度、编组策略和可用区拓扑约束的分布式 Job。"
spec:
  parallelism: 8
  completions: 8
  scheduling:
    schedulingPolicy:
      gang: {}                # 省略 minCount → 默认取 parallelism (8)
    schedulingConstraints:
      topology:
      - key: topology.kubernetes.io/zone
    disruptionMode:
      all: {}
  template:
    spec:
      containers:
      ...

省略 .spec.scheduling，或省略其中的 schedulingPolicy， 将选择 basic 策略，其行为与当前的标准 Job 调度完全相同。

对于其管理的每个 Job，控制器都会将此配置编译为由该 Job 所拥有的 Workload 和 PodGroup，并在其创建的每个 Pod 上设置 .spec.schedulingGroup.podGroupName，使调度器将这些 Pod 视为一个组。 .spec.scheduling 创建后不可变，但有一个例外： 可以更新 schedulingPolicy.gang.minCount， 从而调整正在运行的编组规模。

面向工作负载的 DRA ResourceClaim 支持（参考地址：https://kubernetes.io/zh-cn/blog/2026/09/08/kubernetes-v1-37-advancing-workload-aware-scheduling/#%e9%9d%a2%e5%90%91%e5%b7%a5%e4%bd%9c%e8%b4%9f%e8%bd%bd%e7%9a%84-dra-resourceclaim-%e6%94%af%e6%8c%81）

随着核心 WAS API 逐渐成熟，它们与动态资源分配（参考地址：https://kubernetes.io/zh-cn/docs/concepts/scheduling-eviction/dynamic-resource-allocation/） （DRA）的集成也在走向成熟。 Kubernetes v1.36 引入了 DRAWorkloadResourceClaims（参考地址：https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/feature-gates/#DRAWorkloadResourceClaims） 特性门控。相关特性允许复制 ResourceClaim（参考地址：https://kubernetes.io/zh-cn/docs/concepts/scheduling-eviction/dynamic-resource-allocation/#resourceclaims-templates） 并将其预留给整个 PodGroup，由组内所有成员 Pod 共享：

apiVersion: scheduling.k8s.io/v1beta1
kind: PodGroup
metadata:
  name: training-job-workers-pg
spec:
  ...
  resourceClaims:
    - name: pg-claim
      resourceClaimTemplateName: my-claim-template
---
apiVersion: v1
kind: Pod
metadata:
  name: topology-aware-workers-pg-pod
spec:
  ...
  schedulingGroup:
    podGroupName: training-job-workers-pg
  resourceClaims:
    - name: pg-claim
      resourceClaimTemplateName: my-claim-template

在 Kubernetes v1.37 中，DRAWorkloadResourceClaims 特性门控已进阶到 Beta。

虽然该特性的 API 和核心功能保持不变， 但有一项变更消除了禁用此特性时可能令人意外的行为。 以前，当 Pod 的 spec.resourceClaims 中某一项引用了 ResourceClaimTemplate， 并且与其 PodGroup 的某个 spec.resourceClaims 匹配， 同时 DRAWorkloadResourceClaims 特性门控处于禁用状态时， 系统会为 Pod 而非 PodGroup 创建 ResourceClaim。 在 v1.37 的同一场景中，系统完全不会创建 ResourceClaim。 这一变更可避免 Kubernetes 根据 ResourceClaimTemplate 大量创建 ResourceClaim： 如果原本应由整个 PodGroup 共享的申领被复制给组内的每一个 Pod， 就可能耗尽 DRA 资源。

有关更多信息，请参阅特性文档（参考地址：https://kubernetes.io/zh-cn/docs/concepts/scheduling-eviction/dynamic-resource-allocation/#workload-resourceclaims）。

后续计划（参考地址：https://kubernetes.io/zh-cn/blog/2026/09/08/kubernetes-v1-37-advancing-workload-aware-scheduling/#%e5%90%8e%e7%bb%ad%e8%ae%a1%e5%88%92）

工作负载感知调度工作组（参考地址：https://www.kubernetes.dev/community/community-groups/wg/workload-aware-scheduling/） （WG WAS）正在敲定 Kubernetes v1.38 发布周期的计划。 虽然路线图仍在逐步成形（敬请关注！）， 但以下关键工作已在计划之中：

  • Workload 和 PodGroup API 进阶到 GA： 将工作负载感知调度的核心基础巩固为稳定的 Kubernetes API。
  • 拓扑感知调度（TAS）和 CompositePodGroup（CPG）进阶到 Beta： 让这些高级放置和分层调度特性达到 Beta 阶段。
  • 控制器集成构建块进阶到 Beta： 进一步完善集成 API，确保可靠、完善的开发体验。
  • 提高采用率并扩大集成范围： 通过将工作负载感知调度与其他控制器集成来扩展生态系统， 尤其关注 JobSet（参考地址：https://github.com/kubernetes-sigs/jobset） 等分层编排器。
  • Kueue 集成： 推动 WAS 与 Kueue（参考地址：https://kueue.sigs.k8s.io/） 更紧密地协同。 短期内，我们的目标是确保 Kueue 能够充分感知 WAS 特性，实现无缝互操作。 长期来看，我们希望 Kueue 将 WAS 用作底层引擎， 以实现编组调度和拓扑感知放置等能力。

快速开始（参考地址：https://kubernetes.io/zh-cn/blog/2026/09/08/kubernetes-v1-37-advancing-workload-aware-scheduling/#%e5%bf%ab%e9%80%9f%e5%bc%80%e5%a7%8b）

许多工作负载感知调度改进现在已在 v1.37 中以 Beta 特性的形式提供， 同时还有新的高级能力以 Alpha 特性的形式引入。 这里的 Beta 和 Alpha 特性均默认禁用，需要手动启用。

Beta 特性：

  • Workload API、编组调度和抢占： GenericWorkload（参考地址：https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/feature-gates/#GenericWorkload） 特性门控（现在集成了编组调度和工作负载感知抢占）处于 Beta 阶段， 并且在 kube-apiserver、kube-controller-manager 和 kube-scheduler 上默认禁用。 请确保清单已更新为使用 scheduling.k8s.io/v1beta1 API 组（参考地址：https://kubernetes.io/zh-cn/docs/concepts/overview/kubernetes-api/#api-groups-and-versioning）。
  • 面向工作负载的 DRA ResourceClaim 支持： 在 kube-apiserver、kube-controller-manager、kube-scheduler 和 kubelet 上启用 DRAWorkloadResourceClaims（参考地址：https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/feature-gates/#DRAWorkloadResourceClaims） 特性门控。

Alpha 特性：

  • 拓扑感知调度： 在 kube-apiserver 和 kube-scheduler 上启用 TopologyAwareWorkloadScheduling（参考地址：https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/feature-gates/#TopologyAwareWorkloadScheduling） 特性门控。

  • CompositePodGroup API： 在 kube-apiserver、kube-controller-manager 和 kube-scheduler 上启用 CompositePodGroup（参考地址：https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/feature-gates/#CompositePodGroup） 特性门控，并确保启用了 scheduling.k8s.io/v1alpha3 API 版本。 请注意，在 kube-controller-manager 上启用 CompositePodGroup， 还需要启用 TopologyAwareWorkloadScheduling（参考地址：https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/feature-gates/#TopologyAwareWorkloadScheduling） 特性门控。

  • Workload API 与 Job 控制器集成： 在 kube-apiserver 和 kube-controller-manager 上启用 WorkloadWithJob（参考地址：https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/feature-gates/#WorkloadWithJob） 特性门控。

  • PodGroup preemptionPolicy： 在 kube-apiserver 和 kube-scheduler 上启用 PodGroupPreemptionPolicy（参考地址：https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/feature-gates/#PodGroupPreemptionPolicy） 特性门控。

控制器集成 API：

新的 workloadbuilder 库可供希望与 WAS 集成的树外和树内控制器开发者使用。 它不需要特性门控。 你可以直接在 kubernetes/component-helpers（参考地址：https://github.com/kubernetes/component-helpers/tree/master/scheduling/schedulingv1/workloadbuilder） 仓库中查看该库并查找用法示例。

我们鼓励你在测试集群中试用工作负载感知调度并分享经验， 帮助塑造 Kubernetes 调度的未来。 你可以通过以下方式提供反馈：

  • 通过 Slack（#wg-workload-aware-scheduling）（参考地址：https://kubernetes.slack.com/archives/C0AHLJ0EAEL） 与我们联系。
  • 参加 WG Workload-Aware Scheduling（参考地址：https://www.kubernetes.dev/community/community-groups/wg/workload-aware-scheduling/） 或 SIG Scheduling（参考地址：https://www.kubernetes.dev/community/community-groups/sigs/scheduling/#meetings） 会议。
  • 在 Kubernetes 仓库中提交新的 Issue（参考地址：https://github.com/kubernetes/kubernetes/issues）。

了解更多（参考地址：https://kubernetes.io/zh-cn/blog/2026/09/08/kubernetes-v1-37-advancing-workload-aware-scheduling/#%e4%ba%86%e8%a7%a3%e6%9b%b4%e5%a4%9a）

要深入了解这些特性的架构和设计，请阅读以下 KEP：

  • KEP-4671：Kubernetes 中的编组调度支持（参考地址：https://www.kubernetes.dev/resources/keps/4671/）
  • KEP-5710：工作负载感知抢占（参考地址：https://www.kubernetes.dev/resources/keps/5710/）
  • KEP-5732：拓扑感知工作负载调度（参考地址：https://www.kubernetes.dev/resources/keps/5732/）
  • KEP-6012：CompositePodGroup API（参考地址：https://www.kubernetes.dev/resources/keps/6012/）
  • KEP-6089：WAS 控制器集成 API（参考地址：https://www.kubernetes.dev/resources/keps/6089/）
  • KEP-5547：WAS Workload API 与 Job 控制器集成（参考地址：https://www.kubernetes.dev/resources/keps/5547/）
  • KEP-5729：DRA 面向工作负载的 ResourceClaim 支持（参考地址：https://www.kubernetes.dev/resources/keps/5729/）
  • ←上一页（参考地址：https://kubernetes.io/zh-cn/blog/2026/09/03/kubernetes-v1-37-dra-updates/）
  • 下一页→（参考地址：https://kubernetes.io/zh-cn/blog/2026/09/14/kubernetes-v1-37-memory-qos-graduates-to-beta/）
最后修改 August 26, 2026 at 6:44 PM PST: Add Chinese translation of the v1.37 workload-aware scheduling blog (ab3272d400)（参考地址：https://github.com/kubernetes/website/commit/ab3272d4004a68352b76182f71fe6c7ad9fce51f）
【版权声明】本文为华为云社区用户转载文章，如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱： cloudbbs@huaweicloud.com
Kubernetes Linux 云原生
  • 点赞
  • 收藏
  • 关注作者

评论（0）

0/1000
抱歉，系统识别当前为高风险访问，暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称，即可参与社区互动！

*长度不超过10个汉字或20个英文字符，设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符，设置后3个月内不可修改。

确认 取消

加入云驻计划，成为创作者

  • 华为云周边好礼
  • 免费体验产品
  • 特殊身份标识
  • 线下官方门票
  • 内部专家零距离
  • 与10000+优质创作者共同成长
立即加入