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 中将该特性升级到测试版，这样该特性在默认情况下就可以使用了。