1.运行一次性容器
容器按照持续运行的时间可分为两类：
服务类容器
服务类容器通常持续提供服务，需要一直运行，比如 http server，daemon 等。
工作类容器
工作类容器则是一次性任务，比如批处理程序，完成后容器就退出。
Kubernetes 的 Deployment、ReplicaSet 和 DaemonSet 都用于管理服务类容器；对于工作类容器，我们用 Job。
先看一个简单的 Job 配置文件 myjob.yml：
① batch/v1是当前job的Version
② 指定当前资源的类型时Job
③restartPolicy是指当前的重启策略。对于 Job，只能设置为 Never 或者 OnFailure。对于其他 controller（比如 Deployment）可以设置为 Always 。
启动这个job
[root@k8s-master k8s]# kubectl apply -f myjob.yml job.batch/myjob created
kubectl get job 查看这个job
[root@k8s-master k8s]# kubectl get job NAME COMPLETIONS DURATION AGE myjob 1/1 23s 3m45s
completions为 1/1 表示成功运行了这个job
kubectl get pod 查看pod的状态
[root@k8s-master k8s]# kubectl get pod NAME READY STATUS RESTARTS AGE myjob-29qlw 0/1 Completed 0 4m5s
看到 状态为Completed表示这个job已经运行完成
kubectl logs 命令查看这个 pod的日志
[root@k8s-master k8s]# kubectl logs myjob-29qlw hello k8s job!
2.Job的执行失败
将配置文件中的正确命令 echo 换成一个不存在的错误命令 invalid_command
查看job的时候发现COMPLETIONS 0/1 这个job没有完成。但是我们的重启策略是never，所以他不会重启，如果我们将策略设置为 onFaillure
[root@k8s-master k8s]# kubectl delete -f myjob.yml job.batch "myjob" deleted [root@k8s-master k8s]# kubectl apply -f myjob.yml job.batch/myjob created
通过kubectl get pod 查看pod
发现2分钟42秒 容器重启了4次
通过 kubectl describe pod 查看pod的日志
如果容器启动失败，它会自动回退并重启。
先前的版本是一个容器重启失败，他会继续开启一个新的容器，他检测completions 是否为1 如果不为1，就会一直开启新的容器，这样做非常浪费资源，而且有可能会让CPU内存等资源耗尽，新版本做了改进不会一直创建，而是一直回退重启这个失败的容器。并且重启次数达到一定次数，会自动删除这个容器不在执行这个job。我认为这是一个很睿智的改进。
3.并行执行job
有时，我们希望能同时运行多个 Pod，提高 Job 的执行效率。这个可以通过 parallelism设置。
将上面的错误命令改成正确的echo
job一共启动了两个pod，而且AGE是相同，证明是并发执行完成的。
上面通过kubectl get job 看到 completions的缺省值为1，我们现在将它设置为6
重新启动 Job 查看到 completions 变为了 6
通过查看pod 创建的时间 发现 总有个两个相近完成时间创建的pod ，验证了并发执行为2的设置
上面的例子只是为了演示 Job 的并行特性，实际用途不大。不过现实中确实存在很多需要并行处理的场景。比如批处理程序，每个副本（Pod）都会从任务池中读取任务并执行，副本越多，执行时间就越短，效率就越高。这种类似的场景都可以用 Job 来实现。
4.定时执行Job
Linux 中有 cron 程序定时执行任务，Kubernetes 的 CronJob 提供了类似的功能，可以定时执行 Job。
CronJob 配置文件cronjob.yml示例如下：
apiVersion: batch/v2alpha1
kind: CronJob
metadata:
name: hello
spec:
schedule: "*/1 * * * *"
jobTemplate:
spec:
template:
spec:
containers:
- name: hello
image: busybox
command: ["echo","hello k8s job!"]
restartPolicy: OnFailure
① batch/v2alpha1 是当前 CronJob 的 apiVersion。
② 指明当前资源的类型为 CronJob。
③ schedule 指定什么时候运行 Job，其格式与 Linux cron 一致。这里 */1 * * * * 的含义是每一分钟启动一次。
④ jobTemplate 定义 Job 的模板，格式与前面 Job 一致。
执行后报如下错误：
[root@k8s-master k8s]# kubectl apply -f cronjob.yml error: unable to recognize "cronjob.yml": no matches for kind "CronJob" in version "batch/v2alpha1"
我们只需要更改一下/etc/kubernetes/manifests/kube-apiserver.yaml，增加如下配置，重启 kubelet服务，然后重新执行这个cronJob
[root@k8s-master k8s]# systemctl restart kubelet
确认这个api已被加载
再次执行这个cronjob
[root@k8s-master k8s]# kubectl apply -f cronjob.yml cronjob.batch/hello created
等待几分钟，然后通过 kubectl get jobs 查看 Job 的执行情况：
通过AGE发现 每个job都比之前的多了 60s，正好符合我们的预期
使用 kubect get pods 和 kubectl logs 命令查看
5.小结
运行容器化应用是 Kubernetes 最重要的核心功能。为满足不同的业务需要，Kubernetes 提供了多种 Controller，包括 Deployment、DaemonSet、Job、CronJob 等。
1.运行一次性容器
容器按照持续运行的时间可分为两类：
服务类容器
服务类容器通常持续提供服务，需要一直运行，比如 http server，daemon 等。
工作类容器
工作类容器则是一次性任务，比如批处理程序，完成后容器就退出。
Kubernetes 的 Deployment、ReplicaSet 和 DaemonSet 都用于管理服务类容器；对于工作类容器，我们用 Job。
先看一个简单的 Job 配置文件 myjob.yml：
① batch/v1是当前job的Version
② 指定当前资源的类型时Job
③restartPolicy是指当前的重启策略。对于 Job，只能设置为 Never 或者 OnFailure。对于其他 controller（比如 Deployment）可以设置为 Always 。
启动这个job
[root@k8s-master k8s]# kubectl apply -f myjob.yml job.batch/myjob created
kubectl get job 查看这个job
[root@k8s-master k8s]# kubectl get job NAME COMPLETIONS DURATION AGE myjob 1/1 23s 3m45s
completions为 1/1 表示成功运行了这个job
kubectl get pod 查看pod的状态
[root@k8s-master k8s]# kubectl get pod NAME READY STATUS RESTARTS AGE myjob-29qlw 0/1 Completed 0 4m5s
看到 状态为Completed表示这个job已经运行完成
kubectl logs 命令查看这个 pod的日志
[root@k8s-master k8s]# kubectl logs myjob-29qlw hello k8s job!
2.Job的执行失败
将配置文件中的正确命令 echo 换成一个不存在的错误命令 invalid_command
查看job的时候发现COMPLETIONS 0/1 这个job没有完成。但是我们的重启策略是never，所以他不会重启，如果我们将策略设置为 onFaillure
[root@k8s-master k8s]# kubectl delete -f myjob.yml job.batch "myjob" deleted [root@k8s-master k8s]# kubectl apply -f myjob.yml job.batch/myjob created
通过kubectl get pod 查看pod
发现2分钟42秒 容器重启了4次
通过 kubectl describe pod 查看pod的日志
如果容器启动失败，它会自动回退并重启。
先前的版本是一个容器重启失败，他会继续开启一个新的容器，他检测completions 是否为1 如果不为1，就会一直开启新的容器，这样做非常浪费资源，而且有可能会让CPU内存等资源耗尽，新版本做了改进不会一直创建，而是一直回退重启这个失败的容器。并且重启次数达到一定次数，会自动删除这个容器不在执行这个job。我认为这是一个很睿智的改进。
3.并行执行job
有时，我们希望能同时运行多个 Pod，提高 Job 的执行效率。这个可以通过 parallelism设置。
将上面的错误命令改成正确的echo
job一共启动了两个pod，而且AGE是相同，证明是并发执行完成的。
上面通过kubectl get job 看到 completions的缺省值为1，我们现在将它设置为6
重新启动 Job 查看到 completions 变为了 6
通过查看pod 创建的时间 发现 总有个两个相近完成时间创建的pod ，验证了并发执行为2的设置
上面的例子只是为了演示 Job 的并行特性，实际用途不大。不过现实中确实存在很多需要并行处理的场景。比如批处理程序，每个副本（Pod）都会从任务池中读取任务并执行，副本越多，执行时间就越短，效率就越高。这种类似的场景都可以用 Job 来实现。
4.定时执行Job
Linux 中有 cron 程序定时执行任务，Kubernetes 的 CronJob 提供了类似的功能，可以定时执行 Job。
CronJob 配置文件cronjob.yml示例如下：
apiVersion: batch/v2alpha1
kind: CronJob
metadata:
name: hello
spec:
schedule: "*/1 * * * *"
jobTemplate:
spec:
template:
spec:
containers:
- name: hello
image: busybox
command: ["echo","hello k8s job!"]
restartPolicy: OnFailure
① batch/v2alpha1 是当前 CronJob 的 apiVersion。
② 指明当前资源的类型为 CronJob。
③ schedule 指定什么时候运行 Job，其格式与 Linux cron 一致。这里 */1 * * * * 的含义是每一分钟启动一次。
④ jobTemplate 定义 Job 的模板，格式与前面 Job 一致。
执行后报如下错误：
[root@k8s-master k8s]# kubectl apply -f cronjob.yml error: unable to recognize "cronjob.yml": no matches for kind "CronJob" in version "batch/v2alpha1"
我们只需要更改一下/etc/kubernetes/manifests/kube-apiserver.yaml，增加如下配置，重启 kubelet服务，然后重新执行这个cronJob
[root@k8s-master k8s]# systemctl restart kubelet
确认这个api已被加载
再次执行这个cronjob
[root@k8s-master k8s]# kubectl apply -f cronjob.yml cronjob.batch/hello created
等待几分钟，然后通过 kubectl get jobs 查看 Job 的执行情况：
通过AGE发现 每个job都比之前的多了 60s，正好符合我们的预期
使用 kubect get pods 和 kubectl logs 命令查看
5.小结
运行容器化应用是 Kubernetes 最重要的核心功能。为满足不同的业务需要，Kubernetes 提供了多种 Controller，包括 Deployment、DaemonSet、Job、CronJob 等。