DaemonSet 确保每个节点运行一个 Pod，适合集群级守护进程；Deployment 管理无状态副本应用，适合水平扩展的微服务。 这是 Kubernetes 里最常见的两种控制器，但很多人刚接触时容易混淆各自该管什么，一个负责“每节点一个”，一个保证“指定副本数”，背后承载的负载类型完全不同，下面拆开细说，帮你彻底分清它们分别适合干什么,以及怎么根据业务场景做选择。
DaemonSet 和 Deployment 的核心区别
两种控制器的设计起点就不同,这决定了它们各自擅长的领域。
设计理念不同
DaemonSet 的核心理念是“每个节点运行一个副本”，你声明一个 DaemonSet，Kubernetes 就会保证集群中新增节点时自动启动 Pod，删除节点时自动回收 Pod，它不关心副本总数，只关心节点覆盖率，Deployment 则相反，它管理一个固定副本数的 Pod 集合，通过 ReplicaSet 确保指定数量的 Pod 始终运行，并支持滚动更新、回滚等操作。
调度方式不同
DaemonSet 默认将 Pod 调度到所有节点，但你可以通过 nodeSelector 或亲和性规则限制运行范围，Deployment 的 Pod 由调度器根据资源、策略分配到合适节点，可能部分节点没有 Pod，部分节点有多个，完全由调度器决定，这种差异导致 DaemonSet 适合那些必须每个节点都出现的组件，比如日志采集、监控采集器或网络代理。
更新策略比较
Deployment 提供丰富的更新策略，包括滚动更新、蓝绿部署、金丝雀发布，支持暂停和恢复，DaemonSet 的更新策略相对简单，主要支持滚动更新和 OnDelete 模式，但也能满足守护进程类的升级需求，在回滚方面，Deployment 有完整的版本记录和回滚能力，DaemonSet 同样支持回滚,但更侧重节点级更新的稳定性。
DaemonSet 适合承载什么负载？
DaemonSet 适合的场景非常明确：凡是需要在集群中每个节点（或特定节点）上运行一个副本的守护进程，都应该用 DaemonSet。
节点级基础设施守护进程
这类组件负责节点的底层能力，比如文件系统挂载、网络策略实施、设备管理，典型例子是存储插件（如 Ceph 的 csi-node 或 GlusterFS 客户端）和设备管理 Daemon（如 FPGA 驱动），这些组件必须和节点一一对应，不能用 Deployment 来管理，因为 Deployment 无法保证每个节点一个 Pod,节点数量变化时也不会自动扩展。
日志采集与监控
日志采集是 DaemonSet 最经典的用法，每个节点上运行一个日志采集代理（如 Fluentd、Logstash、Filebeat），直接从节点文件系统拉取容器日志，传输到中央存储，监控类似，Prometheus Node Exporter 通常也以 DaemonSet 部署，确保每个节点暴露指标，行业共识认为，这种每节点一个采集器的模式比 Deployment 集中部署更可靠，因为不会出现单点故障,且节点扩容时自动补齐。
网络插件与安全代理
很多 CNI 网络插件（如 Calico、Flannel、Weave）都通过 DaemonSet 在节点上运行网络代理或路由组件，安全策略控制器（如 Cilium 的 Agent）也常以 DaemonSet 运行，确保每个节点都能执行网络策略，这些组件对节点亲和性要求高，不能容忍某些节点缺失，Deployment 无法保证这种覆盖度。
在实际部署中，你可以通过 nodeSelector 让 DaemonSet 只运行在特定节点上，比如只部署在 GPU 节点上的监控采集器，这样既保持了 DaemonSet 的“每节点”特性,又实现了灵活控制。
Deployment 适合承载什么负载？
Deployment 是无状态应用的标配，也是大多数微服务的选择，它关注副本数、滚动更新和高可用，适合那些可以任意调度、不依赖特定节点的业务容器。
无状态 Web 应用与 API 服务
Web 服务器、REST API、前端应用这些典型无状态负载，用 Deployment 管理最合适，你可以设置副本数为 3，Kubernetes 会保证始终有 3 个 Pod 运行，即使节点故障也会在其他节点重建。滚动更新让新版本逐步替换旧版本，零停机发布，如果业务流量波动，还可以配合 HPA 自动扩缩副本数，Deployment 会自动调整 ReplicaSet 的副本数。
微服务架构下的业务容器
在微服务中，每个服务独立部署，彼此不共享状态，Deployment 管理这些服务实例，支持多版本并行、灰度发布，比如支付服务需要 5 个副本，Deployment 会确保 5 个 Pod 分布在不同节点，避免单点故障，你可以通过配置 strategy 字段控制更新行为，maxSurge 和 maxUnavailable 来平衡可用性和更新速度。
需要精细更新与回滚的场景
当你的应用需要频繁更新，且要求快速回滚时，Deployment 是首选，它保留历史版本，你可以通过
kubectl rollout undo 随时回退到任意版本，DaemonSet 虽然也支持回滚，但版本管理不如 Deployment 灵活，对于业务应用，回滚是家常便饭，Deployment 的版本记录机制更成熟。
DaemonSet 和 Deployment 选型对比：场景与性能
很多人在设计 Kubernetes 集群时纠结“日志采集到底用 DaemonSet 还是 Deployment”，其实两者在资源占用、高可用和更新策略上有明显差异。
资源需求与节点亲和性
DaemonSet 适合对节点资源有固定需求且必须每个节点一个的场景，比如监控采集器消耗的资源相对固定，每个节点一个 Pod 不会造成过大开销，而 Deployment 的副本数根据业务负载调整，适合资源消耗波动大的应用，如果你在超大规模集群（比如上千节点）中部署 DaemonSet，要注意资源总量,避免守护进程占用过多节点资源。
高可用与副本分布
DaemonSet 的高可用依赖节点本身的高可用，因为每个节点上只有一个 Pod，节点故障时 Pod 不会在其他节点重建（因为 DaemonSet 认为该节点不存在），Deployment 则可以将副本分散到多个节点，即使部分节点故障，其他节点上的 Pod 仍能提供服务，并通过自动重建恢复副本数，对于关键业务，Deployment 的高可用性更优。
更新与回滚差异
DaemonSet 的更新是节点级别的，默认逐个节点更新，不会同时中断多个节点上的服务，Deployment 的更新是副本级别的，可以控制一次替换多少个 Pod，在回滚速度上，Deployment 的版本记录更详细，可以快速回退到任意版本，DaemonSet 的回滚需要手动指定版本，且版本数量有限，如果你需要频繁灰度发布，Deployment 更灵活。
如何选择：DaemonSet 还是 Deployment？
当你面对一个负载时，先问自己两个问题：这个组件是否需要每个节点都运行？ 如果答案是“是”，就选 DaemonSet，如果答案是“否”，再问：这个组件是无状态的，并且需要水平扩展吗？ 如果是，就选 Deployment。
判断负载类型
- 守护进程类：日志采集、监控采集、网络代理、存储插件、安全 Agent → DaemonSet
- 无状态应用类：Web 服务、API 服务、微服务业务容器、批处理任务 → Deployment
- 有状态应用类：需要持久化存储、固定网络标识的 → 通常用 StatefulSet，但某些场景下 DaemonSet 也可用于单节点数据库（不推荐）
集群规模与节点管理
在小型集群（几个节点）中，Deployment 和 DaemonSet 的差异不明显，但节点增多后，DaemonSet 的 Pod 数量会随节点线性增长，这时要注意资源预留，如果你使用按节点计费的云服务（比如某些地域的云主机价格较高），DaemonSet 的守护进程成本会随着节点数增加而增加，而 Deployment 的副本数可以独立控制，在成本敏感场景下，可以考虑将某些采集器从 DaemonSet 改为 Deployment 并合理调度,但这样会牺牲节点覆盖度。
Q&A: DaemonSet 和 Deployment 常见问题
DaemonSet 可以部署有状态应用吗？
理论上可以，但很少这么做，DaemonSet 保证每个节点一个 Pod，但 Pod 的存储和网络标识不固定，节点故障时 Pod 不会在其他节点重新创建，不利于有状态服务的持久化，如果需要在每个节点运行一个数据库实例，通常会使用 StatefulSet 配合节点亲和性，而不是 DaemonSet。
日志采集用 DaemonSet 还是 Deployment？
绝大多数情况下用 DaemonSet，因为日志采集需要从每个节点收集文件，DaemonSet 天然满足“每节点一个”的需求，如果使用 Deployment，你需要手动调度 Pod 到每个节点，节点扩容时还需要手动调整副本数，非常麻烦，行业共识认为，DaemonSet 是日志采集的唯一合理选择，对于少量节点的测试环境，Deployment 配合节点亲和性也能临时用,但生产环境不推荐。
同时使用 DaemonSet 和 Deployment 需要注意什么？
两者可以共存，但要注意资源冲突，DaemonSet 运行的守护进程可能占用节点端口或资源，需要为 Deployment 的 Pod 预留足够资源，DaemonSet 的更新策略可能影响节点上 Deployment Pod 的运行（比如网络代理更新时短暂断网），建议在维护窗口期操作，在集群规划时，建议将 DaemonSet 的 Pod 资源请求设置得较低,避免挤压业务容器的资源。
<|start|>DaemonSet 和 Deployment 各司其职，前者守护节点，后者服务业务。选型时记住：每节点一个的用 DaemonSet，水平扩展多副本的用 Deployment。 把这两个概念理清，Kubernetes 的负载管理就不再容易混淆了。