Job
API
对象定义:
1 | apiVersion: batch/v1 |
在这个模板中,我们定义了一个Ubuntu
镜像的容器,他运行计算π
的程序,所以,这是一个计算π
的容器。
创建成功后,查看一下这个Job
对象:
//TODO:
可以看到,在这个Job
对象创建后,它的Pod
模板被自动加上了一个controller-uid=<一个随机字符串>
这样的Label
。从而保证了Job
与它所管理的Pod
之间的匹配关系。
离线作业失败了要怎么办?
Job Controller工作原理
首先,Job Controller
控制的对象直接就是Pod
。
其次,Job Controller
在控制循环中进行的调谐操作,是根据实际Running
状态的Pod
的数目、已经成功退出的Pod
的数目,以及parallelism
、completions
参数的值共同计算出在这个周期里应该创建或者删除的Pod
数目,然后调用Kubernetes API
来执行这个操作。
因此,Job Controller
实际上控制了作业执行的并行度(parallelism
),以及总共需要完成的任务数(completions
)这两个重要参数。而在实际使用时,需要根据作业的特性来决定并行度和任务数的合理取值。
CronJob
CronJob
描述的是定时任务,它的API
对象如下:
1 | apiVersion: batch/v1 |
原来CronJob
是一个Job
对象的控制器。
通过以上例子,创建CronJob
对象后,每一分钟后就会有一个Job
产生:
//TODO:
此时,CronJob
对象会记录下这次Job
执行的时间:
注意:由于定时任务的特殊性,很可能某个Job
还没有执行完,另外一个新Job
就产生了。此时,可以通过spec.concurrenyPolicy
字段来定义具体的处理策略:
- 1,
concurrenyPolicy=Allow
:这是默认情况,它意味着这些Job
可以同时存在; - 2,
concurrenyPolicy=Forbid
:这意味着不会创建新的Pod
,该创建周期被跳过; - 3,
concurrenyPolicy=Replace
:这意味着新产生的Job
会替换旧的、未执行完的Job
。
而如果某一次Job
创建失败,这次创建就会被标记为"miss"
。当在指定的时间窗口内miss
的数目达到100时,CronJob
会停止再创建这个Job
。
这个时间段可以由spec.startingDeadlineSeconds
字段指定。比如,startingDeadlineSeconds=200
,意味着在过去200s里,如果miss
的数目达到了100,那么这个Job
就不会被创建执行了。
总结
Job
是一次性执行的离线任务;CronJob
是定时执行的离线任务,也就是说CronJob
对象在控制Job
对象,这也说明用一个对象控制另一个对象,是 Kubernetes 编排的精髓所在。