Kubernetes 集群的动态性和复杂性使得传统监控方式难以胜任——Pod 频繁创建销毁、节点弹性扩缩容、服务网络动态变化，这些特性要求监控体系具备自动发现和动态适配的能力。而 Prometheus + Grafana 的组合，已经成为云原生监控领域的标准方案。

一、监控体系架构概览

一个完整的 K8s 资源监控体系由三个核心层次构成：

1. 节点级监控：关注物理机或虚拟机的资源使用情况（CPU、内存、磁盘、网络）。通过 node-exporter 采集，部署为 DaemonSet 在每个节点运行。

2. 容器级监控：关注 Pod 和容器的资源消耗。cAdvisor（Container Advisor）集成在 kubelet 中，自动采集容器的 CPU、内存、文件系统和网络指标。

3. 应用级监控：关注业务应用的自定义指标。应用通过 /metrics 端点暴露 Prometheus 格式的数据，由 Prometheus 主动拉取。

此外，kube-state-metrics 是不可或缺的组件——它通过监听 Kubernetes API Server，暴露集群状态指标（如 Deployment 期望副本数、Pod 重启次数等），与 node-exporter 形成互补：前者回答“应该是什么状态”，后者反映“实际是什么状态”。

二、Prometheus：监控系统的核心

2.1 Prometheus 是什么？

Prometheus 是一个开源监控系统，前身是 SoundCloud 的警告工具包。2016 年，它在继 Kubernetes 之后成为第二个从 CNCF 毕业的项目。其核心特性包括：

• 多维数据模型：由 metric 名字和一组 key/value 标签构成的时间序列
• 灵活的查询语句（PromQL）
• 采用 HTTP 协议，使用 Pull 模式拉取数据
• 支持服务发现或静态配置来发现监控目标
• 无依赖存储，支持 local 和 remote 模式

2.2 核心组件及其职责

组件	职责
Prometheus Server	定期从静态配置或服务发现（DNS、Consul、K8s）的 targets 拉取数据
Exporters	负责向 Prometheus Server 汇报数据，如 node-exporter、MySQL exporter 等
Pushgateway	解决 Pull 模式无法拉取的场景（如不在同一子网、防火墙限制），类似 Zabbix Proxy
Alertmanager	负责告警的去重、分组、抑制和路由分发
Grafana	作为可视化 WebUI，展示监控数据

2.3 数据模型与指标类型

Prometheus 存储的是时序数据——按照相同时序（相同的名字和标签），以时间维度存储连续的数据集合。时序由 Metric 名字和一组 Key/Value 标签定义。

四种核心指标类型：

1. Counter（计数器）：只增不减，如 http_requests_total，用于记录服务请求总数、错误总数
2. Gauge（仪表盘）：可增可减，如内存使用率、磁盘使用率
3. Histogram（直方图）：对数据进行采样并统计区间分布，如请求持续时间，用于计算分位数
4. Summary（摘要）：类似 Histogram，但直接存储分位数（quantile）值

2.4 在 K8s 中部署 Prometheus

推荐使用 Prometheus Operator，它通过 CRD（Custom Resource Definition）简化了配置管理。ServiceMonitor 是其引入的核心 CRD——通过声明式配置定义 Prometheus 应抓取哪些服务的指标，并通过标签选择器自动发现目标，完美适配 K8s 的动态特性。

关键的 scrape_configs 配置示例（以抓取 node-exporter 为例）：

scrape_configs:
- job_name: 'node-exporter'
  kubernetes_sd_configs:
  - role: endpoints
  relabel_configs:
  - source_labels: [__meta_kubernetes_service_label_app]
    action: keep
    regex: node-exporter

部署验证命令：

# 检查 node-exporter DaemonSet
kubectl get daemonset -n monitoring
# 查看 Prometheus 目标是否在线
kubectl port-forward svc/prometheus-server -n monitoring 9090:9090
# 访问 http://localhost:9090/targets

三、Grafana：数据可视化层

3.1 部署 Grafana

使用 Helm 部署是最常见的方式：

# 添加 Grafana Helm 仓库
helm repo add grafana https://grafana.github.io/helm-charts
helm repo update

# 创建命名空间
kubectl create namespace monitoring

# 部署 Grafana（需准备 values.yaml 配置数据源）
helm install grafana grafana/grafana -n monitoring --values grafana-values.yaml

关键的 values.yaml 配置示例：

persistence:
  enabled: true
  size: 10Gi

datasources:
  datasources.yaml:
    apiVersion: 1
    datasources:
    - name: Prometheus
      type: prometheus
      url: http://prometheus-server.monitoring.svc.cluster.local
      access: proxy
      isDefault: true

resources:
  requests:
    cpu: 100m
    memory: 256Mi
  limits:
    cpu: 500m
    memory: 512Mi

3.2 访问与数据源配置

部署完成后，通过端口转发访问：

kubectl port-forward svc/grafana -n monitoring 3000:80

访问 http://localhost:3000，默认用户名/密码为 admin/admin。

在 Grafana 界面中：

1. 进入 Configuration → Data Sources
2. 点击 Add data source，选择 Prometheus
3. 填写 URL（如 http://prometheus-server.monitoring.svc.cluster.local）
4. 点击 Save & Test，验证连接是否成功

3.3 预置 Dashboard

社区提供了大量优质的 Kubernetes 监控 Dashboard。其中 dotdc/grafana-dashboards-kubernetes 是一套现代化的 Dashboard 集合，包含：

• k8s-views-nodes.json：节点视图
• k8s-views-pods.json：Pod 视图
• k8s-views-namespaces.json：命名空间视图
• k8s-system-api-server.json：API Server 监控
• k8s-system-coredns.json：CoreDNS 监控

可以通过 Helm values 直接加载这些 Dashboard：

grafana:
  dashboardProviders:
    dashboardproviders.yaml:
      apiVersion: 1
      providers:
      - name: 'grafana-dashboards-kubernetes'
        orgId: 1
        folder: 'Kubernetes'
        type: file
        options:
          path: /var/lib/grafana/dashboards/grafana-dashboards-kubernetes
  dashboards:
    k8s-views-nodes:
      url: https://raw.githubusercontent.com/dotdc/grafana-dashboards-kubernetes/master/dashboards/k8s-views-nodes.json

3.4 Dashboard 设计原则

设计有效的 Dashboard 应遵循三大原则：

• 聚焦原则：每个 Dashboard 聚焦一个主题（如节点概览、API 网关监控），避免堆砌无关面板
• 层次原则：按“概览 → 详细 → 下钻”的层次组织，顶部放关键指标单值面板，中部放趋势图，底部放明细表格
• 阈值原则：为关键指标设置颜色阈值（绿色正常、黄色警告、红色危险），使异常一目了然

四、常用监控指标与 PromQL 查询

4.1 常用 PromQL 查询示例

监控目标	PromQL 查询	说明
节点 CPU 使用率	100 - (avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)	计算节点整体 CPU 使用率
节点内存可用率	node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100	节点可用内存百分比
Pod CPU 使用率	sum(rate(container_cpu_usage_seconds_total{image!=""}[5m])) by (pod, namespace)	按 Pod 和命名空间统计 CPU 使用
Pod 内存使用率	sum(container_memory_working_set_bytes{container!=""}) by (pod, namespace) / (sum(container_spec_memory_limit_bytes{container!=""}) by (pod, namespace)) * 100	计算 Pod 内存使用百分比（需有 limit）
集群节点数	count(kube_node_info)	集群节点总数
运行中 Pod 数	sum(kube_pod_status_phase{phase="Running"})	集群中 Running 状态的 Pod 数量
容器重启次数	sum(increase(kube_pod_container_status_restarts_total[1h]))	过去 1 小时的重启事件总数

五、告警配置

5.1 告警规则示例

告警规则使用 PromQL 表达式定义触发条件。例如：

groups:
- name: kubernetes-resources
  rules:
  - alert: HighPodMemory
    expr: sum(container_memory_working_set_bytes{container!=""}) by (pod, namespace) / (sum(container_spec_memory_limit_bytes{container!=""}) by (pod, namespace)) * 100 > 90
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "Pod {{ $labels.pod }} 内存使用率超过 90%"

5.2 Alertmanager 配置

Alertmanager 负责管理告警通知，支持去重、分组、抑制和路由：

route:
  group_by: ['alertname', 'cluster']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: 'email'
receivers:
- name: 'email'
  email_configs:
  - to: 'team@example.com'

告警级别建议：

• P0 级别（服务完全不可用）：电话或短信通知
• P1 级别（错误率升高）：企业微信或钉钉群
• P2 级别（资源使用率偏高）：工单系统

六、存储与扩展

6.1 存储管理

Prometheus 默认使用本地 TSDB 存储，保留时间通常设置为 15~30 天。如需更长保留时间或高可用，可使用远程存储方案：

• Thanos：将历史数据上传到对象存储（如 S3），同时提供全局查询视图
• VictoriaMetrics：高性能的 Prometheus 兼容时序数据库
• 分片（Sharding）方案：当单个 Prometheus 无法承载监控目标数量时，按服务拆分为多个实例

6.2 适用场景说明

Prometheus 在记录纯数字时间序列方面表现出色，适用于服务器硬件监控和微服务监控。需要注意：它对统计数据不要求 100% 精确（如实时计费系统不适合使用），其核心价值在于服务可靠性保障和快速问题定位。

结语

Prometheus + Grafana 构建的监控体系，通过自动发现、多维数据模型和灵活的可视化能力，完美适配了 Kubernetes 的动态环境。在落地时，建议关注几个运营要点：

1. 定期评审监控覆盖度：新增服务是否已纳入监控
2. 定期评审告警有效性：告警准确率、响应时间是否达标
3. 定期评审 Dashboard 使用情况：归档无人查看的 Dashboard

监控体系不是一次性建设工程，需要持续运营和迭代，才能让数据和告警真正为团队创造价值。