本篇已加入《.NET Core on K8S学习实践系列文章索引》，可以点击查看更多容器化技术相关系列文章。

上一篇《3-1 Deployment》中介绍了Deployment，它可以满足我们大部分时候的应用部署（无状态服务类容器），但是针对一些特殊的场景应用例如守护进程或者离线业务，就可以用到今天介绍的DaemonSet和Job。

一、DaemonSet

　　Deployment的部署可以指定副本Pod分布在多个Node节点上，且每个Node都可以运行多个Pod副本。而DaemonSet呢，它倔强地保证在每个Node上都只运行一个Pod副本。

　　回想一下项目经历，有哪些场景满足这个特质呢？是不是一些集群的日志、监控或者其他系统管理应用？

• 日志收集，比如fluentd，logstash等

• 系统监控，比如Prometheus Node Exporter，collectd，New Relic agent，Ganglia gmond等

• 系统程序，比如kube-proxy，kube-dns，glusterd，ceph等

  　　

Prometheus Node Exporter Dashboard

　　在K8S中，就有一些默认的使用DaemonSet方式运行的系统组件，比如我们可以通过下面一句命令查看：

kubectl get daemonset --namespace=kube-system

　　

　　可以看到，kube-flannel-ds 和 kube-proxy 是K8S以DaemonSet方式运行的系统组件，分别为K8S集群负责提供网络连接支持和代理支持，这里不深入讨论它们的详细情况，只需要了解它们负责什么就可以了。在通过查看Pod副本，看看各个节点的分布情况：

kubectl get pod --namespace=kube-system -o wide

　　

　　可以看到，它们两分布在各个Node节点上（这里是我的K8S集群中的所有节点了），且每个节点上只有一个Pod副本。

　　同之前的创建资源方式一样，仍然采用通过YAML配置文件的方式进行创建，只需要指定kind: DaemonSet即可：

apiVersion: apps/v1
kind: DaemonSet

　　这里我们以Prometheus Node Exporter为例演示一下如何运行我们自己的DaemonSet。

_PS：_Prometheus是流行的系统监控方案，而Node Exporter负责收集节点上的metrics监控数据，并将数据推送给Prometheus。Prometheus则负责存储这些数据，Grafana最终将这些数据通过网页以图形的形式展现给用户。

　　下面是yaml配置文件对于DaemonSet资源清单的定义：

apiVersion: apps/v1
kind: DaemonSet
metadata:
name: node-exporter-daemonset
namespace: agent
spec:
selector:
matchLabels:
app: prometheus
template:
metadata:
labels:
app: prometheus
spec:
hostNetwork: true
containers:
- name: node-exporter
image: prom/node-exporter
imagePullPolicy: IfNotPresent
command:
- /bin/node_exporter
- --path.procfs
- /host/proc
- --path.sysfs
- /host/sys
- --collector.filesystem.ignored-mount-points
- ^/(sys|proc|dev|host|etc)($|/)
volumeMounts:
- name: proc
mountPath: /host/proc
- name: sys
mountPath: /host/sys
- name: root
mountPath: /rootfs
volumes:
- name: proc
hostPath:
path: /proc
- name: sys
hostPath:
path: /sys
- name: root
hostPath:
path: /

　　这里暂且不纠结其中的配置内容，包括Host网络、容器启动命令以及Volume，后面会专题介绍。

　　同样，通过kubectl创建资源：

kubectl apply -f node-exporter.yaml

　　然后，通过kubectl查看Pod分布情况：

　　

　　可以看出，我们的Prometheus Node Exporter部署成功，且分别在两个Node节点都只部署了一个Pod副本。

二、Job

　　对于ReplicaSet、Deployment、DaemonSet等类型的控制器而言，它希望Pod保持预期数目并且持久运行下去，除非用户明确删除，否则这些对象一直存在，因此可以说他们说持久服务型任务的。

　　

　　对于非耐久性任务，比如压缩文件，任务完成后，Pod需要结束运行，不需要Ppod继续保持在系统中，这个时候就要用到Job。因此也可以说，Job是对ReplicaSet、Deployment、DaemonSet等持久性控制器的补充。

　　同之前的创建资源方式一样，仍然采用通过YAML配置文件的方式进行创建，需要指定apiVersioin: batch 以及 kind: Job即可：

apiVersion: batch/v1

kind: Job

　　（1）第一个Job

　　这里我们以一个简单的小Job为例，看看一个简单的Job：当Job启动后，只运行一个Pod，Pod运行结束后整个Job也就立刻结束。

apiVersion: batch/v1
kind: Job
metadata:
name: edc-job-hello-job
namespace: jobs
spec:
template:
metadata:
labels:
app: edc-job-hello-job
spec:
containers:
- name: hello-job
image: busybox
imagePullPolicy: IfNotPresent
command: ["echo", "hello edison's k8s job!"]
restartPolicy: Never

　　这里需要注意的是，对Job而言，其restartPolicy只能为Never或者OnFailure，这也是它与其他控制器的差别（如Deployment控制器还允许设置为Always）。这个Job要执行的任务也很简单，就是输出一段话“hello edison's k8s job!”就结束其生命了。

PS：这里用到了一个busybox的镜像，busybox是一个软件工具箱，里边集成了Linux中几百个常用的Linux命令以及工具。如果我们只需要一个小型的Linux运行环境跑命令，完全可以使用这个busybox镜像，而不用拉取一个CentOS镜像。

　　通过查看Job运行情况可以知道，其运行结束就结束了，如下图所示，变成了Completed状态。

kubectl get pod -n jobs

　　

　　还可以通过查看Log看看这个Job留下的足迹：

kubectl get pod -n jobs --show-all
kubectl logs edc-job-hello-job-whcts

　　

　　（2）并行Job

　　如果希望能够同时并行运行多个Pod以提高Job的执行效率，Job提供了一个贴心的配置：parallesim。例如下面的配置，我们将上面的小Job改为并行运行的Pod数量设置为3。

apiVersion: batch/v1
kind: Job
metadata:
name: edc-job-hello-job
namespace: jobs
spec:
parallelism:
template:
metadata:
labels:
app: edc-job-hello-job
spec:
containers:
- name: hello-job
image: busybox
imagePullPolicy: IfNotPresent
command: ["echo", "hello edison's k8s job!"]
restartPolicy: OnFailure

PS：默认parallelism值为1

　　使用上面的配置文件创建了资源后，通过以下命令查看验证：

kubectl get job -n jobs
kubectl get pod -o wide -n jobs

　　

　　可以看出，Job一共启动了3个Pod，都是同时结束的（可以看到三个Pod的AGE都是相同的）。

　　此外，Job还提供了一个completions属性使我们可以设置Job完成的Pod总数，还是上面的例子：

apiVersion: batch/v1
kind: Job
metadata:
name: edc-job-hello-job
namespace: jobs
spec:
parallelism: completions:
template:
metadata:
labels:
app: edc-job-hello-job
spec:
containers:
- name: hello-job
image: busybox
imagePullPolicy: IfNotPresent
command: ["echo", "hello edison's k8s job!"]
restartPolicy: OnFailure

PS：默认completions也为1

　　上面的配置意思就是：每次运行3个Pod，直到总共有6个Pod就算成功完成。同样通过命令验证一下：

　　

　　可以看到，状态和AGE都符合预期，第一批3个Pod的AGE为12s，第二批3个Pod的AGE为14s。

　　我们都知道在Linux中，Cron程序可以定时执行任务，而在K8S中也提供了一个CronJob帮助我们实现定时任务。

　　继续以上面的例子，我们增加一些配置：

apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: edc-cron-job
namespace: jobs
spec:
schedule: "*/1 * * * *" jobTemplate:
spec:
template:
spec:
containers:
- name: cron-job
image: busybox
imagePullPolicy: IfNotPresent
command: ["echo", "hello edison's k8s cron job!"]
restartPolicy: OnFailure

　　上面加粗的配置是CronJob的独有配置，需要注意的是schedule，它的格式和Linux Cron一样，这里的"*/1 * * * *"代表每一分钟启动执行一次。对于CronJob，它需要的是jobTemplate来定义Job的模板。

　　同样，隔几分钟之后，通过命令来验证一下：

　　

　　可以看到，在过去的三分钟里，每一分钟都启动了一个Pod，符合预期。

三、小结

　　Deployment可以满足我们大部分时候的应用部署（无状态服务类容器），但是针对一些特殊的场景应用，Deployment就无法胜任了。比如日志收集、系统监控等场景，就可以使用今天介绍的DaemonSet。又比如批处理定时任务，则可以使用今天介绍的Job/CronJob。

参考资料

（1）CloudMan，《每天5分钟玩转Kubernetes》

（2）李振良，《一天入门Kubernets教程》

（3）马哥（马永亮），《Kubernetes快速入门》

（4）阿龙，《Kubernetes系列-07.Pod控制器详解》

（5）elvis，《K8S-Job与CronJob的使用》

（6）五星上炕，《Kubernetes之Job详解》

作者：周旭龙

出处：https://edisonchou.cnblogs.com

本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文链接。