ASP.NET Core on K8S深入學習（3-2）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           

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