Kubernetes(k8s)-CronJob介绍

我们上一章介绍了Docker基本情况，目前在规模较大的容器集群基本都是Kubernetes，但是Kubernetes涉及的东西和概念确实是太多了，而且随着版本迭代功能在还增加，笔者有些功能也确实没用过，所以只能按照我自己的理解来讲解。

前面我们的Job属于一次性任务，但是对于那种持续运行任务应该怎么实现呢？Kubernetes给我们提供了一个类似crontab的资源名称CronJob。

Kubernetes（k8s）中的CronJob是一个用于定时执行任务的资源对象。CronJob类似于Linux系统中的cron作业(Linux日常运维-任务计划crontab)，它允许你按照预定的时间表（基于Cron格式的表达式）运行容器。

范例

apiVersion: batch/v1
kind: CronJob
metadata:
  name: extensive-cronjob
  namespace: default
spec:
  schedule: "* * * * *"  # 每分钟执行一次
  startingDeadlineSeconds: 200  # 如果错过执行时间，最多等待200秒
  concurrencyPolicy: Forbid  # 禁止并发执行
  successfulJobsHistoryLimit: 5  # 保留5个成功的Job历史记录
  failedJobsHistoryLimit: 3  # 保留3个失败的Job历史记录
  suspend: false  # 是否挂起CronJob，默认为false
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: my-container
            image: 192.168.31.43:5000/busybox
            command: ["sh", "-c", "echo Hello, Kubernetes Job! && sleep 30"]
            imagePullPolicy: IfNotPresent
          restartPolicy: OnFailure  # Job的重启策略

schedule: Cron格式的字符串，定义了Job的执行时间表，也遵循和Linux任务计划一样的时间规划：分钟，小时，日期，月份，星期。

startingDeadlineSeconds: 如果CronJob控制器因为任何原因错过了执行时间，它将等待该参数指定的时间（秒）来尝试执行Job。如果 Job 应该在10:00:00开始，但由于节点故障直到10:01:00才恢复，那么从10:01:00开始计算，Job 有200秒的时间窗口来启动。如果在此200秒的时间窗口内（即10:05:20之前），Pod 成功启动了，那么 Job 将正常进行。如果超过了这个时间窗口 Pod 还没有启动，Kubernetes 将不再尝试启动该 Job，并将其标记为失败。

concurrencyPolicy: 定义了如何处理Job的并发执行。Allow（默认）：允许并发执行。Forbid：禁止并发执行，如果新的Job应该被创建，但前一个Job尚未完成，则跳过新的Job。Replace：如果新的Job应该被创建，但前一个Job尚未完成，则用新的Job替换前一个Job。所以需要根据实际情况合理控制时间，避免出现旧任务还没有跑完，新任务又来，然后程序任务风暴，打垮整个集群。也需要考虑到任务未执行完成又被重新开始执行，永远都无法执行完成的情况。

successfulJobsHistoryLimit: 保留多少个成功完成的Job记录，Pod正常完成状态就会显示为Completed。

曾经在生产环境见过Job还是CronJob太多，一直保留，然后把节点的ip地址用光的情况。

failedJobsHistoryLimit: 保留多少个失败Job的记录。

suspend: 如果设置为true，则这个CronJob则暂时不会执行，类似只是创建了任务，但是不执行，如果要让它执行，再需要修改为false值。

执行状态

每一个Cronjob实际上执行一次就等于创建了一个Job。如果Job正常执行完成则pod的状态也是正常退出的Completed。