Workload API

• 1: Pod 组策略
• 2: Pod 组干扰和优先级
• 3: 拓扑感知工作负载调度

apiVersion: scheduling.k8s.io/v1alpha1
kind: Workload
metadata:
  name: training-job-workload
  namespace: some-ns
spec:
  controllerRef:
    apiGroup: batch
    kind: Job
    name: training-job
  podGroups:
  - name: workers
    policy:
      gang:
        # 只有当可以同时运行 4 个 Pod 时，此 gang 才可调度
        minCount: 4

1 - Pod 组策略

在 Workload 中定义的每一个 Pod 组都必须声明一个调度策略。此策略决定调度器如何处理这一组 Pod。

策略类别

当前 API 支持两种策略类别：basic 和 gang。你必须为每个 Pod 组指定一种策略。

Basic 策略

basic 策略指示调度器将组内的所有 Pod 视为独立实体，并使用标准的 Kubernetes 行为来调度这些 Pod。

使用 basic 策略的主要原因是对 Workload 中的 Pod 进行组织，以提升可观测性和管理能力。

此策略可用于那些不需要同时启动但逻辑上属于应用的 Workload 组； 同时也为未来可能引入的、不一定要求“全有或全无”调度方式的组约束提供扩展空间。

policy:
  basic: {}

Gang 策略

gang 策略强制执行“全有或全无”的调度机制。这对于紧密耦合的工作负载非常重要，因为部分启动可能导致死锁或资源浪费。

此策略常用于 Job 或其他需要所有 Worker 同时运行才能推进的批处理任务。

gang 策略需要配置 minCount 参数：

policy:
  gang:
    # 组被允许调度所需的最小 Pod 数量
    minCount: 4

接下来

• 阅读 Gang 调度算法。

2 - Pod 组干扰和优先级

PodGroup 可以声明一个干扰模式。此模式规定了调度器如何干扰运行中的 PodGroup， 例如为了容纳更高优先级的 PodGroup。PodGroup 还具有优先级， 该优先级会在工作负载感知抢占 事件中覆盖来自该组的单个 Pod 的优先级。

干扰模式类型

API 支持两种干扰模式：Pod 和 PodGroup。默认模式是 Pod。

Pod

Pod 模式指示调度器将组中的所有 Pod 视为单独的实体， 允许从 PodGroup 中独立干扰单个 Pod。

PodGroup

PodGroup 模式强调干扰的 "全有或全无" 语义。 它指示调度器必须同时干扰 PodGroup 中的所有 Pod。

Pod 组优先级

PodGroup 使用与单个 Pod 相同的 PriorityClass 概念。 创建一个或多个 PriorityClass 后，你可以创建一个 PodGroup， 并在其规约中指定这些 PriorityClass 名称之一。 优先级准入控制器使用 priorityClassName 字段并填充优先级的整数值。 如果未找到优先级类，则 PodGroup 会被拒绝。 当 PodGroup 未设置 priorityClassName 时，Kubernetes 会寻找默认值（globalDefault 设置为 true 的 PriorityClass）。 如果没有 globalDefault 设置为 true 的 PriorityClass， 则没有 priorityClassName 的 PodGroup 优先级为零。

PodGroup 的优先级是该组中所有 Pod 在 工作负载感知抢占 事件中的权威优先级， 即使组成该 PodGroup 的各个 Pod 的优先级不同也是如此。

以下 YAML 是使用 high-priority PriorityClass 的 PodGroup 配置示例， 该 PriorityClass 映射到整数值 1000000 的优先级。 优先级准入控制器检查规约并将 PodGroup 的优先级解析为 1000000。

apiVersion: scheduling.k8s.io/v1alpha2
kind: PodGroup
metadata:
  namespace: ns-1
  name: job-1
spec:
  priorityClassName: high-priority

接下来

• 阅读有关工作负载感知抢占算法的信息。
• 了解工作负载 API。

3 - 拓扑感知工作负载调度

拓扑感知调度（Topology-Aware Scheduling，TAS）是 Workload API 的一项特性， 用于优化 Pod 在集群中的调度方式。

TAS 确保同一个 PodGroup 中的所有 Pod 被一起调度在特定的拓扑域中， 例如同一个服务器机架或同一个可用区。这减少了 Pod 之间通信的延迟， 并防止工作负载在集群基础设施中发生碎片化分布。

拓扑感知调度与 gang 调度策略配合使用

当 TAS 应用于使用 gang 调度策略的 PodGroup 时，TAS 会一次性模拟整个 Pod 组的潜在分配。 TAS 保证在真正分配资源之前，至少指定数量的 minCount Pod 可以一起调度到同一个拓扑域中。 如果找不到可行的调度方案，则整个 PodGroup 成为不可调度。

这是推荐用于分布式 AI 和 ML 训练等工作负载的方法， 因为这类场景通常严格要求 Pod 之间具备较近的物理距离，以降低通信延迟。

如果向已经存在部分已调度 Pod 的 PodGroup 中新增 Pod（例如 Pod 被重新创建时）， 调度器将强制所有新传入的 Pod 落在现有 Pod 当前所在的完全相同的拓扑域中。 如果该特定拓扑域没有足够容量来容纳新的 Pod，这些 Pod 将保持 Pending 状态 ——即使这意味着当前已调度的 Pod 数量少于 minCount。

拓扑感知调度与 basic 调度策略配合使用

将 TAS 与 basic 调度策略一起使用时，可能会出现不一致的行为。调度器在进入 PodGroup 调度周期时， 可能只能观测到部分 Pod，因此可行性评估仅针对已观测到的 Pod，而不是整个 PodGroup。为了部分缓解这一限制， 你可以使用调度门控，以便在 PodGroup 中所有 Pod 都进入调度队列之前暂缓调度。

如果无法为整个 PodGroup 找到可行的调度方案，则可能只有部分 Pod 会被调度， 但这些已调度的 Pod 仍然保证满足调度约束。

如果向已经存在部分已调度 Pod 的 PodGroup 中新增 Pod， 调度器的行为将与 gang 策略相同——强制新 Pod 进入相同的拓扑域， 除非容量不足（在这种情况下，新 Pod 将保持 Pending 状态）。

API 配置：调度约束

每个 PodGroup（或 PodGroupTemplate）都可以选择性声明 schedulingConstraints 字段，有关该字段的细节参阅 PodGroup 调度算法。 如果在 PodGroupTemplate 中定义了约束，这些约束会复制到引用该模板的 PodGroup 中。

截至 Kubernetes v1.36，API 支持拓扑约束。

拓扑约束

要为 PodGroup 定义拓扑约束，你需要设置一个 key， 它对应 Kubernetes 节点上的某个标签，用于表示目标拓扑域（例如机架或可用区）。 调度器会严格保证：同一个 PodGroup 中的所有 Pod 只能被调度到具有相同标签值的节点上。

下面是一个配置了拓扑约束的 PodGroup 示例：

apiVersion: scheduling.k8s.io/v1alpha2
kind: PodGroup
metadata:
  name: example-podgroup
spec:
  schedulingPolicy:
    gang:
      minCount: 4
  schedulingConstraints:
    topology:
      - key: topology.example.com/rack

接下来

• 了解 Pod 组策略。
• 了解拓扑感知调度相关插件
• 参阅 Gang 调度算法。