介绍
Kubernetes有两个概念跟job有关:
Job
Job用于批量处理短暂的一次性任务,并保证指定数量的Pod成功结束。
K8S支持以下几种方式:
-
非并行Job:
- 通常只运行一个Pod,Pod成功结束Job就退出。
-
固定完成次数的并行Job:
- 并发运行指定数量的Pod,直到指定数量的Pod成功,Job结束。
-
带有工作队列的并行Job:
- 用户可以指定并行的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也会被强制停止。
Job模式
Job有几种典型的模式应用于不同的业务场景:
-
基于Job模版进行扩展:
- 需要先编写一个通用的Job模版,根据不同的参数生成多个Job json/yml文件用于Job的创建,可以使用相同的标签进行Job管理。
-
按每个工作项目排列的队列:
- 需要用户提前准备好一个消息队列服务,比如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进行实现。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。