Kubernetes v1.36 [alpha](默认禁用)拓扑感知调度(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。
截至 v1.36,TAS 不会触发工作负载或 Pod 抢占。如果在不触发抢占的情况下无法找到可行的调度方案, 则 PodGroup 成为不可调度。
basic 调度策略配合使用将 TAS 与 basic 调度策略一起使用时,可能会出现不一致的行为。调度器在进入 PodGroup 调度周期时,
可能只能观测到部分 Pod,因此可行性评估仅针对已观测到的 Pod,而不是整个 PodGroup。为了部分缓解这一限制,
你可以使用调度门控,以便在 PodGroup 中所有 Pod 都进入调度队列之前暂缓调度。
如果无法为整个 PodGroup 找到可行的调度方案,则可能只有部分 Pod 会被调度, 但这些已调度的 Pod 仍然保证满足调度约束。
如果向已经存在部分已调度 Pod 的 PodGroup 中新增 Pod,
调度器的行为将与 gang 策略相同——强制新 Pod 进入相同的拓扑域,
除非容量不足(在这种情况下,新 Pod 将保持 Pending 状态)。
每个 PodGroup(或 PodGroupTemplate)都可以选择性声明 schedulingConstraints 字段,有关该字段的细节参阅
PodGroup 调度算法。
如果在 PodGroupTemplate 中定义了约束,这些约束会复制到引用该模板的 PodGroup 中。
截至 Kubernetes v1.36,API 支持拓扑约束。
截至 Kubernetes v1.36,你只可以在每个 PodGroup 中指定一个拓扑约束。
要为 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