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 频道，并参加定期社区会议。

• ←上一页
• 下一页→