用Daemon Pod來進行通訊
使用Pod來再DaemonSet中通訊的手段有：
-
推的方式:在DaemonSet中的Pod會被配置成傳送更新到如狀態資料庫這樣的服務。這些都沒有客戶端。
-
IP+埠方式：DaemonSet中的Pod可以使用主機埠。因此通過node的IP就可以訪問。客戶端知道了node的IP，就可以用實現約定配置好的埠進行通訊了。
-
DNS方式：用同樣的Pod選擇器建立一個headless service，可以通過DNS使用終端資源或者獲取資料的方式來探測DaemonSets。
-
服務方式：用同樣的Pod選擇器來建立一個服務，使用這個服務來與任意一個node的後臺程式通訊。
更新一個DaemonSet
node標籤一旦被改變，DaemonSet會迅速的新增Pod到最新匹配的node上，並且從最新不匹配的node上刪除Pod。
修改DaemonSet建立的Pod是可以修改的。但是Pod不允許所有的欄位都被更新。而且，DaemonSet控制器會使用原來的模板進行下一次的node建立。
DaemonSet也是可以刪除的。如果用kubectl指定了--cascade=false，那Pod就會留在node上。可以用一個不同的模板建立一個新的DaemonSet。當有匹配的標籤出現時，可以用不同模板生成的新的DaemonSet來識別出所有已經存在的Pods。如果Pod模板不匹配，則不會修改或者刪除Pod。
在Kuberntes版本1.6或以後，可以使用DaemonSet的滾動更新。
DaemonSet的可選項
初始化指令碼
直接在node上執行守護程式肯定是可以的（比如使用init,upstartd或者systemd方式來啟動）。但是如果使用DaemonSet會有很多好處。
-
像管理應用一樣監控和管理守護程式。
-
與應用使用相同的配置語言和工具(如Pod templates，Kubectl)
-
在container裡使用資源限制執行守護程式增強了守護執行緒和app容器的隔離性。然而，這個也可以通過在container而不是pod裡執行daemon程式完成。
裸Pod
直接指定node來建立Pod是可以實現的。但是DaemonSet可以自動替換由於任何原因被刪除的或者停止的Pod，以防止node掛了或者其他型別的node維護，比如kernel升級。
靜態Pod
通過在被Kubelet監聽的目錄下建立檔案的方式生成Pod是可以實現的，它們被稱為靜態Pod。不像DaemonSet，靜態Pod不能被kubectl或者其他K9s API客戶端管理。靜態Pod不依賴apiserver。一般是叢集啟動時候用到的。在後續的版本中，靜態Pod可能被廢棄。
Deployment
DaemonSet與Deployment的相同點是他們都用於建立Pod，這些Pod是不期望被意外停止的。
使用Deployment可以管理無狀態服務，如前端服務，它需要擴容和縮容指定的副本數，還可以滾動升級。而使用DaemonSet最重要的是產生一個Pod一直執行在指定的或者全部的宿主機上，或者是需要比其他的Pod先啟動的場景。
相關閱讀
作者簡介
作者是一個有美國矽谷、日本東京工作經驗，十二年堅持一線寫程式碼的程式媛。堅持原創文章。歡迎技術交流！
