DaemonSet滚动更新中PDB为何无法保护监控数据？

DaemonSet 滚动更新导致监控数据出现空窗时，很多运维的第一反应是"加 PDB"，但这是典型的错误归因。核心原因在于 API 路径的差异：PodDisruptionBudget 只对 eviction API 生效，而 DaemonSet 控制器执行 RollingUpdate 删除旧 Pod 走的是标准 DELETE API，完全绕过 PDB 的检查逻辑。无论 disruptionsAllowed 是 0 还是 1，PDB 都无法约束控制器的删除行为，监控空窗与该字段没有任何因果关系。

PDB 的真实作用域

PDB 的设计目标是约束驱逐类操作，典型场景是 kubectl drain 节点维护。驱逐请求经过 eviction API 时会被 PDB 拦截，disruptionsAllowed: 0 时阻塞驱逐。但 RollingUpdate 不在此列，控制器直接发出 DELETE 请求，PDB 的状态字段此时仅供参考，不具备阻断能力。更危险的是认知层面的误区：团队误以为配置了 PDB 就等于上了保险，从而忽略单 Pod 优雅退出的配置缺陷，导致监控断点在每次更新时重复出现。

真正的保护点在哪

既然 PDB 管不到 DELETE 路径，监控连续性的责任就落在四个层面：Pod 层的 terminationGracePeriodSeconds 与 preStop hook 是否给进程留足连接排空、缓冲刷盘的时间；CRI 层容器内 PID 1 是否为真实业务进程、SIGTERM 能否正确送达；Node 层监控类 DaemonSet 是否配置了 system-node-critical 级别的高优先级，避免节点资源压力时被优先驱逐；集群层则需接受 RollingUpdate 的固有行为，用 maxUnavailable: 1 控制并发终止的影响面。

收尾建议

对安全团队而言，几十秒的指标空窗意味着入侵检测盲区、up==0 告警风暴和合规审计缺口。务实的做法是确保采集进程注册 SIGTERM 处理器并在退出前完成最后一次指标推送，terminationGracePeriodSeconds 提升至 60 秒并配合 preStop 延迟 10–15 秒，Prometheus 告警规则加入 for: 2m 抑制滚动更新噪声。PDB 应留给它真正能保护的场景——节点驱逐，而不是滚动更新。