Kubernetes部署监控怎么做？手把手带你搭个能用的监控系统

公司刚把几个微服务迁到 ref="/tag/2020/" style="color:#C468A7;font-weight:bold;">Kubernetes 上，结果某天半夜 API 响应变慢，日志里又没明显报错，运维小哥盯着屏幕抓耳挠腮——这时候要是有个监控系统能一眼看出是哪个 Pod 内存爆了、哪个节点 CPU 跑满、哪个 Service 的请求 503 暴增，问题早就定位完了。

监控不是装个软件就完事

Kubernetes 本身不带开箱即用的监控界面，它只提供基础指标接口（比如 /metrics），真正要看到图形、告警、下钻分析，得靠外部工具组合。最常见也最接地气的方案就是 Prometheus + Grafana：一个负责“抄表”，一个负责“画表”。

Prometheus 怎么盯住你的集群？

先在集群里跑一个 Prometheus 实例，通常用 Helm 或 YAML 部署。核心配置是 prometheus.yml 里的 scrape_configs，告诉它去哪拉数据。比如监控 kubelet：

scrape_configs:
  - job_name: 'kubernetes-nodes'
    kubernetes_sd_configs:
      - role: node
    relabel_configs:
      - source_labels: [__address__]
        target_label: __address__
        replacement: <node-ip>:10250
      - action: labelmap
        regex: __meta_kubernetes_node_label_(.+)

再加一段监控 Service 和 Pod 的配置，Prometheus 就能自动发现新上线的 Pod 并采集 CPU、内存、网络收发包等指标。

Grafana 画图，别硬背面板参数

装好 Grafana 后，连上 Prometheus 数据源，直接导入社区现成的仪表盘 ID，比如 3119（Kubernetes Cluster Monitoring）或 6417（Pods and Containers）。打开一看：节点负载曲线、各命名空间内存使用热力图、Pod 重启次数排行——这些都不是玄学，都是你集群当前的真实呼吸节奏。

告警不能只靠人盯

光看图不行，出问题得有人知道。Prometheus Alertmanager 就是干这个的。写一条简单规则：

groups:
- name: example
  rules:
  - alert: HighPodRestartRate
    expr: count_over_time(kube_pod_status_phase{phase="Running"}[1h]) < 10
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "Pod {{ $labels.pod }} in namespace {{ $labels.namespace }} restarted too often"

配上邮件或钉钉 Webhook，一有 Pod 连续重启，消息立马弹到手机上。

别忽略日志和链路

指标监控管“有没有问题”，但“为什么出问题”还得看日志和调用链。ELK（Elasticsearch + Logstash + Kibana）或 Loki + Promtail 是轻量日志方案；Jaeger 或 Zipkin 则帮你串起一次 HTTP 请求从 Ingress 到后端 Pod 的完整路径。比如用户反馈订单提交卡顿，查链路图一眼就能看到是调支付服务那步耗时飙升，不用翻十多个 Pod 的日志。

监控不是一步到位的事，但也不用一上来就堆高大上的平台。从 Prometheus 抓指标、Grafana 看图、Alertmanager 发告警这三板斧开始，你的 Kubernetes 集群就有了基本的“健康感知力”。