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，或者根本没有创建。为了解决第一个问题，你的任务应该是幂等的（多次而不是一次运行不会得到不希望的结果）。对于第二个问题，请确保下—个任务运行完成本应该由上一次的（错过的）运行完成的任何工作。
