DaemonSet 在每个合格节点各起一个 Pod
Deployment 在意总数，DaemonSet 在意覆盖面：新节点一进池子，同一个服务立刻就在那里。节点级关切——发日志、暴露硬件指标、跑网络 fabric、执行策略——必须处处有，不然等于处处没有。用逐节点脚本或每个 Pod 塞 sidecar 去凑合，立刻就烂：新节点漏掉、版本漂移，没人答得出"哪些节点跑着 agent"而不审计。 DaemonSet 控制器用声明式覆盖弥合这个缝。你把守护进程描述一次，控制器永远把现实收敛到每合格节点一个 Pod，扩集群自动扩守护舰队。覆盖从 runbook 条目变成系统维护的不变量。 每节点一个、天生如此 你把守护进程描述一次，控制器就给每个节点都挂一份副本，这正是节点级日志、指标 agent 与 kube-proxy 这类流量的天然归属。没有需要手工调大小的伸缩旋钮。没有旋钮是特性：副本数一经手压就会从意图漂走，而"每合格节点一个"不会漂——它按节点列表持续重算。新节点注册时 gain Pod，离场释放，被 cordon 的除非 drain 都留着。 因为放置按节点不按容量，DaemonSet Pod 一般要优先级和抢占 headroom，才能在满节点上活下来。给高 PriorityClass、诚实而克制的资源 requests：节点再满它们也必须调度上去，因为过载节点上缺席的监控 agent，恰在最需要 visibility 时致盲。没有需要手工调大小的伸缩旋钮，但调度要做对。 覆盖优先于数量 因为期望副本数本就隐含，一次滚动更新会触及每个成员：往池子里加一个节点，守护进程不用额外动作就自动出现。这是任何逐节点脚本都拼不过的保证。更新用 maxUnavailable 限 disruption 在舰队铺开——设 1 就逐节点刷新，舰队永不断覆盖。节点脚本的慢性病版本漂移，在结构上不可能：控制器把每节点收敛到同一模板，kubectl rollout status ds/agent 告诉你收敛何时完成。 ...