Job与CronJob离线任务

之前我们将讲解的deployment statefulSet 和DeamonSet三种编排都是“在线业务”，这些应该一旦跑起来除非出错就会一直保持运行。

今天讲解的Job和CronJob是离线任务。这些任务跑一次，跑完就直接退出了。

Job

job对象在创建后会被自动打上标签controller-uid= < 一个随机字符串 >，而这个 Job 对象本身，则被自动加上了这个 Label 对 应的 Selector，从而 保证了 Job 与它所管理的 Pod 之间的匹配关系。而 Job Controller 之所以要使用这种携带了 UID 的 Label，就是为了避免不同 Job 对象所 管理的 Pod 发生重合。

如果这个离线作业失败了要怎么办?如果定义了 restartPolicy=Never，那么离线作业失败后 Job

Controller 就会不断地尝试创建一个新 Pod。如果定义的 restartPolicy=OnFailure，那么离线作业失败后，Job Controller 就不会去尝试创建新的 Pod。但是，它会不断地尝试重启 Pod 里的容器。

当一个 Job 的 Pod 运行结束后，它会进入 Completed 状态。但是，如果这个 Pod 因为某种原因一直不肯结束呢?一旦运行超过了 100 s，这个 Job 的所有 Pod 都会被终止。并且，你可以在 Pod 的状态 里看到终止的原因是 reason: DeadlineExceeded。

Job 对象中，负责并行控制的参数有两个:

1. spec.parallelism，它定义的是一个 Job 在任意时间最多可以启动多少个 Pod 同时运 行;

2. spec.completions，它定义的是 Job 至少要完成的 Pod 数目，即 Job 的最小完成数

Job的控制器CronJob

Job Controller直接控制的对象还是pod。Job Controller 在控制循环中进行的调谐(Reconcile)操作，是根据实际在 Running 状态 Pod 的数目、已经成功退出的 Pod 的数目，以及 parallelism、 completions 参数的值共同计算出在这个周期里，应该创建或者删除的 Pod 数目，然后调 用 Kubernetes API 来执行这个操作。

Job Controller 实际上控制了，作业执行的并行度，以及总共需要完成的任务 数这两个重要参数。而在实际使用时，你需要根据作业的特性，来决定并行度(parallelism)和任务数(completions)的合理取值。

CronJob 是一 个专门用来管理 Job 对象的控制器。只不过，它创建和删除 Job 的依据，是 schedule 字段定义的、一个标准的Unix Cron格式的表达式。

schedule: "*/1 * * * *"
这个 Cron 表达式里 */1 中的 * 表示从 0 开始，/ 表示“每”，1 表示偏移量。所以，它的 意思就是:从 0 开始，每 1 个时间单位执行一次。

你可能某个 Job 还没有执行完，另外一个新 Job 就产生了。这时候，你可以通过 spec.concurrencyPolicy 字段来定义具体的处理策略。比 如:

 concurrencyPolicy=Allow，这也是默认情况，这意味着这些 Job 可以同时存在;  concurrencyPolicy=Forbid，这意味着不会创建新的 Pod，该创建周期被跳过;  concurrencyPolicy=Replace，这意味着新产生的 Job 会替换旧的、没有执行完的Job。

而如果某一次 Job 创建失败，这次创建就会被标记为“miss”。当在指定的时间窗口内， miss 的数目达到 100 时，那么 CronJob 会停止再创建这个 Job。

---

总结

今天，分享了离线任务job和job 控制器以及其中一种控制器CronJob