介紹 Suspended Jobs

Jobs 是 Kubernetes API 的重要組成部分。雖然其他種類的工作負載，例如 Deployments、ReplicaSets、StatefulSets 和 DaemonSets 解決了需要 Pod 永遠運行的使用案例，但當 Pod 需要運行至完成時，Jobs 非常有用。Jobs 常見於並行批次處理，可用於各種應用程式，範圍從視訊渲染和資料庫維護到發送大量電子郵件和科學計算。

雖然並行量和 Job 完成的條件是可配置的，但 Kubernetes API 缺少暫停和恢復 Job 的能力。當叢集資源有限且需要執行更高優先順序的 Job 來取代另一個 Job 時，通常會需要此功能。刪除較低優先順序的 Job 是一種糟糕的應變措施，因為 Pod 完成歷史記錄和與 Job 相關聯的其他指標將會遺失。

透過最近的 Kubernetes 1.21 版本，您將能夠透過更新 Job 的 spec 來暫停 Job。此功能目前處於 alpha 階段，需要您在 API 伺服器 和 控制器管理器 上啟用 SuspendJob 功能閘道 才能使用它。

API 變更

我們在 Jobs 的 .spec 中引入了一個新的布林值欄位 suspend。假設我建立以下 Job

apiVersion: batch/v1
kind: Job
metadata:
  name: my-job
spec:
  suspend: true
  parallelism: 2
  completions: 10
  template:
    spec:
      containers:
      - name: my-container
        image: busybox
        command: ["sleep", "5"]
      restartPolicy: Never

Job 預設不會暫停，因此我明確地將上述 Job 清單的 .spec 中的 suspend 欄位設定為 true。在上述範例中，Job 控制器將不會建立 Pod，直到我準備好啟動 Job 為止，我可以透過將 suspend 更新為 false 來啟動 Job。

作為另一個範例，請考慮一個在省略 suspend 欄位的情況下建立的 Job。Job 控制器將樂於建立 Pod 以努力完成 Job。但是，在 Job 完成之前，如果我透過 Job 更新明確地將欄位設定為 true，則 Job 控制器將終止所有正在運行的活動 Pod，並無限期地等待標誌翻轉回 false。通常，Pod 終止是透過向 Pod 中的所有容器程序發送 SIGTERM 信號來完成的；將會遵守 Pod 清單中定義的 寬限期。以這種方式終止的 Pod 將不會被 Job 控制器計為失敗。

務必了解，來自過去的成功和失敗的 Pod 將在您暫停 Job 後繼續存在。也就是說，一旦您恢復 Job，它們將計入 Job 完成。您可以透過查看暫停前後的 Job 狀態來驗證這一點。

閱讀文件以全面了解此新功能。

這在哪裡有用？

假設我是大型叢集的運營商。我有很多使用者向叢集提交 Job，但並非所有 Job 都是平等的 — 有些 Job 比其他 Job 更重要。叢集資源也不是無限的，因此所有使用者都必須共享資源。如果所有 Job 都在暫停狀態下建立並放置在待處理佇列中，我可以透過依正確順序恢復 Job 來實現基於優先順序的 Job 排程。

作為另一個激勵人心的使用案例，請考慮雲端供應商在夜間的運算資源比早晨便宜。如果我有一個需要多天才能完成的長時間運行的 Job，能夠在早上暫停 Job，然後每天晚上恢復它，可以降低成本。

由於此欄位是 Job spec 的一部分，CronJobs 也會自動免費獲得此功能。

參考資料和後續步驟

如果您有興趣深入了解此功能背後的原理以及我們做出的決策，請考慮閱讀增強提案。有關暫停和恢復 Job 的更多詳細資訊，請參閱 Job 的文件。

如前所述，此功能目前處於 alpha 階段，只有在您透過 SuspendJob 功能閘道 明確選擇加入時才可用。如果您對此功能感興趣，請考慮在您的叢集中測試暫停的 Job 並提供意見回饋。您可以在 GitHub 上討論此增強功能。SIG Apps 社群也 定期舉行會議，並且可以透過 Slack 或郵件列表 聯繫。除非 API 有任何意外變更，否則我們打算在 Kubernetes 1.22 中將此功能升級到 beta 版，以便預設情況下可以使用該功能。

• ←上一篇
下一篇→