k8s 关于Job与Cronjob
在Kubernetes 中通过创建工作负载资源 Job 可完成大型计算以及一些批处理任务。比如 Job 转码文件、获取部分文件和目录,机器学习中的训练任务等。这篇小作文我们一起来了解 k8s 中关于 job、cronjob 的内容。
Job创建
我们可以通过API版本 batch/v1
创建出一个简单的k8s Job
#new-job.yml apiVersion: batch/v1 kind: Job metadata: name: command-job spec: template: spec: containers: - name: command-job image: busybox command: ["/bin/sh","-c","sleep 5;echo 'job one'"] restartPolicy: Never复制代码
Job对象 将会启动一个pod用于完成我们的工作--睡眠5s,接着输出 job one
应用job定义,查看job工作工作状态:
$ kubectl apply -f new-job.yml job.batch/command-job created复制代码
任务完成后,pod状态被置为Completed:
通过logs查看我们的任务执行结果:
Job重启与失败认定
在上面我们的例子中,job pod顺利的完成了我们的任务。当pod在执行作业时,容器可能会由于一些原因启动失败,比如进程以非0代码退出或超出内存限制等。在pod模板中可以通过restartPolicy
控制job pod的重启策略。
重启策略(restartPolicy):
Never:pod启动失败时不会重启,而是通过
job-controller
重新创建pod供节点调度。OnFailure:pod将会在节点重启执行任务。
失败回退策略(backoffLimit):
当Job pod 经过多次重启无果,显然我们应该认定这个Job是一个失败任务,默认失败认定重启次数为6,我们可以通过在spec中添加backoffLimit
来改变这一认定。
我们调整new-job.yml如下:
#new-job.yml apiVersion: batch/v1 kind: Job metadata: name: command-job-two spec: template: spec: containers: - name: command-job-two image: busybox command: ["/bin/sh","-c","sleep 5;echo 'job two';exit 1"] restartPolicy: Never backoffLimit: 2复制代码
我们通过describe
查看创建的Job
job-controller
经过2次重建pod达到阈值,job-controller
认定本次Job为失败工作流。
在重启策略为Never
时,认定失败的Job会将pod遗留在节点上。
Job 期限与清理
除了Job执行结束与重启失败认定的Job 终止外还可以通过配置活跃期限(activeDeadlineSeconds)来自动停止Job任务。
我们可以为 Job 的 .spec.activeDeadlineSeconds
设置一个秒数值。 该值适用于 Job 的整个生命期,无论 Job 创建了多少个 Pod。 一旦 Job 运行时间达到 activeDeadlineSeconds
秒,其所有运行中的 Pod 都会被终止,并且 Job 的状态更新为 type: Failed
及 reason: DeadlineExceeded
。
注意 Job 的 .spec.activeDeadlineSeconds
优先级高于其 .spec.backoffLimit
设置。 因此,如果一个 Job 正在重试一个或多个失效的 Pod,该 Job 一旦到达 activeDeadlineSeconds
所设的时限即不再部署额外的 Pod,即使其重试次数还未 达到 backoffLimit
所设的限制。
调整new-job.yml如下:
#new-job.yml apiVersion: batch/v1 kind: Job metadata: name: command-job-three spec: template: spec: containers: - name: command-job-three image: busybox command: ["/bin/sh","-c","sleep 50;echo 'job three'"] restartPolicy: Never backoffLimit: 2 activeDeadlineSeconds: 10复制代码
虽然是50s的任务,但是由于activeDeadlineSeconds
的限制,Job运行10s后被终止
清理job和终止相似,我们可以通过添加spec.ttlSecondsAfterFinished
使Job在任务完成后一段时间内被清理,读者感兴趣可动手尝试一下。
Job 任务类型
非并行 Job
通常只启动一个 Pod,除非该 Pod 失败,Pod中应用成功运行完成即视为Job任务为完成状态,我们上面讨论的任务即属于此类。
并行 Job
我们可以从Job pod 运行过程中看到次模式中Pod 创建存在先后顺序,即需要等待一个job完成后,开启下一个Job的运行。
工作队列式的并行 Job
一旦一个 Pod 成功终止则所有 Pod 都都终止,此时Job 成功完成。
修改new-jobs.yml,并添加parallelism使其并行数为5
apiVersion: batch/v1 kind: Job metadata: name: command-jobs spec: template: spec: containers: - name: command-jobs image: busybox command: ["/bin/sh","-c","sleep 50;echo 'jobs '"] restartPolicy: Never backoffLimit: 2 parallelism: 5复制代码
此类Job Pod在同一时间创建和结束。
指定任务数的并行 Job
通过spec.completions指定任务数,一旦所有 Pod 成功完成它的任务. 作业将完成。
我们添加一个new-jobs.yml,并指定completions为3
apiVersion: batch/v1 kind: Job metadata: name: command-jobs spec: template: spec: containers: - name: command-jobs image: busybox command: ["/bin/sh","-c","sleep 50;echo 'jobs '"] restartPolicy: Never backoffLimit: 2 completions: 3复制代码
当3个Pod都运行完成时,Job状态为成功执行。
Cronjob周期性任务
CronJob 用于执行周期性的动作,例如备份、邮件、报告生成等。
cron时间配置与linux crontab相似。
# ┌────────────────── 时区 (可选) # | ┌───────────── 分钟 (0 - 59) # | │ ┌───────────── 小时 (0 - 23) # | │ │ ┌───────────── 月的某天 (1 - 31) # | │ │ │ ┌───────────── month (1 - 12) # | │ │ │ │ ┌───────────── 周的某天 (0 - 6)(周日到周一;在某些系统上,7 也是星期日) # | │ │ │ │ │ # | │ │ │ │ │ # | │ │ │ │ │ # CRON_TZ=UTC * * * * *复制代码
添加cronjob.yml如下:
#cronjob.yml apiVersion: batch/v1beta1 kind: CronJob metadata: name: cronjob spec: schedule: "*/1 * * * *" jobTemplate: spec: template: spec: containers: - name: cronjob image: busybox command: ["/bin/sh","-c","date"] restartPolicy: Never复制代码
我们通过cronjob没隔一分钟打印一次日期。
查看cronjob信息:
通过logs查看任务结果:
[docker@localhost yml]$ kubectl logs cronjob-1635010680-n5gxj Sat Oct 23 17:38:15 UTC 2021复制代码
cronjob可以自动清理任务,默认保留3次成功的任务,我们可以通过添加.spec.successfulJobsHistoryLimit
改变保留的历史任务信息即Pod。
以上我们将k8s中Job、Cronjob涉及的大部分内容进行了介绍。
作者:顶级饮水机管理员
链接:https://juejin.cn/post/7022537961333850119