K8s监控采集端优雅终止的配置检查清单

家里监控摄像头重启几秒钟，小偷正好挑这个空档进门——K8s 集群里滚动更新监控采集端，出的就是这种事。DaemonSet 一滚动，旧 Pod 收到 SIGTERM 如果没能好好收尾，节点上的监控指标就会断上几十秒，入侵检测、告警全都跟着瞎。更坑的是，不少人以为配了 PDB 就万事大吉，其实 RollingUpdate 走的是 DELETE 接口，PDB 根本拦不住，只能干瞪眼。

所以咱们整理一份检查清单，发布前对着一条条过：

• 进程得接得住信号：容器入口如果是 shell 脚本包了一层，PID 1 就不是真正的采集进程，SIGTERM 发过去等于石沉大海。要确认信号能传到真身，并且进程注册了处理器，退出前把缓冲刷完、最后一批指标推出去。
• 宽限期别抠门：terminationGracePeriodSeconds 默认 30 秒，采集端收尾慢的话建议给到 60 秒，别让人家刚收到通知就被 SIGKILL 一刀砍掉。
• preStop 打个时间差：配个 sleep 10 到 15 秒的 preStop，给 Endpoints 摘除和流量切换留出缓冲。但注意 hook 耗时别超过宽限期，不然会被直接截断，等于白配。
• 优先级要够硬：给监控类 DaemonSet 打上 priorityClassName: system-node-critical。不然节点资源紧张时，kubelet 驱逐第一个拿它开刀——偏偏那才是大家最需要监控的时刻。
• 告警侧降降噪：Prometheus 的告警规则加上 for: 2m，滚动更新造成的短时抓取失败就不会刷出成百上千条告警，把值班同学彻底淹没。

清单之外还有个心态要摆正：PDB 的状态字段在 RollingUpdate 场景里只是摆设，看到 disruptionsAllowed 是 1 并不代表安全，真正管用的是每个 Pod 自己的退出质量。要是业务特别敏感、一点空窗都不能忍，那就上双采集端或者交替更新，拿资源换连续。说到底，监控自己的可靠性，也得当成基建 SLA 来守。