Job
Job 对象离线计算的 Pod 永远都不应该被重启，否则它们会再重新计算一遍，所以我们需要在 Pod 模板中定义 restartPolicy=Never 。Job Controller 重新创建 Pod 的间隔是呈指数增加的，即下一次重新创建 Pod 的动作会分别发生在 10 s、20 s、40 s …后。
Job Controller离线作业失败后有两种处理方式
- 当定义了 restartPolicy=Never，那么离线作业失败后 Job Controller 就会不断地尝试创建一个新 Pod
- 当定义的 restartPolicy=OnFailure，那么离线作业失败后，Job Controller 就不会去尝试创建新的 Pod。但是，它会不断地尝试重启 Pod 里的容器
在 Job 对象中，负责并行控制的参数有两个：
- spec.parallelism，它定义的是一个 Job 在任意时间最多可以启动多少个 Pod 同时运行；
- spec.completions，它定义的是 Job 至少要完成的 Pod 数目，即 Job 的最小完成数
Job Controller 控制的对象，直接就是 Pod。Job Controller 在控制循环中进行的调谐（Reconcile）操作，是根据实际在 Running 状态 Pod 的数目、已经成功退出的 Pod 的数目，以及 parallelism、completions 参数的值共同计算出在这个周期里，应该创建或者删除的 Pod 数目，然后调用 Kubernetes API 来执行这个操作。
Job Controller 实际上控制了，作业执行的并行度，以及总共需要完成的任务数这两个重要参数。而在实际使用时，你需要根据作业的特性，来决定并行度（parallelism）和任务数（completions）的合理取值。
有三种常用的、使用 Job 对象的方法：
- 外部管理器 +Job 模板：把 Job 的 YAML 文件定义为一个“模板”，然后用一个外部工具控制这些“模板”来生成 Job
- 拥有固定任务数目的并行 Job：设置指定数目（spec.completions）个任务成功退出即可，无须关注执行时的并行度
- 指定并行度（parallelism），但不设置固定的 completions 的值：任务数目的总数不固定，需要决定什么时候启动新 Pod，什么时候 Job 才算执行完成
CronJob
CronJob是指定时任务。在YAML文件中，关键词是jobTemplate，这表明CronJob 是一个 Job 对象的控制器（Controller）
CronJob 与 Job 的关系，正如同 Deployment 与 Pod 的关系一样。CronJob 是一个专门用来管理 Job 对象的控制器。只不过，它创建和删除 Job 的依据，是 schedule 字段定义的、一个标准的Unix Cron格式的表达式。
于定时任务的特殊性，很可能某个 Job 还没有执行完，另外一个新 Job 就产生了。这时候，你可以通过 spec.concurrencyPolicy 字段来定义具体的处理策略。比如：
- concurrencyPolicy=Allow，这也是默认情况，这意味着这些 Job 可以同时存在；
- concurrencyPolicy=Forbid，这意味着不会创建新的 Pod，该创建周期被跳过；
- concurrencyPolicy=Replace，这意味着新产生的 Job 会替换旧的、没有执行完的 Job。
如果某一次 Job 创建失败，这次创建就会被标记为“miss”。当在指定的时间窗口内，miss 的数目达到 100 时，那么 CronJob 会停止再创建这个 Job。这个时间窗口，可以由 spec.startingDeadlineSeconds 字段指定
