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

借由 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

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 API。这一新 API 可以为复杂的异构 Pod 组表达多级拓扑约束、编组调度和抢占策略。更重要的是，这项架构扩展为通常由 JobSet 和 LeaderWorkerSet（LWS）等高阶扩展 API 管理的高级工作负载结构提供了原生调度支持。

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

编组调度以及 Workload/PodGroup API

Kubernetes v1.37 带来了一个重要里程碑： Workload / PodGroup API 和编组调度正式进阶到 Beta。这次进阶意味着，面向工作负载的原生“全有或全无”调度正在逐步稳定，可以得到更广泛的采用。

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

进阶到 Beta 以及 API 版本变更

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

原生 PodGroup 入队

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

通过可变的 minCount 实现动态弹性

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

工作负载感知抢占

在 Kubernetes v1.37 中，用于工作负载感知抢占的独立 WorkloadAwarePreemption 特性门控已合并到 GenericWorkload 特性门控中，成为编组调度工作中的核心组成部分。

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

性能和最优性

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

作为被抢占者的 PodGroup

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

重命名 `disruptionMode` 字段

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

支持 `preemptionPolicy`

在 v1.36 中，PodGroup 没有 preemptionPolicy 字段。只要组成 PodGroup 的所有 Pod 都没有设置 preemptionPolicy: Never， PodGroup 就可以执行抢占。在 v1.37 中，启用 PodGroupPreemptionPolicy 特性门控后，PodGroup 也会具有 preemptionPolicy 字段。该字段是决定 PodGroup 能否执行抢占的权威字段。

CompositePodGroup API

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

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

定义工作负载层次结构

要表达多级调度需求，你需要在 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 后，控制器可以根据这些模板生成对应的运行时组对象：

一个根 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

两个 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

多级编组调度的工作原理

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

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

CompositePodGroup API 的工作负载感知抢占

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

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

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

拓扑感知调度

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

多级拓扑感知调度

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

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

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

自顶向下解析拓扑约束

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

配置和运行时执行

借助更新后的 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

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

引用 root 模板的根 CompositePodGroup，携带可用区拓扑约束和分层编组调度策略。
两个 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）的性能改进

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

控制器集成 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 控制器集成

基于新的控制器集成 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 支持

随着核心 WAS API 逐渐成熟，它们与动态资源分配（DRA）的集成也在走向成熟。 Kubernetes v1.36 引入了 DRAWorkloadResourceClaims 特性门控。相关特性允许复制 ResourceClaim 并将其预留给整个 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 资源。

有关更多信息，请参阅特性文档。

后续计划

工作负载感知调度工作组（WG WAS）正在敲定 Kubernetes v1.38 发布周期的计划。虽然路线图仍在逐步成形（敬请关注！），但以下关键工作已在计划之中：

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

快速开始

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

Beta 特性：

Workload API、编组调度和抢占： GenericWorkload 特性门控（现在集成了编组调度和工作负载感知抢占）处于 Beta 阶段，并且在 kube-apiserver、kube-controller-manager 和 kube-scheduler 上默认禁用。请确保清单已更新为使用 scheduling.k8s.io/v1beta1 API 组。
面向工作负载的 DRA ResourceClaim 支持： 在 kube-apiserver、kube-controller-manager、kube-scheduler 和 kubelet 上启用 DRAWorkloadResourceClaims 特性门控。

Alpha 特性：

拓扑感知调度： 在 kube-apiserver 和 kube-scheduler 上启用 TopologyAwareWorkloadScheduling 特性门控。
CompositePodGroup API： 在 kube-apiserver、kube-controller-manager 和 kube-scheduler 上启用 CompositePodGroup 特性门控，并确保启用了 scheduling.k8s.io/v1alpha3 API 版本。请注意，在 kube-controller-manager 上启用 CompositePodGroup，还需要启用 TopologyAwareWorkloadScheduling 特性门控。
Workload API 与 Job 控制器集成： 在 kube-apiserver 和 kube-controller-manager 上启用 WorkloadWithJob 特性门控。
PodGroup preemptionPolicy： 在 kube-apiserver 和 kube-scheduler 上启用 PodGroupPreemptionPolicy 特性门控。

控制器集成 API：

新的 workloadbuilder 库可供希望与 WAS 集成的树外和树内控制器开发者使用。它不需要特性门控。你可以直接在 kubernetes/component-helpers 仓库中查看该库并查找用法示例。

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

通过 Slack（#wg-workload-aware-scheduling）与我们联系。
参加 WG Workload-Aware Scheduling 或 SIG Scheduling 会议。
在 Kubernetes 仓库中提交新的 Issue。

了解更多

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

最后修改 August 26, 2026 at 6:44 PM PST: Add Chinese translation of the v1.37 workload-aware scheduling blog (ab3272d400)