系列目录

job是什么

对于ReplicaSet、ReplicationController等类型的控制器而言，它希望pod保持预期数目、持久运行下去，除非用户明确删除，否则这些对象一直存在，它们针对的是耐久性任务，如web服务等。对于非耐久性任务，比如压缩文件，任务完成后，pod需要结束运行，不需要pod继续保持在系统中，这个时候就要用到Job。因此说Job是对ReplicaSet、ReplicationController等持久性控制器的补充。

Job与其它控制器的细微差别

Job定义方法与ReplicaSet等控制器相似，只有细微差别，如下：

• Job中的restart policy必需是"Never"或者"OnFailure"，这个很好理解，因为pod要运行到结束，而不是反复重新启动。

• Job不需要选择器，其中的pod也不需要标签，系统在创建Job时会自动添加相关内容。当然用户也可以出于资源组织的目的添加标签，但这个与Job本身的实现没有关系。

• Job新增加两个字段：.spec.completions、.spec.parallelism。详细用法在示例中说明

• backoffLimit字段：示例中说明

示例

非并发Job

非并发Job的含义是，Job启动后，只运行一个pod，pod运行结束后整个Job也就立刻结束。

以下是简单的Job配置文件，只包含一个pod，输出圆周率小数点后2000位，运行时间大概为10s：

apiVersion: batch/v1kind: Jobmetadata: name: pispec: template: spec: containers: - name: pi image: perl command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] restartPolicy: Never backoffLimit: 4

以上示例无需设置选择器、pod标签。无需设置.spec.completions、.spec.parallelism，这两个字段的默认值都是1。backoffLimit=4，表示允许pod失败的次数。将以上内容保存成文件并创建Job：

$ kubectl create -f https://k8s.io/examples/controllers/job.yamljob "pi" created

确认Job状态：

$ kubectl describe jobs/piName: piNamespace: defaultSelector: controller-uid=b1db589a-2c8d-11e6-b324-0209dc45a495Labels: controller-uid=b1db589a-2c8d-11e6-b324-0209dc45a495 job-name=piAnnotations: <none>Parallelism: 1Completions: 1Start Time: Tue, 07 Jun 2016 10:56:16 +0200Pods Statuses: 0 Running / 1 Succeeded / 0 FailedPod Template: Labels: controller-uid=b1db589a-2c8d-11e6-b324-0209dc45a495 job-name=pi Containers: pi: Image: perl Port: Command: perl -Mbignum=bpi -wle print bpi(2000) Environment: <none> Mounts: <none> Volumes: <none>Events: FirstSeen LastSeen Count From SubobjectPath Type Reason Message --------- -------- ----- ---- ------------- -------- ------ ------- 1m 1m 1 {job-controller } Normal SuccessfulCreate Created pod: pi-dtn4q

从以上输出可以看到系统自动添加的Selector、Pod labels。注意Events的输出，全程只创建了一个pod。

列出Job的所有pod：

$ pods=$(kubectl get pods --selector=job-name=pi --output=jsonpath={.items..metadata.name})$ echo $podspi-aiw0a

查看Pod的输出

$ kubectl logs $pods3.14159265358979323846264......

以上是最简单的Job应用示例，输出圆周率小数点后2000位。但是，考虑另外一种情况，假如我们需要计算圆周率小数点后3000、4000、5000位怎么办？一种方案是先将上例中的2000改成3000，创建并运行。然后再改成4000，再创建并运行，一直到5000。显然这种方案并不高明：麻烦、资源利用率低。另外一种方法是同时创建4个Job，分别计算2000、3000、4000、5000。注意4个Job的name字段不能冲突分别是pi-2000、pi-3000、pi-4000、pi-5000，
文件名分别为pi-2000.yaml、pi-3000.yaml、pi-4000.yaml、pi-5000.yaml，并保存在目录/tmp/pi下。利用kubectl对目录的支持一次性创建4个Job：

$ kubectl create -f /tmp/pijob "pi-2000" createdjob "pi-3000" createdjob "pi-4000" createdjob "pi-5000" created

以上方法是伪并发，只适用于任务量少的情况。假如我们需要处理的任务是从pi-1到pi-10000，那么以上方法就不适用了：

• 需要同时创建太多的Job与pod，不好管理。

• 资源配额限制。

粗并发Job

本例创建一个Job，但Job要创建多个pod。了解完示例后就明白为什么叫“粗并发”。

本示例需要一个消息队列服务的配合，不详细描述如何部署、填充消息队列服务。假设我们有一个RabbitMQ服务，集群内访问地址为：amqp://guest:guest@rabbitmq-service:5672。其有一个名为job1的队列，队列内有apple banana cherry date fig grape lemon melon共8个成员。

另外假设我们有一个名为gcr.io/ /job-wq-1的image，其功能是从队列中读取出一个元素并打印到标准输出，然后结束。注意，它只处理一个元素就结束了。接下来创建如下Job：

apiVersion: batch/v1kind: Jobmetadata: name: job-wq-1spec: completions: 8 parallelism: 2 template: metadata: name: job-wq-1 spec: containers: - name: c image: gcr.io/<project>/job-wq-1 env: - name: BROKER_URL value: amqp://guest:guest@rabbitmq-service:5672 - name: QUEUE value: job1 restartPolicy: OnFailure

上例中，completions的值为8，等于job1队列中元素的个数。因为每个成功的pod处理一个元素，所以需要成功8次，job1中的所有成员就会被处理完成。在粗并发模式下，completions的值必需指定，否则其默认值为1，整个Job只处理一个成员就结束了。

上例中，parallelism的值是2。虽然需要pod成功8次，但在同一时间，只允许有两个pod并发。一个成功结束后，再启动另一个。这个参数的主要目的是控制并发pod的个数，可根据实际情况调整。当然可以不指定，那么默认的并发个数就是1。

env中的内容告诉image如何访问队列。

将以上内容保存在job.yaml文件中，运行Job：

kubectl create -f ./job.yaml

稍等片刻Job运行完成，查看结果：

$ kubectl describe jobs/job-wq-1Name: job-wq-1Namespace: defaultSelector: controller-uid=41d75705-92df-11e7-b85e-fa163ee3c11fLabels: controller-uid=41d75705-92df-11e7-b85e-fa163ee3c11f job-name=job-wq-1Annotations: <none>Parallelism: 2Completions: 8Start Time: Wed, 06 Sep 2017 16:42:02 +0800Pods Statuses: 0 Running / 8 Succeeded / 0 FailedPod Template: Labels: controller-uid=41d75705-92df-11e7-b85e-fa163ee3c11f job-name=job-wq-1 Containers: c: Image: gcr.io/causal-jigsaw-637/job-wq-1 Port: Environment: BROKER_URL: amqp://guest:guest@rabbitmq-service:5672 QUEUE: job1 Mounts: <none> Volumes: <none>Events: FirstSeen LastSeen Count From SubobjectPath Type Reason Message ───────── ──────── ───── ──── ───────────── ────── ────── ─────── 27s 27s 1 {job } Normal SuccessfulCreate Created pod: job-wq-1-hcobb 27s 27s 1 {job } Normal SuccessfulCreate Created pod: job-wq-1-weytj 27s 27s 1 {job } Normal SuccessfulCreate Created pod: job-wq-1-qaam5 27s 27s 1 {job } Normal SuccessfulCreate Created pod: job-wq-1-b67sr 26s 26s 1 {job } Normal SuccessfulCreate Created pod: job-wq-1-xe5hj 15s 15s 1 {job } Normal SuccessfulCreate Created pod: job-wq-1-w2zqe 14s 14s 1 {job } Normal SuccessfulCreate Created pod: job-wq-1-d6ppa 14s 14s 1 {job } Normal SuccessfulCreate Created pod: job-wq-1-p17e0

查看Events，可以看到总共创建了8个pod。在本例中，每处理队列中的一个成员都需要创建一个pod，开销很大。如果队列中的成员个数非常庞大，那么这种处理方式就不适用。我们希望少创建pod、每个pod能处理多条记录,请看下面示例

细并发Job

redis:6379> lrange job2 0 -11) "apple"2) "banana"3) "cherry"4) "date"5) "fig"6) "grape"7) "lemon"8) "melon"9) "orange"

接下来创建image，详细过程不描述。只需确定这个image运行如下名为worker.py的python程序

#!/usr/bin/env python import timeimport rediswq host="redis"# Uncomment next two lines if you do not have Kube-DNS working.# import os# host = os.getenv("REDIS_SERVICE_HOST") q = rediswq.RedisWQ(name="job2", host="redis")print("Worker with sessionID: " + q.sessionID())print("Initial queue state: empty=" + str(q.empty()))while not q.empty(): item = q.lease(lease_secs=10, block=True, timeout=2) if item is not None: itemstr = item.decode("utf=8") print("Working on " + itemstr) time.sleep(10) # Put your actual work here instead of sleep. q.complete(item) else: print("Waiting for work")print("Queue empty, exiting")

首先连接到redis的job2队列。然后是一个while循环，每次读job2中的一条记录并输出，然后sleep 10s。循环退出的条件是job2队列为空。这个image与示例2不同，示例2只处理一条记录这就结束，而这个可以处理多条一直到队列为空。

接下来定义Job：

apiVersion: batch/v1kind: Jobmetadata: name: job-wq-2spec: parallelism: 2 template: metadata: name: job-wq-2 spec: containers: - name: c image: gcr.io/myproject/job-wq-2 restartPolicy: OnFailure

上例中，无需像示例2一样指定 completions的值，因为结束条件是job2为空，已经内嵌在image的逻辑中。parallelism=2表示可以并发两个pod，不设置默认为1，在实际应用中可据实际情况自行调整。

运行Job：

kubectl create -f ./job.yaml

过一会查看Job运行状况：

$ kubectl describe jobs/job-wq-2Name: job-wq-2Namespace: defaultSelector: controller-uid=b1c7e4e3-92e1-11e7-b85e-fa163ee3c11fLabels: controller-uid=b1c7e4e3-92e1-11e7-b85e-fa163ee3c11f job-name=job-wq-2Annotations: <none>Parallelism: 2Completions: <unset>Start Time: Mon, 11 Jan 2016 17:07:59 -0800Pods Statuses: 1 Running / 0 Succeeded / 0 FailedPod Template: Labels: controller-uid=b1c7e4e3-92e1-11e7-b85e-fa163ee3c11f job-name=job-wq-2 Containers: c: Image: gcr.io/exampleproject/job-wq-2 Port: Environment: <none> Mounts: <none> Volumes: <none>Events: FirstSeen LastSeen Count From SubobjectPath Type Reason Message --------- -------- ----- ---- ------------- -------- ------ ------- 33s 33s 1 {job-controller } Normal SuccessfulCreate Created pod: job-wq-2-lglf8

虽然允许的最大并发数是2，但Events显示只创建成功一个pod，这个是正常情况，最大并非必需，可能系统因为资源问题达不到最大。

查看pod输出：

$ kubectl logs pods/job-wq-2-7r7b2Worker with sessionID: bbd72d0a-9e5c-4dd6-abf6-416cc267991fInitial queue state: empty=FalseWorking on bananaWorking on dateWorking on lemon

细并发相比与粗并发，减少了创建pod的开销，使每个pod能处理多条记录，但是pod要自己决定退出条件，如果不退出，那么Job永远无法结束。

关于资源回收

Job创建的pod在结束运行后，无论是成功还是失败，不会默认删除，仍然保留在系统中，这样用户才可以查看其日志、状态信息、排除错误。用户需要手动运行kubectl delete删除所有运行结束的pod，为了方便组织资源，一次性删除会部pod，可以被pod自定义标签。Job在运行完成后也仍然保留在系统中，由用户删除。所以使用Job，用户应注意资源回收，避免资源被耗尽。