Kubernetes v1.37 工作负载感知调度适合哪些批任务

Kubernetes v1.37 的工作负载感知调度（Workload-Aware Scheduling，WAS）值得关注，但它不是“所有 Job 都换成 gang scheduling”。最适合它的是一组 Pod 必须成组获得资源、共享设备或满足同一拓扑约束的批任务；普通的独立数据处理 Job 继续使用默认的 Pod-by-Pod 调度通常更简单。

官方地址：https://kubernetes.io/

先看任务是不是“缺一组就没法跑”

判断标准不是 Job 的名字，而是 Pod 之间有没有硬依赖。分布式训练常见的 driver、worker 需要同时拿到足够资源；MPI 或其他集体通信任务如果只启动一部分进程，已经运行的 Pod 也无法产生有效结果。这类任务适合用 gang scheduling 表达“至少一起安排多少个成员”。

相反，图片转码、日志切片、独立 ETL 分片这类任务通常彼此独立。只要一个 Pod 能单独完成一份输入，就没有必要为了全组等待而牺牲调度弹性。此时采用默认的 basic 策略，反而能让空闲节点更快接收工作。

v1.37 的能力分别解决什么批任务问题

v1.37 把 Workload 和 PodGroup API、gang scheduling 以及 Workload-Aware Preemption 推进到 Beta。PodGroup 作为调度队列中的整体对象，有助于让成员共享一致的排队语义；minCount 可以调整，也给弹性批任务留下了逐步扩缩的空间。

对标准 Job，v1.37 增加了显式的 .spec.scheduling。其中 basic 保持原来的逐 Pod 调度，gang 才会让 Job 控制器生成并关联 Workload 与 PodGroup。这样做的好处是策略写在任务声明中，不必再根据 Job 的形状猜测调度意图。

启用前要分清 Beta、Alpha 和默认行为

最容易踩坑的是看到“进入 Beta”就以为安装 v1.37 后自动生效。官方说明中，GenericWorkload 仍需要在 kube-apiserver、kube-controller-manager 和 kube-scheduler 上手动开启；Workload/PodGroup 清单也要迁移到 scheduling.k8s.io/v1beta1。DRA 工作负载资源声明则需要在 apiserver、controller-manager、scheduler 和 kubelet 保持一致。

CompositePodGroup、多层拓扑感知调度、Job 控制器集成以及 PodGroup 的抢占策略仍属于 Alpha 侧能力，启用它们还涉及不同的 feature gate 和 API 版本。尤其是层级拓扑约束，解决的是“整组在一个 zone、子组再在不同 rack 内共置”的复杂场景，不应为了普通批处理增加这层复杂度。

用一轮小规模试验决定是否采用

先选一个可回放的分布式批任务，把并行度、每个 Pod 的资源请求、优先级和拓扑标签固定下来。试验时观察四件事：资源不足时是否整组等待；满足 minCount 后是否能同时推进；抢占发生时是否符合 single 或 all 的预期；禁用 DRA gate 时是否意外创建了不该出现的 ResourceClaim。

如果任务只是“很多份独立输入”，保留 basic；如果缺少任意成员就没有产出，再考虑 gang；如果还要求设备共享或多层共置，才逐项引入 DRA、拓扑和 CompositePodGroup。每增加一项能力，都应单独记录 gate、API 版本、回滚方式和待调度任务的告警条件。

常见问题

普通 Kubernetes Job 是否必须使用 gang scheduling？

不需要。省略 .spec.scheduling 或选择 basic 时，行为仍是标准的逐 Pod 调度。

gang 的 minCount 应该怎么定？

先按任务能产生有效结果所需的最小成员数设定，不要盲目等于最大并行度；v1.37 支持在运行中调整它，但仍要验证弹性变化对应用的影响。

CompositePodGroup 适合直接上生产吗？

它面向层级工作负载和多层拓扑约束，目前是 Alpha。除非任务确实需要 zone 与 rack 等多层共置，否则先使用更简单的 Job 或扁平 PodGroup。

WAS 和 Kueue 是互相替代吗？

不是。WAS 解决工作负载级的成组调度、拓扑和抢占语义，Kueue 仍可承担队列与配额管理；两者的互操作应以具体版本和控制器支持情况为准。