Kubernetes 每天 10 分钟入门系列

  1. 从 RunC 聊起
  2. Kubernetes 介绍与安装
  3. Pod
  4. Service
  5. Replicas
  6. Deployment
  7. Job 和 CronJob
  8. DaemonSet
  9. StatefulSet

本篇概述

在前面两篇中,我已经介绍了 Replicas 和 Deployment,这两种资源类型都是用于控制 Worklload 的。当你使用的时候,可以感受到,这两种类型的资源一般都是持续运行的,同时还有一些辅助的方式帮助在 Workload 出现异常时恢复,以及根据情况进行动态伸缩的特性。

那么,如果我不需要保持我的 workload 持续运行可不可以,例如,在一个 Web 应用真正运行之前,我希望有个 container 能够帮我初始化一下 DB;又或者,我希望有个定时任务可以帮助我定时地刷新一下 DB 的状态,这些场景都不需要 Pod 保持持续地运行,虽然我们了解 Pod 的运行并不会占用太多资源。

事实上,Kubernetes 充分地考虑了这些场景,并且给出了解决方案,那就是 Job 和 CronJob。

Job

在 Kubernetes 的定义中,Job 其实和前面介绍的 Replicas 和 Deployment 原理类似,都是通过定义 Pod 的模板,然后根据 Job 的定义创建出对应的 Pod,然后关注 Pod 的状态,直到满足定义,例如 Pod 执行成功了或者说执行失败了,并且达到了重试次数之类的。这里来看一个简单的 Pod 的例子:

  1. ---
  2. apiVersion: batch/v1
  3. kind: Job
  4. metadata:
  5. name: pi
  6. spec:
  7. template:
  8. spec:
  9. containers:
  10. - name: pi
  11. image: perl
  12. command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
  13. restartPolicy: Never
  14. backoffLimit: 4

这个 Job 的功能很简单,就是计算一下 Pi 的值,完成之后就退出了。我们先将它添加到 Kubernetes 中,然后再看看状态:

  1. [[email protected].io]# kubectl apply -f job00.yaml
  2. [[email protected].io]# kubectl get jobs
  3. NAME COMPLETIONS DURATION AGE
  4. pi 0/1 8m 8m

这个时候 Job 就在准备执行了,可以看到 COMPLETIONS 这一项,期望是 1,实际是 0,然后再看下 Pods 列表:

  1. [[email protected].io]# kubectl get pods
  2. k get pods
  3. NAME READY STATUS RESTARTS AGE
  4. pi-6rsxc 0/1 ContainerCreating 0 2m18s

可以发现确实有 Pod 在执行,并且还没有开始运行。我们等它执行完毕再看下效果:

  1. [[email protected].io]# kubectl get pods
  2. k get pods
  3. NAME READY STATUS RESTARTS AGE
  4. pi-6rsxc 0/1 Completed 0 4m47s
  5. [[email protected].io]# kubectl get jobs
  6. k get jobs
  7. NAME COMPLETIONS DURATION AGE
  8. pi 1/1 14m 17m

可以看到,这里的预期状态已经达成一致了。这是一个只执行一次的任务的 Job,它的操作方式就是创建一个 Pod,然后运行一遍(默认),然后就退出了。如果我们想要运行两遍呢?该怎么处理?其实,在 Job 的描述中加入一个配置项:

加上这一项之后,Kubernetes 就会创建分别创建两次 Pod,然后保证他们都执行成功之后才确认这个 Job 是完成的。

这里有一个注意的地方就是,我们在使用 Deployment 等 Workload 的时候,一般都会指定一个 restartPolicy,默认都是 RestartOnFail,那么在 Job 中,不能这么指定,因为这个逻辑应由 Job 来控制,而不应该让 Pod 来控制。

同时,Job 也不是说会无限期地执行下去,可以通过执行 backoffLimit 来限制失败重试的次数。

CronJob

Job 确实很有用,但是,很多时候我们更需要的是定时执行任务,例如,每小时统计一次商城的销售数据和趋势,类似这样周期性的任务,Kubernetes 在 Job 之上,又定义了 CronJob。之所以说是在 Job 之上,是因为 CronJob 就是在 Job 的基础上加上了周期定义的接口:

  1. ---
  2. apiVersion: batch/v1beta1
  3. kind: CronJob
  4. metadata:
  5. name: batch-job-pi
  6. spec:
  7. schedule: "0,15,30,45 * * * *"
  8. jobTemplate:
  9. spec:
  10. template:
  11. metadata:
  12. labels:
  13. app: pi-job
  14. spec:
  15. containers:
  16. - name: pi
  17. image: perl
  18. command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
  19. restartPolicy: Never

从这份定义中可以看到,除了在外层套了一层 CronJob 的 Meta 数据之外,还有一个 schedule,里面的其实就是一个 Job 的定义了。这份 CronJob 的功能就是每隔 15 分钟算一次 Pi(毫无意义的事情)。然后我们将这份申明应用到 Kubernetes 中之后,每隔 15 分钟就会出现一个 Job。

这里需要说明的一点是,CronJob 目前还不稳定,有诸多问题,例如:

Ref