Job（作業）是 Kubernetes API 的重要組成部分。雖然其他類型的工作負載（如 Deployment、ReplicaSet、StatefulSet 和 DaemonSet）解決了需要 Pod 永遠運行的用例，但 Job 在 Pod 需要運行到完成時非常有用。Job 通常用于并行批處理，可以用于各種應用程序，從視頻渲染和數據庫維護到發送批量電子郵件和科學計算。

雖然并行度和 Job 完成的條件是可配置的，但 Kubernetes API 缺乏暫停（suspend）和恢復（resume）Job 的能力。當集群資源有限，需要在另一個 Job 的位置上執行一個更高優先級的 Job 時，通常需要這樣做。刪除較低優先級的 Job 是一個糟糕的解決方案，因為 Pod 完成歷史和其他與 Job 相關的指標將會丟失。

在最近的 Kubernetes 1.21 版本中，你可以通過更新其規范來暫停 Job。該特性目前處于 alpha 階段，需要你在 API 服務器和控制器管理器上啟用 suspend Job 特性門才能使用它。

API 的變化

我們在作 Job 的.spec 中引入了一個新的布爾字段 suspend。假設我創建了以下作業：

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 來完成。

作為另一個示例，考慮一個省略了 suspend 字段創建的 Job。Job 控制器將愉快地創建 Pod 以完成 Job。但是，在 Job 完成之前，如果我通過 Job 更新顯式地將該字段設置為 true，Job 控制器將終止所有正在運行的活動 Pod，并無限期地等待該標志被設回 false。通常，Pod 終止是通過向 Pod 中的所有容器進程發送 SIGTERM 信號來完成的；Pod 規范中定義的優雅終止期^[1]將得到遵守。以這種方式終止的 Pod 不會被 Job 控制器視為失敗。

重要的是要理解，在你暫停 Job 之后，過去的成功和失敗的 Pod 將繼續存在。也就是說，一旦你重新開始 Job，他們就會被算作 Job 完成的一部分。你可以通過查看 Job 在暫停之前和之后的狀態來驗證這一點。

這在哪里有用？

假設我是一個大集群的操作員。我有很多用戶向集群提交 Job，但并不是所有的 Job 都是平等的——有些 Job 比其他的更重要。集群資源也不是無限的，因此所有用戶都必須共享資源。如果所有 Job 都是在暫停狀態創建的，并放置在一個暫停隊列中，我就可以通過按照正確的順序恢復 Job 來實現基于優先級的 Job 調度。

作為另一個動機性的用例，考慮一個云提供商，它的計算資源在晚上比在早上更便宜。如果我有一個長時間運行的 Job，需要好幾天才能完成，可以在早上暫停 Job，然后在晚上恢復，這樣可以降低成本。

由于該字段是 Job 規范的一部分，因此CronJobs也自動獲得該特性。

引用和下一步

如果你有興趣深入了解這個特性背后的基本原理和我們所做的決定，請考慮閱讀增強建議^[4]。在 Job 的文檔中有關于暫停和恢復 Job 的更多細節。

如前所述，該特性目前處于 alpha 階段，只有通過 SuspendJob 特性門明確選擇加入時才可用。如果這是你感興趣的特性，請考慮在集群中測試暫停作業特性并提供反饋。你可以在GitHub^[5]上討論這個增強。SIG Apps 社區也定期開會^[6]并且可以通過Slack 或郵件列表參與。除非 API 有任何意外的變化，我們打算在 Kubernetes 1.22 中將該特性升級到測試版，這樣該特性在默認情況下就可以使用了。