Kubernetes v1.33：Job 逐索引的回退限制进阶至 GA

在 Kubernetes v1.33 中，逐索引的回退限制特性进阶至 GA（正式发布）。本文介绍此特性及其优势。

关于逐索引的回退限制

当你在 Kubernetes 上运行工作负载时，必须考虑 Pod 失效可能影响工作负载完成的场景。理想情况下，你的工作负载应该能够容忍短暂的失效并继续运行。

为了在 Kubernetes Job 中容忍失效，你可以设置 spec.backoffLimit 字段。此字段指定容忍的失效总数。

但是，对于每个索引都被视为独立单元的工作负载，比如过易并行的工作负载，spec.backoffLimit 字段通常不够灵活。例如，你可以选择运行多个继承测试套件，将每个套件作为带索引的 Job内的某个索引。在这种情况下，快速失效的索引（测试套件）很可能消耗你全部的 Pod 失效容忍预算，你可能无法运行其他索引的 Pod。

为了解决这一限制，Kubernetes 引入了逐索引的回退限制，允许你控制逐索引的重试次数。

逐索引回退限制的工作原理

要在带索引的 Job 中使用逐索引的回退限制，可以通过 spec.backoffLimitPerIndex 字段指定每个索引允许的 Pod 失效次数。当你设置此字段后，Job 默认将执行所有索引。

另外，你可以通过以下方式微调错误处理：

• 通过设置 spec.maxFailedIndexes 字段，指定失效索引总数的上限。超过此限制时，整个 Job 会被终止。
• 通过 Pod 失效策略机制中的FailIndex 动作定义短路来检测失效的索引。

当超过容忍的失效次数时，Job 会将该索引标记为失效，并在 Job 的 status.failedIndexes 字段中列出该索引。

示例

下面的 Job 规约片段展示了如何将逐索引的回退限制与 Pod 失效策略特性结合使用：

completions: 10
parallelism: 10
completionMode: Indexed
backoffLimitPerIndex: 1
maxFailedIndexes: 5
podFailurePolicy:
  rules:
  - action: Ignore
    onPodConditions:
    - type: DisruptionTarget
  - action: FailIndex
    onExitCodes:
      operator: In
      values: [ 42 ]

在此例中，Job 对 Pod 失效的处理逻辑如下：

• 忽略具有内置干扰状况 （称为 DisruptionTarget）的失效 Pod。这些 Pod 不计入 Job 的回退限制。
• 如果失效的 Pod 中任何容器的退出码是 42，则基于匹配的 FailIndex 规则，将对应的索引标记为失效。

• 除非索引因匹配的 FailIndex 规则失效，否则会重试该索引的首次失效。
• 如果失效索引数量超过 5 个（由 spec.maxFailedIndexes 设置），则整个 Job 失效。

进一步了解

• 阅读与 Pod 失效策略密切相关的博客文章：Kubernetes 1.31：Job 的 Pod 失效策略进阶至 GA
• 查看包含 FailIndex 用法在内的 Pod 失效策略实操指南：使用 Pod 失效策略处理可重试和不可重试的 Pod 失效
• 阅读逐索引的回退限制和Pod 失效策略等文档
• 查阅 KEP：带索引的 Job 的逐索引回退限制

参与此工作

这项工作由 Kubernetes Batch Working Group（批处理工作组）负责，且与SIG Apps 社区密切协作。

如果你有兴趣参与此领域的新特性开发，建议订阅我们的Slack 频道，并参加定期社区会议。

• ←上一页
• 下一页→