Kubernetes告警风暴是怎么形成的

0 阅读5分钟

当你正专心写着代码时,手机突然开始狂响。钉钉群、企微群、短信轮番轰炸——十分钟里收到了上百条告警。你打开监控面板一看:CPU高了、内存高了、Pod重启了、节点状态异常了……一堆红色警告。

但真正导致问题的,可能只是某个节点上的磁盘快满了。

这就是K8s运维里常见的“告警风暴”——故障本身没那么致命,但告警多到让你想摔手机。

一、K8s天生就容易“告警放大”

K8s是一层套一层的:Pod、ReplicaSet、Deployment、Service、Node……每一层都有自己的健康检查。底层一个小毛病,传到上面就变成了“全家桶”告警。

举个例子:一个服务器的内核出了点问题,导致kubelet不能正常上报心跳。然后会发生什么?

  • 节点状态变成NotReady → 节点告警一条
  • 节点上跑的所有Pod都被标记为异常 → 每个Pod来一条告警
  • Deployment控制器发现Pod少了,开始重建Pod → 重建事件告警
  • 新Pod要调度到别的节点,别的节点资源可能不够 → 又来个调度告警

一个底层故障,轻轻松松变成几十条告警。这就是K8s告警风暴的根本原因:故障会像滚雪球一样被放大。

二、CPU、内存这些老指标,在K8s里经常“撒谎”

很多团队监控K8s,还是用老一套:看CPU、看内存、看磁盘。但这些指标在K8s里经常不准。

  • CPU:一个跑批处理的Pod,突然CPU飙到80%,其实人家干活呢,很正常。但你要是告警阈值设在70%,那就误报了。
  • 内存:Java应用内存占用一直很高,但只要GC能正常回收,就没问题。但监控可不管这些,觉得高就报警。
  • 磁盘:节点上有日志轮转,磁盘使用率一下子涨到90%,过一会又掉下去了。你要是按峰值报警,那天天被吵。

更麻烦的是,很多人怕漏报,把阈值设得很低。结果业务稍微抖一下就报警,时间长了大家都不当回事了,真出事的时候反而没人看。

三、事件重复发,一条故障刷出几百条消息

K8s有个“事件”机制,会记录各种操作。本意是帮你排查问题,但故障的时候,事件能把你刷到崩溃。

比如你配的镜像地址写错了,Pod拉取镜像失败后,Kubernetes会不断重试并生成失败事件。如果这些事件被直接转发到告警系统,很容易形成大量重复告警。这些事件如果都转成告警发到群里,那就是刷屏。

很多监控系统(比如常见的Prometheus加Alertmanager)自带的去重能力很弱,或者根本没配置好。结果就是:同一个错误,发了几百条消息。

四、服务互相调,一挂挂一片

K8s里的服务互相调用很常见。A调B,B调C。如果C服务的数据库挂了,导致C超时,会发生什么?

  • C服务超时告警
  • B调C也超时 → B也告警
  • A调B也超时 → A也告警

三个服务各发一堆告警,看起来整个系统都瘫了。但根因就一个:C的数据库挂了。

如果没有工具帮你分析告警之间的依赖关系,值班的人就得自己对着时间戳、翻日志、画调用链,非常麻烦。

五、告警风暴的“后遗症”比故障本身还烦

告警风暴不只是吵,它还会带来一堆麻烦:

  1. 真正的严重告警被淹了:几百条消息里,可能有一条是“订单数据库连接池满了”,但你就是没看到。
  2. 反应变慢:收到上百条告警,你不知道先看哪个。等你看明白,业务已经停了半小时。
  3. 人麻了:天天被无效告警轰炸,大家开始习惯性忽略所有告警,甚至直接把群静音。
  4. 浪费精力:每一条告警都要看一眼、判断一下,不管是人还是自动化的脚本,都在做无用功。

六、怎么不让告警风暴炸到你?

说了这么多问题,那怎么解决呢?三个方向供你参考。

第一,告警要会“合并同类项”
同一个故障产生的告警,别一条一条发。比如“节点A坏了导致8个Pod重跑”,就发一条告警,后面附上“影响的Pod列表”。别搞成8条。

第二,阈值别设太死,加个“持续时间”
别一超过阈值就报警。比如“CPU超过90%持续5分钟”再报。业务瞬时抖动很正常,让它抖一会儿。另外,核心服务和普通服务的阈值要分开,别一视同仁。

第三,让系统帮你找“真凶”
当一堆告警同时涌来的时候,系统能不能自动判断谁是根因?比如数据库连接池满了,就只发这条告警,然后附带一句“受影响的服务有A、B、C”。这样值班的人一眼就知道该修什么。

七、关于告警治理,专业团队是怎么做的?

告警风暴这事儿,很多中小团队刚上K8s的时候都会踩坑。监控装了一堆,告警规则配了一大堆,结果第一周就被吵得受不了。后来我了解到,有些做运维服务的公司,比如江苏立维,他们在帮客户搭建K8s监控的时候,会直接内置一套告警治理的策略——比如自动聚合重复告警、识别告警之间的依赖关系、把噪声告警自动降级。同时他们还有7x24的值班工程师,就算告警真的炸了,也有人工帮你快速过滤出真正的故障。

当然,不一定非要找外部团队。每个运维都可以从自己的集群开始,每个月回顾一次告警记录,把那些“报了也不解决问题的”告警规则删掉。告警风暴的核心从来不是技术问题,而是你愿不愿意花时间去搞清楚:什么该报,什么不该报。