Kubernetes v1.37 Job successPolicy 如何设计提前完成条件

Kubernetes v1.37 中，Job 想要“提前完成”，关键不是把 completions 改小，而是使用 Indexed Job 的 successPolicy 明确哪些索引成功、至少成功多少个，以及多条规则谁优先。策略命中后，Job 控制器会终止剩余 Pod；如果同时触发失败终止策略，不能把 successPolicy 当成覆盖规则。

一、先把“完成”定义成索引集合

默认 Job 的完成语义比较单一：成功 Pod 数达到 spec.completions。这适合“每个任务都必须完成”的批处理，却不适合仿真只需若干样本、leader-worker 只看 leader，或候选任务达到最小成功数就可以结束的场景。

successPolicy 的前提是 Indexed Job。completionMode: Indexed 让每个 Pod 对应一个稳定的 completion index，控制器才能把“索引 2 成功”与“任意一个 Pod 成功”区分开。索引表达式只能覆盖 0 到 completions-1，不能写重复或越界的编号。

这也是设计时最容易混淆的一点：parallelism 决定同时运行多少 Pod，completions 决定索引空间有多大，成功策略决定哪些已完成索引足以宣布整体成功，三者不是同一个开关。

二、用 succeededIndexes 和 succeededCount 表达门槛

最小写法有两种。只写 succeededIndexes: "0-2"，表示 0、1、2 三个索引必须全部成功；只写 succeededCount: 3，表示成功索引总数达到 3 即可。将两者放在同一条规则里，则计数只在指定索引子集内计算。

例如下面的清单把 0、1、2 作为优先候选：其中任意两个成功即可提前结束；如果这组候选一直达不到门槛，第二条规则再允许 4、5、6、7 中至少三个成功。这个例子只是策略结构示意，容器镜像和命令应替换成自己的任务。

apiVersion: batch/v1
kind: Job
metadata:
  name: indexed-simulation
spec:
  parallelism: 4 # 控制同时运行的 Pod 数，不改变索引总数
  completions: 8 # 索引范围为 0 到 7
  completionMode: Indexed # successPolicy 依赖稳定的 completion index
  successPolicy:
    rules:
      - succeededIndexes: "0-2"
        succeededCount: 2 # 候选索引中成功两个即可满足第一条规则
      - succeededIndexes: "4-7"
        succeededCount: 3 # 第一条未满足时，备用候选至少成功三个
  template:
    spec:
      restartPolicy: Never # 让每个索引的结果由 Job 控制器记录
      containers:
        - name: worker
          image: example/simulation:1.0 # 示例镜像，部署时替换为可信镜像
          command: ["/bin/sh", "-c"]
          args:
            - echo "index=$JOB_COMPLETION_INDEX" # 示例只展示如何读取当前索引

这里的判断范围是“已成功的索引集合”，不是成功 Pod 的总数。比如规则是 succeededIndexes: "1-4"、succeededCount: 3，而已完成索引是 1、3、5，那么只有 1 和 3 落在子集内，计数仍为 2，规则不会命中。

三、把多条规则排成有意图的顺序

规则数组不是并列备注，而是有顺序的替代条件。控制器按顺序评估，某条规则满足后就忽略剩余规则。因此第一条应代表最可信、最省资源或最符合业务协议的成功路径，后面的规则才放宽候选集或成功数量。

一个常见安排是把 leader 索引单独放在第一条，把“多个 worker 达到门槛”放在第二条。但只有当 leader 成功确实足以代表整体结果时才这样做；如果 leader 只是调度角色，第一条就不该拥有更高优先级。对于仿真或抽样任务，更稳妥的做法是先限定可信索引集合，再设置最小成功数，避免任意 Pod 的偶然成功结束整个 Job。

四、同时检查失败策略与收尾状态

成功策略命中后，Job 会记录成功条件已满足，并发起剩余 Pod 的终止；最终的终态仍是 Complete。这意味着任务程序要能响应终止信号，外部系统也不能把“success criteria met”误认为所有索引都已跑完。

还要把 backoffLimit、activeDeadlineSeconds、podFailurePolicy 等终止条件放进同一张检查表。官方语义明确指出，当 successPolicy 与失败或终止策略同时满足时，控制器遵循终止策略，successPolicy 不会覆盖失败结论。

上线前可以按四项复查：是否使用 Indexed 模式；所有索引表达式是否在合法范围；第一条规则是否真的是首选成功契约；任务是否能接受提前终止和部分索引未完成。只要其中一项答不上来，先不要把成功数量调低。

相关问题

successPolicy 能用于普通非 Indexed Job 吗？

不能。API 约束要求它与 Indexed completion mode 配合使用；普通 Job 没有稳定索引，无法解释 succeededIndexes。

succeededCount 是统计所有成功 Pod 吗？

单独使用时统计成功索引数量；与 succeededIndexes 同时使用时，只统计指定索引子集中的成功索引。

命中 successPolicy 后还会继续创建 Pod 吗？

控制器会停止继续扩充任务并终止滞留 Pod，但终止是控制器收尾过程，不代表每个索引都已经完成。