本篇已加入《.NET Core on K8S學習實踐系列文章索引》，可以點擊查看更多容器化技術相關系列文章。

上一篇《3-1 Deployment》中介紹了Deployment，它可以滿足我們大部分時候的應用部署（無狀態服務類容器），但是針對一些特殊的場景應用，就可以用到今天介紹的DaemonSet和Job。

本文預計閱讀時間為10分鐘。

01

—

DaemonSet

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

在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副本。

DaemonSet的創建與運行

同之前的創建資源方式一樣，仍然采用通過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查看Pod分布情況：

　　

?　　可以看出，我們的Prometheus Node Exporter部署成功，且分別在兩個Node節點都只部署了一個Pod副本。

02

—

Job

關于Job

對于ReplicaSet、Deployment、DaemonSet等類型的控制器而言，它希望Pod保持預期數目并且持久運行下去，除非用戶明確刪除，否則這些對象一直存在，因此可以說他們說持久服務型任務的。

　　對于非耐久性任務，比如壓縮文件，任務完成后，Pod需要結束運行，不需要Ppod繼續保持在系統中，這個時候就要用到Job。因此也可以說，Job是對ReplicaSet、Deployment、DaemonSet等持久性控制器的補充。

Job的創建與運行

同之前的創建資源方式一樣，仍然采用通過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: 3 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總數，還是上面的例子：

PS：默認completions也為1

　　上面的配置意思就是：每次運行3個Pod，直到總共有6個Pod就算成功完成。同樣通過命令驗證一下：

　　

?　　可以看到，狀態和AGE都符合預期，第一批3個Pod的AGE為12s，第二批3個Pod的AGE為14s。

CronJob的創建與運行

我們都知道在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，符合預期。

03

—

小結

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詳解》

---

恰童鞋騷年，風華不再正茂，仍想揮斥方遒

點個在看少個bug??

總結

以上是生活随笔為你收集整理的ASP.NET Core on K8S深入学习（3-2）DaemonSet与Job的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。