拓扑感知工作负载调度

拓扑感知调度（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/v1beta1
kind: PodGroup
metadata:
  name: example-podgroup
spec:
  schedulingPolicy:
    gang:
      minCount: 4
  schedulingConstraints:
    topology:
      - key: topology.example.com/rack

多级拓扑感知调度

复杂工作负载可能需要将其 Pod 共置于集群基础架构的不同层级。 例如，整个工作负载可能需要运行在单个可用区内，而该工作负载的不同部分可能需要严格共置于特定服务器机架上。

此类多层级共置需求可以通过 CompositePodGroup API 表达，并在组层级结构的不同层次上指定拓扑约束。

使用 CompositePodGroup API 需要启用 CompositePodGroup 特性门控和 scheduling.k8s.io/v1alpha3 {{< glossary_tooltip text="API 组" term_id="api-group" >}}。

多层级拓扑约束解析

CompositePodGroup 层级结构中的每个组都可以指定一个拓扑约束，确保该组的所有后代 Pod 都会在与该组约束相匹配的同一拓扑域中进行调度。

在分层调度过程中， 调度器以自顶向下的方式解析这些约束。具体而言，在对子组进行调度时所考虑的拓扑域， 会被限定在父组所假定的位置对应的拓扑域之内。

Kubernetes 并不对拓扑标签的物理层级结构施加任何严格的要求 —— 拓扑键是任意的节点标签。 不过，你从父组到子组指定拓扑约束的顺序，决定了调度器对拓扑域进行细分的顺序。

示例

下面的示例配置了一个 Workload，其中父级 CompositePodGroupTemplate 将整个工作负载约束到单个可用区（topology.example.com/zone），而两个子级 PodGroupTemplate 条目（workers 和 driver）将它们各自的 Pod 约束到该可用区内的服务器机架（topology.example.com/rack）：

apiVersion: scheduling.k8s.io/v1alpha3
kind: Workload
metadata:
  name: example-workload
spec:
  compositePodGroupTemplates:
  - name: root
    schedulingPolicy:
      gang:
        minGroupCount: 2
    schedulingConstraints:
      topology:
      - key: topology.example.com/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

在创建 Workload 对象之后，对应的组对象将被创建，如下：

• 根级 CompositePodGroup，引用 root 模板。
• 两个子级 PodGroup 对象（workers 和 driver），各自将根级 CompositePodGroup 引用为其父组。

apiVersion: scheduling.k8s.io/v1alpha3
kind: CompositePodGroup
metadata:
  name: workload-root
spec:
  workloadRef:
    workloadName: example-workload
    templateName: root
  schedulingPolicy:
    gang:
      minGroupCount: 2
  schedulingConstraints:
    topology:
    - key: topology.example.com/zone
---
apiVersion: scheduling.k8s.io/v1beta1
kind: PodGroup
metadata:
  name: workload-workers
spec:
  parentCompositePodGroupName: workload-root
  workloadRef:
    workloadName: example-workload
    templateName: workers
  schedulingPolicy:
    gang:
      minCount: 8
  schedulingConstraints:
    topology:
    - key: topology.example.com/rack
---
apiVersion: scheduling.k8s.io/v1beta1
kind: PodGroup
metadata:
  name: workload-driver
spec:
  parentCompositePodGroupName: workload-root
  workloadRef:
    workloadName: example-workload
    templateName: driver
  schedulingPolicy:
    gang:
      minCount: 1
  schedulingConstraints:
    topology:
    - key: topology.example.com/rack

在调度过程中，调度器首先为 workload-root 选择一个可用区，然后按机架细分该可用区内的节点， 以找到 workload-workers 和 workload-driver 在所选可用区内的可行机架放置位置。

例如，考虑一个包含五个节点的集群，其标签如下：

在处理 workload-root 时，调度器会基于 topology.example.com/zone 拓扑键，在所有集群节点上评估候选放置位置：

在处理 workload-root 时，调度器会基于 topology.example.com/zone 拓扑键，在所有集群节点上评估候选放置位置：

为同级 workload-driver PodGroup 生成的候选放置位置与为 workload-workers 生成的相同，因为这两个组都指定了相同的拓扑键（topology.example.com/rack）。

接下来

• 了解 Pod 组策略。
• 了解拓扑感知调度相关插件
• 参阅 Gang 调度算法。
• 了解调度构建块和 workloadbuilder 库，包括调度约束构建块。