4.5 运行执行单个任务的pod+4.6 安排Job定期运行或在将来运行一次

4.5 运行执行单个任务的pod

到目前为止，我们只谈论了需要持续运行的pod。你会遇到只想运行完成工作后就终止任务的情况。ReplicationController、ReplicaSet和DaemonSet会持续运行任务，永远达不到完成态。这些pod中的进程在退出时会重新启动。但是在一个可完成的任务中，其进程终止后，不应该再重新启动。

4.5.1 介绍Job资源

Kubernetes通过Job资源提供了对此的支持，这与我们在本章中讨论的其他资源类似，但它允许你运行一种pod，该pod在内部进程成功结束时，不重启容器。一旦任务完成，pod就被认为处于完成状态。

在发生节点故障时，该节点上由Job管理的pod将按照ReplicaSet的pod的方式，重新安排到其他节点。如果进程本身异常退出（进程返回错误退出代码时），可以将Job配置为重新启动容器。

图4.10显示了如果一个Job所创建的pod，在最初被调度节点上异常退出后，被重新安排到一个新节点上的情况。该图还显示了托管的pod（未重新安排）和由ReplicaSet管理的pod（被重新安排）。

例如，Job对于临时任务很有用，关键是任务要以正确的方式结束。可以在未托管的pod中运行任务并等待它完成，但是如果发生节点异常或pod在执行任务时被从节点中逐出，则需要手动重新创建该任务。手动做这件事并不合理 —— 特别是如果任务需要几个小时才能完成。

这样的任务的一个例子是，如果有数据存储在某个地方，需要转换并将其导出到某个地方。你将通过运行构建在busybox镜像上的容器镜像来模拟此操作，该容器将调用sleep命令两分钟。笔者已经构建了镜像并将其推送到Docker Hub，但你可以在本书的代码档案中查看它的Dockerfile。

FROM busybox
ENTRYPOINT echo "$(date) Batch job starting"; sleep 120; echo "$(date) Finished succesfully"

4.5.2 定义Job资源

vi/vim编辑器粘贴yaml 文件会自动缩进, 粘贴前执行如下命令
：set paste
不再缩进,完美解决

按照下面的代码清单创建Job manifest。

apiVersion: batch/v1
kind: Job
metadata:
  name: batch-job
spec:
  template:
    metadata:
      labels:
        app: batch-job
    spec:
      restartPolicy: OnFailure
      containers:
      - name: main
        image: luksa/batch-job

代码清单4.11 Job的YAML定义：exporter.yaml（应为batch-job.yaml）

Job是batch API组v1 API版本的一部分。YAML定义了一个Job类型的资源，它将运行luksa/batch-job镜像，该镜像调用一个运行120秒的进程，然后退出。

在一个pod的定义中，可以指定在容器中运行的进程结束时，Kubernetes会做什么。这是通过pod配置的属性restartPolicy完成的，默认为Always。Job pod不能使用默认策略，因为它们不是要无限期地运行。因此，需要明确地将重启策略设置为OnFailure或Never。此设置防止容器在完成任务时重新启动（pod被Job管理时并不是这样的）。

4.5.3 看Job运行一个pod

在使用kubectl create命令创建此作业后，应该看到它立即启动一个pod：

$ kubectl get jobs

$ kubectl get po

两分钟过后，pod将不再出现在pod列表中，工作将被标记为已完成。默认情况下，除非使用--show-all（或-a）开关，否则在列出pod时不显示已完成的pod：

$ kubectl get po -A

完成后pod未被删除的原因是允许你查阅其日志。例如：

$ kubectl logs batch-job-28qf4

pod可以被直接删除，或者在删除创建它的Job时被删除。在你删除它之前，让我们再看一下Job资源：

$ kubectl get job

作业显示已成功完成。但为什么这样的信息显示为一个数字而不是yes或true?DESIRED列表示什么意思？

4.5.4 在Job中运行多个pod实例

作业可以配置为创建多个pod实例，并以并行或串行方式运行它们。这是通过在Job配置中设置completions 和 parallelism 属性来完成的。

顺序运行Job pod

如果你需要一个Job运行多次，则可以将completions设为你希望作业的pod运行多少次。下面的代码清单显示了一个例子。

代码清单4.12 需要多次完成的Job:multi-completion-batch-job.yaml

apiVersion: batch/v1
kind: Job
metadata:
  name: multi-completion-batch-job # 此任务顺序运行五个pod
spec:
  completions: 5
  template:
    metadata:
      labels:
        app: batch-job
    spec:
      restartPolicy: OnFailure
      containers:
      - name: main
        image: luksa/batch-job

Job将一个接一个地运行五个pod。它最初创建一个pod，当pod的容器运行完成时，它创建第二个pod，以此类推，直到五个pod成功完成。如果其中一个pod发生故障，工作会创建一个新的pod，所以Job总共可以创建五个以上的pod。

并行运行Job pod

不必一个接一个地运行单个Job pod，也可以让该Job并行运行多个pod。可以通过parallelism Job配置属性，指定允许多少个pod并行执行，如下面的代码清单所示。

代码清单4.13 并行运行Job pod:multi-completion-parallel-batch-job.yaml

apiVersion: batch/v1
kind: Job
metadata:
  name: multi-completion-batch-job
spec:
  completions: 5
  parallelism: 2
  template:
    metadata:
      labels:
        app: batch-job
    spec:
      restartPolicy: OnFailure
      containers:
      - name: main
        image: luksa/batch-job

通过将parallelism设置为2,Job创建两个pod并行运行它们：

$ kubectl get po

只要其中一个pod完成任务，工作将运行下一个pod，直到五个pod都成功完成任务。

Job的缩放

你甚至可以在Job运行时更改Job的parallelism属性。这与缩放ReplicaSet或ReplicationController类似，可以使用kubectl scale命令完成：

$ kubectl scale job multi-completion-batch-job --replicas 3

由于你将parallelism从2增加到3，另一个pod立即启动，因此现在有三个pod在运行。

4.5.5 限制Job pod完成任务的时间

关于Job我们需要讨论最后一件事。Job要等待一个pod多久来完成任务？如果pod卡住并且根本无法完成（或者无法足够快完成），该怎么办？

通过在pod配置中设置activeDeadlineSeconds属性，可以限制pod的时间。如果pod运行时间超过此时间，系统将尝试终止pod，并将Job标记为失败。

注意通过指定Job manifest中的spec.backoffLimit字段，可以配置Job在被标记为失败之前可以重试的次数。如果你没有明确指定它，则默认为6。

Job资源在创建时会立即运行pod。但是许多批处理任务需要在特定的时间运行，或者在指定的时间间隔内重复运行。在Linux和类UNIX操作系统中，这些任务通常被称为cron任务。Kubernetes也支持这种任务。

Kubernetes中的cron任务通过创建CronJob资源进行配置。运行任务的时间表以知名的cron格式指定，所以如果你熟悉常规cron任务，你将在几秒钟内了解Kubernetes的CronJob。

在配置的时间，Kubernetes将根据在CronJob对象中配置的Job模板创建Job资源。创建Job资源时，将根据任务的pod模板创建并启动一个或多个pod副本，如你在前一部分中所了解的那样。

让我们来看看如何创建CronJob。

4.6 安排Job定期运行或在将来运行一次

4.6.1 创建一个CronJob

想象一下，你需要每15分钟运行一次前一个示例中的批处理任务。为此，请使用以下规范创建一个CronJob资源。

代码清单4.14 CronJob资源的YAML:cronjob.yaml

apiVersion: batch/v1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            imagePullPolicy: IfNotPresent
            command:
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure

正如你所看到的，它不是太复杂。你已经指定了创建Job对象的时间表和模板。

配置时间表安排

如果你不熟悉cron时间表格式，你会在网上找到很棒的教程和解释，但作为一个快速介绍，时间表从左到右包含以下五个条目：

分钟
小时
每月中的第几天
月
星期几

在该示例中，你希望每15分钟运行一次任务因此schedule字段的值应该是 0,15,30,45**** 这意味着每小时的0、15、30和45分钟（第一个星号），每月的每一天（第二个星号），每月（第三个星号）和每周的每一天（第四个星号）。

相反，如果你希望每隔30分钟运行一次，但仅在每月的第一天运行，则应将计划设置为0,30 * 1 * * ，并且如果你希望它每个星期天的3AM运行，将它设置为0 3 * * 0 （最后一个零代表星期天）。

配置Job模板

CronJob通过CronJob规范中配置的jobTemplate属性创建任务资源，更多有关如何配置它的信息，请参阅4.5节。

4.6.2 了解计划任务的运行方式

使用 CronJob 运行自动化任务一文会为你详细讲解此例。

Cron 时间表语法

# ┌───────────── 分钟 (0 - 59)
# │ ┌───────────── 小时 (0 - 23)
# │ │ ┌───────────── 月的某天 (1 - 31)
# │ │ │ ┌───────────── 月份 (1 - 12)
# │ │ │ │ ┌───────────── 周的某天 (0 - 6) （周日到周一；在某些系统上，7 也是星期日）
# │ │ │ │ │                                   
# │ │ │ │ │
# │ │ │ │ │
# * * * * *

输入	描述	相当于
@yearly (or @annually)	每年 1 月 1 日的午夜运行一次	0 0 1 1 *
@monthly	每月第一天的午夜运行一次	0 0 1 * *
@weekly	每周的周日午夜运行一次	0 0 * * 0
@daily (or @midnight)	每天午夜运行一次	0 0 * * *
@hourly	每小时的开始一次	0 * * * *

例如，下面这行指出必须在每个星期五的午夜以及每个月 13 号的午夜开始任务：

0 0 13 * 5

要生成 CronJob 时间表表达式，你还可以使用 crontab.guru 之类的 Web 工具。

在计划的时间内，CronJob资源会创建Job资源，然后Job创建pod。

可能发生Job或pod创建并运行得相对较晚的情况。你可能对这项工作有很高的要求，任务开始不能落后于预定的时间过多。在这种情况下，可以通过指定CronJob规范中的startingDeadlineSeconds字段来指定截止日期，如下面的代码清单所示。

代码清单4.15 为CronJob指定一个startingDeadlineSeconds

[图片上传失败...(image-952b09-1626483188040)]

在代码清单4.15的例子中，工作运行的时间应该是10:30:00。如果因为任何原因10:30:15不启动，任务将不会运行，并将显示为Failed。

在正常情况下，CronJob总是为计划中配置的每个执行创建一个Job，但可能会同时创建两个Job，或者根本没有创建。为了解决第一个问题，你的任务应该是幂等的（多次而不是一次运行不会得到不希望的结果）。对于第二个问题，请确保下一个任务运行完成本应该由上一次的（错过的）运行完成的任何工作。

4.5 运行执行单个任务的pod+4.6 安排Job定期运行或在将来运行一次