那些只要有 Node 我就想在上面先跑一個的 Pod (⁎⁍̴̛ᴗ⁍̴̛⁎)

服務部署上去，就結束了嗎？

怎麼可能！如果是開發或 SRE 相關領域，一定會立刻想到的事情一定是：
我可以怎麼監控這套系統？
又要怎麼確保所有的 Pod 都在監控之下？

這時候就該 DaemonSet 上場啦～

DaemonSet

• 定義：
  DaemonSet 確保所有 Node 上都運行一個的 Pod
  （ 說所有不太精確，其實可以添加判斷條件去篩選需要被部署指定 Pod 的 Node）
• 主要用途：
  • Cluster storage daemon
  • Logs collection daemon
  • Monitoring daemon
  • kube-proxy
• 執行機制：
  當 Cluster 新加入一個 Node，DaemonSet 就會自動將設定的 Pod 部署上去。而當 Node 從 Cluster 被移除，這些 Pod 同樣會被回收。

如果刪除 DaemonSet，這些 Pod 也會一併被刪除。

篩選方式：
可用的條件參數依 Kubernetes 版本而有所不同。

• v1.2前：主要依賴 nodeName，不過就像 nodeAffinity提過的，這樣繞過 Scheduler 決策，直接部署到指定 Node 的方式缺乏靈活性，而且要篩選就必須對每個要規範的 Node 做各別設定，對管理者來說也是種負擔。
• v1.2：支援 nodeSelector，可以使用標籤 (label) 作為判斷條件。較為有彈性但只 Label 只能處理 AND 邏輯。
• v1.6：引入了 nodeAffinity，提供了強大的篩選機制。

DaemonSet 定義的 Pod，是誰部署的？

是 DaemonSet 還是 Scheduler？
這個疑問來自於在學習 Scheduler 的時候，從使用者發起 Request 到各組件通力合作完成部署，有完整的執行流程。不管 Pod 是使用者直接使用指令建立，或是透過 Deployment 管理，都有明確的執行方式，那 DaemonSet 呢？

DaemonSet 定義的 Pod 是由 DaemonSet Controller 發起建立的。

DaemonSet Controller

Control Plane 上的組件之一。它會持續監控 Cluster 中的 Node，一旦有新的 Node 出現，就會執行DaemonSet Pod的部署。
（當然刪除 DaemonSet 也是由 DaemonSet Controller 執行回收）

長得很像，但實際上跟 Scheduler 不同。
最明顯的差異是：它沒有 Queue， DaemonSet Controller 是並行處理的。
與其他的 Pod 不同，DaemonSet 只專注在每個符合條件的 Node 上維護一個 Pod，不需要管理多個副本也不需要進行批次操作。

決策方式也不太相同，不同版本的 Kubernetes，其中 DaemonSet 的決策方式也有所變動。
在 v1.2 以前，還只有nodeName作為判斷條件的時候，Pod 是有 DaemonSet 直接指派的。但在 v1.12 以後，DaemonSet 引入了新的設定參數 ScheduleDaemonSetPods。
啟用 ScheduleDaemonSetPods 特性時，Scheduler 就會參與到 DaemonSet Pod 的調度過程。

沒有對應到的 Node 怎麼辦？

DaemonSet Controller 的責任是確保 符合條件的 Node 上面要有這個 Pod，不符合當然就不用啦～
沒有就沒有囉 ╮(￣▽￣ )╭

那不啟用 ScheduleDaemonSetPods 的話還可以使用複雜的篩選條件嗎？ （如： nodeAffinity）

沒有直接關係喔！
其實一開始的設計，所有的 DaemonSet Pod 都是由 DaemonSet Controller 負責調度的 （不管使用哪種篩選條件）。
不過在 v1.12 引入ScheduleDaemonSetPods之後，藉由讓 Scheduler 完成調度，可以讓 DaemonSet Pod 無痛升級直接使用 Scheduler 的各種調度機制，非常方便！而且在比較新的 Kubernetes 版本中， ScheduleDaemonSetPods 也是預設為啟用的喔！

設定方式：

apiVersion: apps/v1 
kind: DaemonSet 
metadata: 
  name: monitoring-daemon 
spec: 
  selector: 
    matchLabels: 
      app: monitoring-agent 
  template: # pod template 
    metadata: 
      labels:
	    app: monitoring-agent 
    spec: 
      containers: 
	    - name: monitoring-agent 
          image: <monitoring-image>

建置指令

kubectl apply -f <daemonset.yaml>

最後補充一些會透過 DaemonSet 配置的資源：

1. 網路相關套件：
   • Calico
   • Flannel
   • Weave Net
2. Log 收集：
   • Fluentd
   • Logstash
   • Filebeat
3. 監控代理：
   • Prometheus Node Exporter
   • Datadog Agent
   • New Relic Infrastructure Agent
4. 存儲解決方案：
   • Ceph
   • GlusterFS
5. 安全和合規性：
   • Falco（運行安全）
   • Sysdig（系統可見性）
6. Load Balancer：
   • MetalLB
7. Service Mesh Proxy：
   • Istio 的 Envoy Proxy
   • Linkerd Proxy
8. Node 問題檢測：
   • Node Problem Detector

小結

DaemonSet 的應用場景十分明確，雖說只是在 Node 上運行一個 Pod 直接使用 kind: Pod 的 yaml 檔也可以做到，但沒有 DaemonSet Controller 進行管理，一旦因為 Node 維護或升級而被終止，它就再也回不來了。

另外一個很常跟 DaemonSet 一併討論的是 Static Pod。
它是透過直接修改 kubelet 的讀取資源達成相同的效果。
在 Kubernetes 中，有一個專用來放置運行組件 yaml 的資料夾：

/etc/kubernetes/manifests

Static Pod 就是透過直接將想建立的 Pod 以 yaml 設定的格式直接加在這個資料夾中，讓 Kubernetes 直接在 Node 上做建置。

對，它不透過 kube-apiserver。
所有的流程都會在單一個 Node 上完成。

好處是這個設定方式不受 Cluster 中其他組件或資源的影響，只要 Node 成功建立 Static Pod 就會一併建置，不過依照官方文件敘述，Static Pod 為來可能會被棄用，在使用上還是要斟酌。