Kubernetes的DaemonSet（下篇） - 编程一生
内容提要
本文介绍Kubernetes的DaemonSet：其Pod可通过推送、主机端口、headless service的DNS或Service方式通信；节点标签变化时自动增删Pod，1.6版本起支持滚动更新。相比初始化脚本、裸Pod和静态Pod，DaemonSet更便于管理守护进程并自动替换故障Pod；与Deployment不同，它确保每个节点运行一个Pod。
延伸解读
DaemonSet 的通信方式选择
文章列出了 DaemonSet 中 Pod 的四种通信方式：推送、主机端口、headless service 的 DNS 以及 Service。推送方式适合无客户端的场景，如上报状态；主机端口方式让客户端通过节点 IP 和约定端口访问；DNS 方式利用 headless service 探测终端资源；Service 方式则用于与任意节点的后台进程通信。读者可根据实际需求选择合适的方式。
节点标签变化与 Pod 管理
当节点标签发生变化时，DaemonSet 会迅速在匹配的新节点上添加 Pod，并从不再匹配的节点上删除 Pod。直接修改 DaemonSet 创建的 Pod 是允许的，但并非所有字段都可更新，且控制器会在下次创建节点时使用原始模板。删除 DaemonSet 时，若指定 --cascade=false，Pod 会保留在节点上，此时可用新模板创建 DaemonSet 来识别现有 Pod，但模板不匹配的 Pod 不会被修改或删除。
DaemonSet 与替代方案的比较
与初始化脚本相比，DaemonSet 能像管理应用一样监控守护进程，使用相同的配置语言和工具，并通过容器资源限制增强隔离性。与裸 Pod 相比，DaemonSet 能自动替换因节点故障或维护而停止的 Pod。静态 Pod 虽不依赖 apiserver，但无法被 kubectl 等客户端管理，且未来可能被废弃。与 Deployment 不同，DaemonSet 确保每个节点运行一个 Pod，适合守护进程或需优先启动的场景。
Q&A
DaemonSet中的Pod有哪些通信方式？
DaemonSet中的Pod可以通过以下方式通信：推的方式（Pod发送更新到状态数据库等服务）、IP+端口方式（使用主机端口，通过node IP访问）、DNS方式（创建headless service，通过DNS探测）、服务方式（创建Service与任意node的后台进程通信）。
DaemonSet如何响应节点标签变化？
当node标签被改变时，DaemonSet会迅速添加Pod到最新匹配的node上，并从不再匹配的node上删除Pod。
DaemonSet从哪个Kubernetes版本开始支持滚动更新？
从Kubernetes 1.6版本开始，DaemonSet支持滚动更新。
与初始化脚本相比，使用DaemonSet运行守护进程有什么好处？
使用DaemonSet可以像管理应用一样监控和管理守护进程，使用相同的配置语言和工具（如Pod templates、kubectl），并在容器中运行守护进程以增强隔离性。
DaemonSet和Deployment的主要区别是什么？
Deployment用于管理无状态服务，需要指定副本数并支持扩缩容和滚动升级；而DaemonSet确保每个节点（或指定节点）上运行一个Pod，通常用于守护进程或需要优先启动的场景。
删除DaemonSet时如何保留Pod？
使用kubectl删除DaemonSet时，如果指定--cascade=false，则Pod会保留在节点上。之后可以用不同的模板创建新的DaemonSet，当有匹配的标签出现时，新DaemonSet会识别已存在的Pod，但不会修改或删除不匹配的Pod。
