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

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

一、DaemonSet

1.1 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

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

1.3 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 apply -f node-exporter.yaml

　　然後，通過kubectl檢視Pod分佈情況：

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

二、Job

2.1 關於Job

　　對於ReplicaSet、Deployment、DaemonSet等型別的控制器而言，它希望Pod保持預期數目並且持久執行下去，除非使用者明確刪除，否則這些物件一直存在，因此可以說他們說持久服務型任務的。

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

2.2 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總數，還是上面的例子：

apiVersion: batch/v1
kind: Job
metadata:
  name: edc-job-hello-job
  namespace: jobs
spec:
  parallelism: 3
  completions: 6
  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。

2.3 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，符合預期。

三、小結

　　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

本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段宣告，且在文章頁面明顯位置給出原文連結。