Kubernetes监控是集群稳定运行的基础能力。没有监控，团队往往只能在服务异常后被动排查；有了监控，才能提前发现节点压力、Pod 重启、资源使用异常、请求延迟升高等问题。真正有效的 Kubernetes 监控，不只是装上 Prometheus 和 Grafana，而是建立节点、容器、业务、事件和告警之间的指标体系。
一、Kubernetes监控为什么重要
Kubernetes 把应用运行拆成 Pod、Node、Service、Ingress、存储、网络等多个层级。只看某个单点数据，很难判断整体健康状态。
监控主要解决：
- 节点资源是否健康
- Pod 是否稳定运行
- 服务性能是否异常
- 扩缩容是否及时
- 哪些问题需要告警
- 故障发生时如何快速定位
二、Prometheus和Grafana分别做什么
Prometheus 通常负责抓取和存储指标数据，例如：
- 节点 CPU、内存、磁盘
- Pod 和容器资源使用
- 应用请求量、延迟、错误率
- Kubernetes 控制平面和组件状态
Grafana 更偏向可视化展示，帮助团队通过仪表盘观察趋势、对比环境和定位异常。
可以简单理解为：
- Prometheus：采集和存储指标
- Grafana：展示和分析指标
三、Kubernetes监控至少要看哪些层面
1. 节点层
要关注：
- CPU、内存、磁盘、网络
- 节点 Ready 状态
- 磁盘压力、内存压力
- kubelet 和容器运行时状态
2. Pod / 容器层
要关注：
- Pod 重启次数
- CPU、内存使用
- OOMKill
- Pod Pending 和调度失败
- 探针失败情况
3. 服务层
要关注：
- QPS
- 延迟
- 错误率
- 成功率
- Ingress 或网关流量指标
4. 平台层
要关注：
- 控制平面组件健康状态
- 存储和网络插件状态
- HPA 扩缩容行为
- PVC 和存储容量情况
四、监控和告警怎么配合
监控负责“看见状态”，告警负责“发现异常并通知”。
常见告警场景包括：
- 节点 NotReady
- Pod 重启次数过高
- CPU 或内存长时间过高
- 服务错误率升高
- 磁盘即将打满
- 关键服务副本不足
告警阈值不要只按默认模板设置，而要结合业务重要性和波动特征做调整。
五、为什么只看资源监控不够
很多团队一开始只看 CPU 和内存，但这远远不够。因为很多问题并不直接表现为资源打满，例如：
- 调度失败
- 镜像拉取失败
- 探针配置错误
- PVC 未绑定
- Service selector 错误
- Ingress 规则异常
所以监控体系要和事件、日志、告警一起看，才能形成完整闭环。
六、监控建设常见误区
常见误区包括：
- 只监控节点，不监控业务服务
- 只做仪表盘，不做告警
- 告警太多导致告警疲劳
- 指标命名和标签不统一
- 没有按环境和命名空间区分
- 监控系统本身缺少高可用设计
这些问题会让监控系统看似存在，但真正出事时发挥不了作用。
结语
Kubernetes监控的目标，不只是“收集指标”，而是建立从节点、Pod、服务到平台组件的全链路可观测能力。Prometheus 和 Grafana 是常见的基础组合，但真正有价值的是指标体系、告警规则和排障路径设计。对生产集群来说，监控不是附加项，而是保障稳定性的基本盘。
FAQ
只装Prometheus和Grafana就够了吗？
不够。还需要梳理指标体系、告警规则、日志配合和责任分工，才能真正形成可用监控体系。
Kubernetes监控要先看节点还是Pod？
两者都要看。节点层反映平台健康，Pod 层反映工作负载状态，缺一不可。
告警越多越好吗？
不是。告警太多会造成告警疲劳，建议优先保留真正影响业务或平台稳定性的关键告警。
