Kubernetes之job

1.运行单个任务的pod

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

 

1.1 介绍Job资源

　　Kubernetes通过Job资源提供了对此的支持，它允许你运行一种pod,该pod在内部进程成功结束时，不重启容器。一旦任务完成，pod就被认为处于完成状态。

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

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

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

　　这样的任务的一个例子是，如果有数据存储在某个地方，需要转换并将其导出到某个地方。你将通过运行构建在busybox镜像上的容器镜像来模拟此操作，该容器将调用sleep命令两分钟。镜像可以自己构建，这里只演示一些结果。

1.2 定义Job资源

apiVersion: batch/v1        #job属于batch API组，版本为v1
kind: Job
metadata:
  name: batch-job
spec:                                 #没有指定pod选择器（他将根据pod模版中的标签创建）
  template:
    metadata:
      labels:
        app: batch-job
    spec:
      restartPolicy: OnFailure   #job不能使用Always为默认的重新启动策略
      containers:
      - name: main
        image: luksa/batch-job

　　Job是batch API组v1 API版本的一部分。YAML定义了一个Job类型的资源, 它将运行luksa/batch-job镜像，该镜像调用一个运行120秒的进程，然后退出。在一个pod的定义中，可以指定在容器中运行的进程结束时，Kubernetes会做什么。这是通过pod配置的属性restartPolicy完成的，默认为Always。Job pod不能使用默认策略，因为它们不是要无限期地运行。

　　因此，需要明确地将重启策略设置为OnFailure或Never。此设置防止容器在完成任务时重新启动（pod被Job管理时并不是这样的）。

 

1.3 Job运行一个pod

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

$ kubectl get jobs
NAME    　　DESIRED SUCCESSFUL  AGE
batch-job    1     　　0        2s
$ kubectl get po
NAME               READY    STATUS    RESTARTS    AGE
batch-job-28qf4    1/1      Running        0      4s

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

$ kubectl get po -a
NAME                READY    STATUS    RESTARTS    AGE
batch-job-2Bqf4    0/1    Completed    0           2m

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

$ kubectl logs batch-job-28qf4
Fri Apr 29 09:58:22 UTC 2016 Batch job starting Fri Apr 29 10:00:22 UTC 2016 Finished succesfully

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

$ kubectl get job
NAME      DESIRED SUCCESSFUL AGE
batch-job    1       1       9m

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

 

1.4 在Job中运行多个pod实例

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

　　顺序运行Job pod

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

apiVersion: batch/v1
kind: Job
metadata:
  name: multi-completion-batch-job
spec:
  completions: 5          #将completions设置为5，将使此作业顺利运行5个pod
  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

apiVersion: batch/v1
kind: Job
metadata:
  name: multi-completion-batch-job
spec:
  completions: 5             #这项任务要保证五个pod成功完成
  parallelism: 2               #最多两个pod可以并行运行
  template:
    metadata:
      labels:
        app: batch-job
    spec:
      restartPolicy: OnFailure
      containers:
      - name: main
        image: luksa/batch-job

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

$ kubectl get po
NAME                          　　　　　　READY    STATUS    RESTARTS AGE
multi-completion-batch-job-lmmnk         1/1    Running       0     21s
multi-completion-batch-job -qx4nq        1/1    Running       0     21s

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

　　Job的缩放

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

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

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

 

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

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

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

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

 

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

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

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

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

　　接下来如何创建CronJob。

2.1 创建一个CronJob

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

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: batch-job-every-fifteen-minutes
spec:
  schedule: "0,15,30,45 * * * *"            #这项工作每天在每小时0、15、30和45分钟运行
  jobTemplate:
    spec:
      template:                                       #此CronJob创建job资源会用到的模版
        metadata:
          labels:
            app: periodic-batch-job
        spec:
          restartPolicy: OnFailure
          containers:
          - name: main
            image: luksa/batch-job

　　配置时间表安排

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

• • 分钟
  • 小时
  • 日
  • 月
  • 星期几

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

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

　　配置Job模板

　　CronJob通过CronJob规范中配置的jobTemplate属性创建任务资源。

 

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

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

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

#代码4.15，为Crontab指定一个startingDeadlineSeconds
apiVersionbatch/v1beta1
kind: CronJob
spec:
   schedule "0,15,30,45 * * * *"
   startingDeadlineSeconds:15   #pod最迟必须在预定时间后15秒开始运行

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

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