”离线任务“也叫Batch Job，这种业务在计算完成后就直接退出了。Job就是用来描述历险业务的API对象

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    spec:
      containers:
      - name: pi
        image: resouer/ubuntu-bc
        command: ["sh", "-c", "echo 'scale=10000; 4*a(1)' | bc -l "]
	  restartPolicy: Never
  backoffLimit: 4

Job Controller不需要显式的指定spec.selector，而是由控制器自动给Pod模版加上一个Label并指定Selector为这个Label，以此实现Job和它所管理的Pod匹配

restartPolicy在Job对象里只允许设置为Never和OnFailure，而在Deployment对象里，只允许设置为Always

如果设置为Never，当Job出现错误失败时，Job Controller会不断尝试创建一个新的Pod，重新尝试的次数由backoffLimit，而设定为OnFailure则会不断尝试重启Pod里的容器

spec.activeDeadlineSeconds可以配置Job最长的运行时间

spec.parallelism可以指定在任意时间最多可以启动多少个Pod同时运行

spec.completions可以定义Job至少要完成的Pod数目，即Job的最小完成数

三种常用的Job对象使用方法：

1. 外部管理器+Job模板
   shell 脚本生成若干Job模板，依次提交
2. 拥有固定任务数目的并行Job
   只关心最后是否有指定数目的任务成功退出，而不关心执行时的并行度
   可以使用一个工作队列进行任务分发：

apiVersion: batch/v1
kind: Job
metadata:
  name: job-wq-1
spec:
  completion: 8
  parallelism: 2
  template:
    metadata:
      name: job-wq-1
    spec:
      containers:
      - name: c
        image: myrepo/job-wq-1
        env:
        - name: BROKER_URL
          value: amqp://guest:guest@rabbitmq-service:5672
        - name: QUEUE
          value: job1
      restartPolicy: OnFailure

这个例子中定义了一个RabbitMQ来作为消费者，每个Pod都会去连接BROKER_URL，从RabbitMQ中读取任务，然后各自处理

3. 指定并行度，但不设置固定的completions的值

这时需要自己决定何时启动新的Pod，何时Job才算执行完成

CronJob描述的是定时任务，它是一个Job对象的控制器

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  // 标准的Unix Cron格式的表达式，来指定定时任务的创建周期和时间
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            args:
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster
		  restartPolicy: OnFailure

由于定时任务的特殊性，可能某个Job还没执行完，另外一个新的Job就产生了，可以通过spec.concurrencyPolicy字段来定义具体的处理策略

1. Allow: 默认情况，意味着这些Job可以同时存在
2. Forbid: 不会创建新的Pod，该创建周期被跳过
3. Replace: 创建新的Job替换旧的、未执行完的Job