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 頻道並參加定期的社群會議。

• ←上一篇
• 下一篇→