Kubernetes 集群一旦投入生产，规模会迅速膨胀：成百上千的 Pod、分布在多台节点上的 Service、频繁变动的 Deployment，都让「集群是否健康」成为一个必须回答的问题。单纯靠 kubectl get 手工巡检既低效又容易遗漏，而容器会因为调度、扩缩容、镜像更新等原因被反复创建和销毁，进一步加大了人工排查的难度。因此，一套自动化、可视化的监控告警体系，是每一位 K8s 运维工程师的必修课。
本系列第 14 天，我们就来搭建 Kubernetes 领域事实上的监控标准组合——Prometheus 与 Grafana，让你能够实时掌握集群状态，并在异常发生时第一时间收到告警。
为什么选择 Prometheus + Grafana
Prometheus 是一个开源的时序数据库与监控告警系统，由 SoundCloud 开发，后被捐献给 CNCF，如今已成为继 Kubernetes 之后第二个「毕业」的 CNCF 项目。它采用「拉取（Pull）」模型，主动从目标端点抓取指标数据，天然契合 Kubernetes 这种动态调度、Pod 随时漂移的环境。
Grafana 则是一款功能强大的可视化面板工具，它本身不采集数据，而是通过数据源插件对接 Prometheus，将时序数据渲染成直观的仪表盘。二者分工明确：Prometheus 负责采集与存储指标、评估告警规则，Grafana 负责展示与探索。
这套组合之所以成为事实标准，主要得益于三点：
- 多维数据模型：指标以「名称 + 一组键值对标签」的形式存储，例如
http_requests_total{method="GET",pod="nginx-0"}，天然适合描述 K8s 中大量的维度。 - 强大的查询语言 PromQL：可以对时序数据做聚合、过滤、计算，灵活度远超传统监控系统。
- 丰富的生态：社区提供了
kube-prometheus-stack这样的全家桶 Chart，一条命令即可部署完整体系。
核心概念解析
在动手之前，先理清几个关键组件，它们共同构成了 Prometheus 在 K8s 中的工作方式。
Prometheus Server
核心服务，负责定时抓取（scrape）目标暴露的 /metrics 接口，将数据写入本地时序存储，并根据规则文件持续评估告警。抓取间隔通常在 15 到 30 秒之间。
ServiceMonitor 与 Prometheus Operator
在 Kubernetes 里，我们一般通过 Prometheus Operator 来管理 Prometheus。Operator 引入了一个名为 ServiceMonitor 的自定义资源，用于声明「去抓取哪些 Service 背后的指标端点」。这样无需修改 Prometheus 配置，只要创建或删除 ServiceMonitor，监控目标就能动态变更。
Alertmanager
告警管理器，接收 Prometheus 推送过来的告警，负责去重、分组、静默（silence）以及路由（route）到邮件、钉钉、企业微信、PagerDuty 等渠道。
Node Exporter 与 kube-state-metrics
node-exporter 部署在每个节点上，暴露主机层面的 CPU、内存、磁盘、网络等指标；kube-state-metrics 则监听 Kubernetes API，把 Deployment、Pod、Node 等资源对象的状态翻译成指标，例如某个 Deployment 期望副本数与当前副本数。
实战：使用 Helm 部署监控栈
下面通过 Helm 安装 kube-prometheus-stack，一次性获得 Prometheus、Grafana、Alertmanager、Node Exporter 与 kube-state-metrics。
首先添加官方 Chart 仓库并更新索引：
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
创建命名空间并安装 Chart。这里我们设置 Grafana 的管理员密码，并开放 NodePort 以便后续访问：
kubectl create namespace monitoring
helm install kube-prometheus-stack prometheus-community/kube-prometheus-stack
--namespace monitoring
--set grafana.adminPassword='Admin@12345'
--set grafana.service.type=NodePort
等待所有 Pod 就绪：
kubectl get pods -n monitoring -w
安装完成后，通过 NodePort 访问 Grafana 登录页，默认用户名是 admin，密码即上面设置的值。Prometheus 的 Web UI 也可以临时通过端口转发访问：
kubectl port-forward -n monitoring svc/kube-prometheus-stack-prometheus 9090:9090
验证指标采集
进入 Prometheus 的「Status -> Targets」页面，可以看到 node-exporter、kube-state-metrics、alertmanager 等全部处于 UP 状态。在查询框输入下面的 PromQL，能看到集群各节点的 CPU 使用率：
100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)
配置告警规则
监控的价值在于「出了问题能立刻知道」。kube-prometheus-stack 自带大量开箱即用的告警规则，但我们也要会编写自定义规则。下面创建一个监控某个 Deployment 副本数不足的 PrometheusRule：
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
name: deployment-replicas-alert
namespace: monitoring
labels:
release: kube-prometheus-stack
spec:
groups:
- name: deployment.rules
rules:
- alert: DeploymentReplicasMismatch
expr: kube_deployment_spec_replicas{deployment="my-app"} != kube_deployment_status_replicas_available{deployment="my-app"}
for: 5m
labels:
severity: warning
annotations:
summary: "Deployment {{ $labels.deployment }} 副本数异常"
description: "期望 {{ $value }} 个副本，但可用副本不足，已持续 5 分钟。"
其中 labels.release 必须与 Helm 安装时生成的 release 名匹配，否则 Operator 不会加载这条规则。应用配置：
kubectl apply -f deployment-replicas-alert.yaml
在 Grafana 中查看仪表盘
Grafana 已预置了 Data Source，指向同一个命名空间下的 Prometheus。登录后依次点击「Dashboards -> Browse」，可以看到大量官方仪表盘，如「Kubernetes / Compute Resources / Pod」「Nodes」等。
若要自建面板，可在「Create -> Dashboard -> Add panel」中编写 PromQL。例如查看某个命名空间下 Pod 的内存占用总量：
sum(container_memory_working_set_bytes{namespace="monitoring"}) by (pod)
把面板保存进自定义仪表盘，就能形成一套贴合自己业务的可视化看板。
常见问题
Q1：Targets 页面里某些目标一直是 DOWN？
通常是 ServiceMonitor 的 selector 与 Service 的 label 不匹配，或者目标端点未暴露 /metrics。用 kubectl describe servicemonitor -n monitoring 查看选择器，再对照 Service 的 labels 排查。
Q2：Grafana 面板显示「No data」，但 Prometheus 里有数据？
检查 Grafana Data Source 的 URL 是否正确。在集群内部应使用 Service 的 DNS 名，例如 http://kube-prometheus-stack-prometheus.monitoring.svc:9090，而不是 localhost 或宿主机 IP。
Q3：告警重复发送、骚扰太多？
在 Alertmanager 中配置合理的 group_by、group_wait 与 repeat_interval，把同一类告警聚合后统一发送，并设置静默窗口抑制已知故障期间的噪音。
Q4：指标数据量太大导致存储压力？
评估是否需要保留全部历史指标，可通过 --storage.tsdb.retention.time 设置保留时长，或使用 Thanos/VictoriaMetrics 等方案做长期存储与下采样。
总结
Prometheus 与 Grafana 的组合，为 Kubernetes 提供了从指标采集、存储、告警到可视化的完整闭环。今天我们从「为什么选这套组合」出发，理清了 Prometheus Server、ServiceMonitor、Alertmanager、Node Exporter 与 kube-state-metrics 的分工，并用 Helm 快速部署了监控栈，还实战了自定义告警规则与 Grafana 面板的编写。掌握这套体系，意味着你对集群的状态有了「看得见、叫得响」的掌控力，这是走向生产级 K8s 运维的关键一步。
下期预告：第 15 天我们将进入「应用打包——Helm 与 Chart 实战」，深入讲解 Chart 结构、模板语法、Values 管理以及如何把复杂应用一键发布到集群，敬请期待。
暂无评论内容