用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先启动的场景。
相关阅读
作者简介
作者是一个有美国硅谷、日本东京工作经验，十二年坚持一线写代码的程序媛。坚持原创文章。欢迎技术交流！