Kubernetes的DaemonSet（下篇）

用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先启动的场景。

相关阅读

《两地书》--K8s基础知识

Kubernetes的污点和容忍（上篇）

Kubernetes的污点和容忍（下篇）

Kubernetes的DaemonSet（上篇）

作者简介

作者是一个有美国硅谷、日本东京工作经验，十二年坚持一线写代码的程序媛。坚持原创文章。欢迎技术交流！