Kubernetes v1.37 Workload-Aware Scheduling 核心进展

技术要点

Kubernetes v1.37 版本聚焦于 Workload-Aware Scheduling (WAS) 能力的深化与扩展，主要技术变化如下：

1. API 版本升级与毕业：核心的 Workload 和 PodGroup API 以及 gang scheduling 功能正式 graduating 至 Beta 阶段。API 版本从 v1alpha2 升级为 v1beta1。原有的 v1alpha2 版本被完全替换为 v1alpha3，其中 disruptionMode 相关的 API 结构有 breaking changes。
2. CompositePodGroup API 引入：新增 CompositePodGroup API，用于表达多级别拓扑约束。它允许将工作负载组织成由 CompositePodGroup 和 PodGroup 对象构成的树形层级结构。每个 CompositePodGroup 携带适用于其子组（其他 CompositePodGroup 和/或 PodGroup）的策略和约束。调度器将此层级视为一个单一调度单元。
3. Workload API 扩展：Workload API 新增 spec.compositePodGroupTemplates 字段，用于定义层级模板。控制器可根据这些模板创建对应的运行时 CompositePodGroup 和 PodGroup 对象。
4. PodGroup 调度队列优化：在调度队列中，PodGroup 成为一等公民。之前，属于 PodGroup 的所有 Pod 被单独排队；现在，仅顶层 PodGroup 对象被排队，确保所有 Pod 共享相同的排队行为。
5. minCount 可变性：PodGroup 的 minCount 字段（定义成功调度所需的最小 Pod 数量）从不可变变为可变。这为弹性工作负载提供了灵活性，控制器可以动态调整 gang 的最小规模。
6. Workload-Aware Preemption (WAP) 改进：
   • WorkloadAwarePreemption 特性门控已合并到 GenericWorkload 特性门控中。
   • 性能优化：在 v1.37 中，调度器模拟移除所有潜在受害者后只运行一次调度算法，然后尝试恢复尽可能多的受害者。v1.36 中则为每个受害者恢复运行调度算法。
   • PodGroup 作为受害者：默认抢占现在尊重 PodGroup 的 disruptionMode 字段，解决了 v1.36 中单 Pod 抢占可能破坏 disruptionMode: {all: {}} 设置的 PodGroup 的问题。
   • disruptionMode 字段重命名：为保持一致性，PodGroup 中的 disruptionMode 字段模式从 PodGroup 改为 all，从 Pod 改为 single。
   • preemptionPolicy 支持：当 PodGroupPreemptionPolicy 特性门控启用时，PodGroup 新增 preemptionPolicy 字段，作为其是否可执行抢占的权威字段。
7. 控制器集成简化：引入新的控制器集成 API 和 workloadbuilder Go 库，为外部控制器集成 WAS 能力提供标准化构建块。原生 Job 控制器集成已升级，以全面使用扩展的 WAS API。

原理与背景

Workload-Aware Scheduling 的设计动机源于 AI/ML 和复杂批处理工作负载对 Kubernetes 调度提出的新挑战。传统调度器以单个 Pod 为单位进行调度，难以满足 gang scheduling（全有或全无）、层级依赖、弹性伸缩等复杂工作负载的需求。

• Workload 与 PodGroup API：Workload 作为工作负载的静态模板定义，PodGroup 作为运行时组状态，二者分离的设计提供了灵活性和清晰性。gang scheduling 确保一组 Pod 要么全部调度成功，要么全部失败，避免了部分 Pod 因资源不足而长时间等待的问题。
• CompositePodGroup 的必要性：现代高性能分布式工作负载（如由 JobSet 或 LeaderWorkerSet 管理的工作负载）往往具有复杂的层级结构。例如，一个作业可能包含一个驱动 Pod 和多个工作 Pod，它们之间又有不同的调度要求。平面的 PodGroup 模型无法表达这种多级别约束。CompositePodGroup 通过树形层级结构，允许定义父组与子组之间的调度策略和依赖关系，使调度器能够理解并满足更复杂的工作负载拓扑。
• PodGroup 队列化与 minCount 可变性：将 PodGroup 作为调度队列中的独立单元，确保了组内 Pod 的调度行为一致性，为未来更高级的队列策略（如优先级、公平性）奠定了基础。minCount 的可变性则支持了工作负载的动态伸缩，例如在负载降低时减少所需的最小 Pod 数，而无需中断已调度的 Pod。
• WAP 的演进：WAP 旨在使抢占过程更“工作负载感知”，减少对工作负载整体稳定性的冲击。性能优化减少了调度模拟的开销。让 PodGroup 成为抢占对象并尊重其 disruptionMode，确保了抢占决策不会破坏工作负载的完整性约束。preemptionPolicy 的引入则提供了更细粒度的控制，允许明确禁止某些 PodGroup 参与抢占。

落地建议

对于计划采用或升级至 Kubernetes v1.37 的集群管理员和开发者，以下建议可供参考：

1. 评估与升级 API：如果已在测试或使用 Workload/PodGroup 的 alpha 版本，需准备迁移到 v1beta1 或 v1alpha3。注意 disruptionMode 字段的 breaking changes 和重命名，更新相关配置和代码。
2. 利用新 API 构建复杂工作负载：对于具有层级结构的工作负载（如主从架构、多阶段作业），考虑使用 CompositePodGroup API 来定义调度约束。通过 Workload 对象的 compositePodGroupTemplates 字段定义模板，并由控制器（如 JobSet、LWS 或自定义控制器）创建运行时组对象。
3. 启用与配置 WAS 特性：根据工作负载需求，启用相应的特性门控，如 GenericWorkload（包含 WAP）和 PodGroupPreemptionPolicy。理解 disruptionMode（all/single）和 preemptionPolicy 的含义，并根据工作负载的容忍度进行配置。
4. 利用集成工具简化开发：对于需要集成 WAS 能力的外部控制器，推荐使用新的控制器集成 API 和 workloadbuilder Go 库，以减少自定义代码量，提高集成效率和一致性。
5. 注意版本兼容性：在升级集群前，确保所有相关控制器和工具支持 v1.37 的 API 变更。测试 gang scheduling、preemption 和层级调度行为是否符合预期。
6. 监控与调优：部署后，监控调度器行为和工作负载调度成功率。利用 minCount 可变性优化弹性工作负载的资源使用。根据实际性能表现，调整调度策略和参数。