介绍
Kubernetes有两个概念跟job有关:git
- Job: 负责批量处理短暂的一次性任务,仅执行一次,并保证处理的一个或者多个Pod成功结束。
- CronJob: 负责定时任务,在指定的时间周期运行指定的任务。
Job
Job用于批量处理短暂的一次性任务,并保证指定数量的Pod成功结束。
K8S支持如下几种方式:github
-
非并行Job:数据库
- 一般只运行一个Pod,Pod成功结束Job就退出。
-
固定完成次数的并行Job:json
- 并发运行指定数量的Pod,直到指定数量的Pod成功,Job结束。
-
带有工做队列的并行Job:api
- 用户能够指定并行的Pod数量,当任何Pod成功结束后,不会再建立新的Pod
- 一旦有一个Pod成功结束,而且全部的Pods都结束了,该Job就成功结束。
- 一旦有一个Pod成功结束,其余Pods都会准备退出。
Job Spec
完整Job字段能够参考Job。Job有几个主要参数配合用于指定完成次数,并发运行,错误重试等操做:并发
- .spec.completions: 指定job须要成功运行Pods的次数。默认值: 1
- .spec.parallelism: 指定job在任一时刻应该并发运行Pods的数量。默认值: 1
- .spec.activeDeadlineSeconds: 指定job可运行的时间期限,超过期间还未结束,系统将会尝试进行终止。
- .spec.backoffLimit: 指定job失败后进行重试的次数。默认是6次,每次失败后重试会有延迟时间,该时间是指数级增加,最长时间是6min。
已知问题
Issue #54870, .spec.template.spec.restartPolicy设置为”Onfailure”时,会与.spec.backoffLimit冲突,能够暂时将restartPolicy设置为”Never”进行规避。
注1: .spec.activeDeadlineSeconds要比.spec.backoffLimit优先级高,若是时间到了,可是backoffLimit还未到,该Job也会被强制中止。rest
Job模式
Job有几种典型的模式应用于不一样的业务场景:code
-
基于Job模版进行扩展:队列
- 须要先编写一个通用的Job模版,根据不一样的参数生成多个Job json/yml文件用于Job的建立,可使用相同的标签进行Job管理。
-
按每一个工做项目排列的队列:ip
- 须要用户提早准备好一个消息队列服务,好比rabbitMQ,该服务是一个公共组件,每一个工做项目能够往里塞任务消息。
- 用户能够建立并行Job,须要能适用于该消息队列,而后从该消息队列中消费任务,并进行处理直到消息被处理完。
- 该模式下,用户须要根据项目数量填写
spec.completions
, 并行数量.spec.parallelism
能够根据实际状况填写。该模式下就是以全部的任务都成功完成了,job才会成功结束。
-
可变任务数量的队列:
- 须要用户提早准备好一个存储服务来保存工做队列,好比Redis。每一个项目能够往该存储服务填充消息。
- 用户能够启动适用于该工做队列的多个并行Job,进行消息处理。与前一个Rabbit消息队列的差别在于,每一个Job任务是能够知道工做队列已经空了,这时候即可以成功退出。
- 该模式下,
spec.completions
须要置1, 并行数量.spec.parallelism
能够根据实际状况填写。只要其中有一个任务成功完成,该Job就会成功结束。
- 普通的静态任务
CronJob
cronJob是基于时间进行任务的定时管理:
- 在特定的时间点运行任务
- 反复在指定的时间点运行任务:好比定时进行数据库备份,定时发送电子邮件等等。
CronJob Spec
完整的spec字段,能够参考CronJob,介绍几个主要的字段:
- .spec.schedule: 指定任务运行周期,具体格式参考Cron - Wikipedia
- .spec.startingDeadlineSeconds: 指定任务运行的截止时间
- .spec.concurrencyPolicy: 指定任务的并发策略,参数支持Allow、Forbid和Replace。
- .spec.jobTemplate: 指定须要运行的任务,格式同Job。因此其实cronJob是基于Job进行实现。
参考资料