job和cronjob的使用

我们在工作中会遇到需要批量处理数据和分析的需求，也会有按时间来进行调度的工作，在k8s集群中，有job和cronjob两中资源对象来映带我们的这种需要。

job负责处理任务，仅执行一次的任务，他保证批处理任务的一个或多个pod成功结束。而cronjob则就是在job上加上了时间调度，相当于定时任务。

Job

运行一个官方job示例，计算π到2000位，大约需要10秒钟：

apiVersion: batch/v1

kind: Jobs

metadata:

  name: pi

spec:

  template:

  backoffLimit: 6 		#默认重试6次后才认为执行失败

  activeDeadlineSeconds: 100  #重试工作的持续时间，优先级别高于backoffLimit

    spec:

      restartPolicy: Never	#job只有两种重启策略，Never、OnFailure不支持Always,失败状态会陷入失败死循环

      containers:

      - name: pi

        image: perl

        command:

        - perl

        - Mbignum=bpi

        - wle

        - print bpip(2000)

#  请注意，作业的.spec.activeDeadlineSeconds优先于.spec.backoffLimit。因此，重试一个或多个失败Pod的Job一旦达到所指定的时间限制activeDeadlineSeconds，就不会部署其他Pod ，即使backoffLimit尚未达到。

parallel(并行) Jobs

适应job运行的三种模式：

Non-parallel(非并行) Jobs
- 通常情况，除非pod发生故障，否则仅启动一个pod
- pod运行成功后，job成complate状态
固定parallel(并行)Jobs一个完成次数

.spec.completion指定一个非零的正值

job是整体任务，在1到范围内的每个值都有一个成功的Pod时完成 .spec.completions

具有工作队列的parallel(并行)Jobs
- 不指定 .spec.completions ,默认为 .spec.parallelism
- pod必须在彼此之间或外部服务之间进行协调，以确定每个pod应该如何处理。例如一个pod可以从工作队列中最多获取N批的批处理
- 每个pod都可以独立地确定其所有对等方是否都已完成，从而确定整个pod状态
- 当jobs中任何pod成功终止时，不会创建新的pod
- 所有pod成功终止，则jobs完成
- pod成功推出后，其他pod不应该为此任务再做任何工作或编写任何输出。他们都应该退出

对于非并行jobs，您可以同时保留.spec.completions和不.spec.parallelism设置。两者均未设置时，均默认为1。

对于固定的完成计数jobs，您应该设置.spec.completions为所需的完成数量。您可以设置.spec.parallelism，或不设置它，默认为1。

对于工作队列 Job，您必须保持未.spec.completions设置状态，并将其设置.spec.parallelism为非负整数。

有关如何利用不同类型的jobs的更多信息，请参见jobs模式部分。

处理Pod和容器故障

Pod中的容器可能由于多种原因而失败，例如，由于该容器中的进程以非零退出代码退出，或者该容器因超出内存限制而被杀死等。如果发生这种情况，请使用.spec.template.spec.restartPolicy = "OnFailure"，然后Pod停留在节点上，但是容器重新运行。因此，您的程序需要在本地重新启动时处理该情况，或者指定.spec.template.spec.restartPolicy = "Never"。有关的更多信息，请参见pod生命周期restartPolicy。

Pod后退失败策略

在某些情况下，由于配置中的逻辑错误等原因，您需要在重试一定次数后使jobs失败。为此，设置.spec.backoffLimit为指定重试次数，然后再将jobs视为失败。默认情况下，将退避限制设置为6。与jobs相关联的失败Pod由Job控制器重新创建，并且其指数退避延迟（10s，20s，40s…）限制为六分钟。如果在jobs的下一个状态检查之前未出现新的失败Pod，则会重置退避计数。

注意：版本1.12之前的Kubernetes版本仍然存在问题＃54870

注意：如果您的jobs具有restartPolicy = "OnFailure"，请记住，一旦达到jobs退避限制，运行该jobs的容器将被终止。这会使调试jobs的可执行文件更加困难。我们建议restartPolicy = "Never"在调试jobs或使用日志记录系统时进行设置，以确保不会因疏忽而丢失失败的jobs的输出。

请注意，作业的.spec.activeDeadlineSeconds优先于.spec.backoffLimit。因此，重试一个或多个失败Pod的Job一旦达到所指定的时间限制activeDeadlineSeconds，就不会部署其他Pod ，即使backoffLimit尚未达到。

CronJob

CronJob其实就是在Job的基础上加上了时间调度，我们可以：在给定的时间点运行一个任务，也可以周期性地在给定时间点运行。这个实际上和我们Linux中的crontab就非常类似了。

一个CronJob对象其实就对应中crontab文件中的一行，它根据配置的时间格式周期性地运行一个Job，格式和crontab也是一样的。

crontab的格式如下：

分时日月星期要运行的命令 第1列分钟0～59 第2列小时0～23）第3列日1～31 第4列月1～12 第5列星期0～7（0和7表示星期天）第6列要运行的命令

现在，我们用CronJob来管理我们上面的Job任务，

apiVersion: batch/v2alpha1

kind: CronJob

metadata:

  name: cronjob-demo

spec:

  schedule: "*/1 * * * *"

  jobTemplate:

    spec:

      template:

        spec:

          restartPolicy: OnFailure

          containers:

          - name: hello

            image: busybox

            args:

            - "bin/sh"

            - "-c"

            - "for i in 9 8 7 6 5 4 3 2 1; do echo $i; done"

我们这里的Kind是CronJob了，要注意的是.spec.schedule字段是必须填写的，用来指定任务运行的周期，格式就和crontab一样，另外一个字段是.spec.jobTemplate, 用来指定需要运行的任务，格式当然和Job是一致的。还有一些值得我们关注的字段.spec.successfulJobsHistoryLimit和.spec.failedJobsHistoryLimit，表示历史限制，是可选的字段。它们指定了可以保留多少完成和失败的Job，默认没有限制，所有成功和失败的Job都会被保留。然而，当运行一个Cron Job时，Job可以很快就堆积很多，所以一般推荐设置这两个字段的值。如果设置限制的值为 0，那么相关类型的Job完成后将不会被保留。