Kubernetes v1.33：Job 的 Backoff Limit Per Index 进入 GA 阶段

在 Kubernetes v1.33 中，**逐索引回退限制（Backoff Limit Per Index）**功能已正式发布（GA）。这篇博文介绍了逐索引回退限制功能及其优点。

关于逐索引回退限制

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

为了在 Kubernetes Job 中实现容错，你可以设置 spec.backoffLimit 字段。该字段指定了可容忍的故障总数。

然而，对于每个索引都被视为独立的工作负载，例如易并行工作负载，spec.backoffLimit 字段通常不够灵活。例如，你可能会选择运行多个集成测试套件，将每个套件表示为带索引的 Job中的一个索引。在这种设置下，一个快速失败的索引（测试套件）很可能会耗尽你容忍 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” 规则，将与该失败 Pod 对应的索引标记为失败。
• 重试任何索引的第一次失败，除非该索引因匹配的 FailIndex 规则而失败。
• 如果失败索引的数量超过 5（由 spec.maxFailedIndexes 字段设置），则将整个 Job 标记为失败。

了解更多

• 阅读关于 Pod 故障策略这一密切相关功能的博文：Kubernetes 1.31：Job 的 Pod 故障策略功能正式发布
• 有关使用 Pod 故障策略的实践指南，包括 FailIndex 的使用，请参阅使用 Pod 故障策略处理可重试和不可重试的 Pod 故障。
• 阅读逐索引回退限制和 Pod 故障策略的文档。
• 阅读关于带索引的 Job 的逐索引回退限制的 KEP。

参与其中

这项工作由 Kubernetes 批处理工作组与 SIG Apps 社区密切合作赞助。

如果你有兴趣在该领域开发新功能，我们建议你订阅我们的 Slack 频道并参加定期的社区会议。

• ←上一篇
• 下一篇→