四年K8s踩坑：上千指标里我只看这些

凌晨三点被告警吵醒，发现是某个节点的CPU飙到87%——但你的服务其实跑得挺好。这种故事，在Kubernetes运维圈每天都在上演。

一个运行了四年K8s生产环境的团队，把经验浓缩成一句话：平台给你上千个指标，但真正管用的不到20个。他们按三层拆解了监控策略，每一层的思路都值得细品。

第一层：集群健康——别盯着单台机器

基础设施层的核心问题是"平台还能不能撑住"。这里最容易犯的错，是对单个节点过度敏感。

原文作者的建议很直接：CPU告警不要设在节点级别，要设在集群级别。当整体利用率超过80%再触发，避免半夜被单节点波动吵醒。具体指标包括：

• 节点就绪状态（node_ready_status）——基础中的基础
• 节点CPU/内存利用率——告警线分别设在85%和90%
• 磁盘压力、PID压力——布尔型告警，触发即高危

控制平面更需要盯紧。API Server的P99延迟超过1秒、etcd的磁盘同步延迟超过100毫秒、调度器出现待调度Pod积压——这些才是会拖垮整个平台的信号。

一个细节：scheduler_pending_pods的告警要设5分钟持续期。短暂积压是正常现象，持续挂起才说明资源调度出了问题。

第二层：工作负载健康——监控部署，而非Pod

这是大多数团队踩坑最深的地方。他们监控Pod状态，却忽略了Pod只是部署的"实例"。

关键指标转向Deployment层面：

• 可用副本数低于期望副本数——持续5分钟以上触发
• Deployment版本号与观察版本号不一致——说明滚动更新卡住了

Pod层面只保留三类信号：

• 重启次数持续增长——CrashLoopBackOff的经典前兆
• 容器被OOM杀死——内存限制设得太低
• Pod处于Pending状态超过2分钟——调度或资源配额问题

作者特别分享了他写过最有价值的告警规则：15分钟内重启速率大于0，持续15分钟触发。这个规则帮他们提前发现了无数即将进入死循环的服务。

弹性伸缩（HPA）也要纳入监控视野。当当前副本数等于最大副本数，或者CPU利用率持续高于目标值，说明自动扩容已经触顶，需要人工介入评估容量规划。

第三层：应用性能——用户真正感知的东西

前两层都是"平台视角"，这一层才是"用户视角"。无论集群多健康、Pod运行多平稳，请求报错或响应慢，用户就会流失。

这里采用RED方法：速率（Rate）、错误（Errors）、延迟（Duration）。

• 每秒请求速率——流量突增的预警
• 错误率百分比——超过1%即告警
• P99请求延迟——超过500毫秒触发

USE方法（利用率、饱和度、错误）作为补充，关注CPU请求与限制的比例，判断资源分配是否合理。

三层监控的边界很清晰：集群层回答"平台有没有病"，工作负载层回答"部署有没有病"，应用层回答"用户体验有没有病"。混在一起监控，必然导致告警风暴和麻木。

这套方法论背后是一个更深层的选择：在数据过载的时代，做减法比做加法更难，也更有价值。当你下次面对Grafana里密密麻麻的仪表盘时，不妨先问自己——如果只能留三个指标，我会选哪三个？