Kubernetes的DaemonSet（上篇） - 编程一生
内容提要
Kubernetes DaemonSet 确保每个节点运行一个 Pod 实例，节点加入或移除时自动增删 Pod，删除 DaemonSet 会清理其 Pod。典型用途包括节点存储、日志收集和监控代理。文中给出 fluentd-elasticsearch 的 YAML 示例，并说明 spec 必需字段、Pod 模板、选择器、nodeSelector 与 affinity，以及调度方式从 DaemonSet 控制器改为默认调度器，并支持污点与容忍。
延伸解读
DaemonSet 的典型应用场景
DaemonSet 确保每个节点运行一个 Pod 实例，适合部署节点级别的守护进程。例如，在每个节点上运行存储守护进程（如 glusterd、ceph）、日志收集组件（如 fluentd、logstash）或监控代理（如 Prometheus Node Exporter）。这些进程需要覆盖所有节点，DaemonSet 能自动管理 Pod 的生命周期，节点加入或移除时同步增删 Pod。
Pod 模板与选择器的关键约束
DaemonSet 的 Pod 模板必须指定合适的标签，且 .spec.selector 必须与模板标签匹配，否则 API 会拒绝。选择器一旦创建便不可更改，修改可能导致 Pod 成为“孤岛”。此外，Pod 模板的 RestartPolicy 必须为 Always，否则配置无效。这些约束保证了 DaemonSet 对 Pod 的准确管理。
调度机制的演进与影响
早期 DaemonSet 控制器直接指定 Pod 的 nodeName 来调度，忽略节点的 unschedulable 字段，且 Pod 初始状态不是 Pending，与普通 Pod 行为不一致。从 1.12 版本开始，默认调度器接管调度，通过添加 nodeAffinity 而非 nodeName 来绑定节点，使 DaemonSet Pod 支持优先级抢占等调度特性，行为更一致。
污点与容忍的自动处理
DaemonSet 创建的 Pod 支持污点和容忍。根据节点特性，系统会自动为 DaemonSet Pod 添加相应的容忍，例如容忍 master 节点的 NoSchedule 污点，确保 Pod 能调度到所有符合条件的节点。这简化了在混合节点集群中部署守护进程的配置。
Q&A
DaemonSet 在 Kubernetes 中有什么作用？
DaemonSet 确保所有（或部分）节点上运行一个 Pod 的副本。当节点加入集群时，Pod 会被自动添加；当节点移除时，Pod 会被垃圾回收。删除 DaemonSet 会清理它创建的所有 Pod。
DaemonSet 通常用在哪些场景？
典型用法包括：在每个节点上运行集群存储守护进程（如 glusterd、ceph）、日志收集进程（如 fluentd、logstash）、节点监控代理（如 Prometheus Node Exporter、collectd、Datadog agent 等）。
DaemonSet 的 YAML 配置中哪些字段是必需的？
DaemonSet 需要 apiVersion、kind 和 metadata 字段，以及 spec 区。spec 中必须包含 .spec.template（Pod 模板）和 .spec.selector（Pod 选择器）。Pod 模板中必须指定合适的 label，且 RestartPolicy 必须为 Always（默认即为 Always）。
如何指定 DaemonSet 的 Pod 只在特定节点上运行？
可以通过 .spec.template.spec.nodeSelector 指定节点选择器，或通过 .spec.template.spec.affinity 指定节点亲和性。如果两者都不指定，DaemonSet 控制器会在所有节点上创建 Pod。
DaemonSet 的 Pod 是如何被调度的？
在 Kubernetes 1.12 之前，DaemonSet 控制器负责调度，Pod 创建时已指定 .spec.nodeName，调度器会忽略。从 1.12 开始，默认使用默认调度器调度，通过添加 nodeAffinity 而不是 .spec.nodeName 来实现，这样 Pod 会以 Pending 状态创建并等待调度，同时支持 Pod 优先权等特性。
DaemonSet 如何处理污点和容忍？
DaemonSet 的 Pod 支持污点和容忍。根据特定特性，一些容忍会被自动添加到 DaemonSet 的 Pod 中，例如容忍 node-role.kubernetes.io/master 的 NoSchedule 污点。
