4. 集群资源监控基础:Prometheus与Grafana部署、核心指标采集(CPU、内存、磁盘、网络)

在Operator集群中,资源监控是容量规划与成本优化的前提。没有精确的监控数据,任何资源调整都是盲目的。本章将搭建以Prometheus为核心、Grafana为可视化层的监控栈,并重点采集CPU、内存、磁盘、网络四大核心指标,为后续的利用率分析与成本分摊奠定数据基础。

4.1 监控架构概览

Operator集群的监控体系采用“拉取(Pull)”模型,由Prometheus Server主动从各目标端点(Targets)抓取指标。Grafana作为数据源连接Prometheus,提供仪表盘与告警管理。整体架构分为三层:

  • 数据采集层:Node Exporter(节点指标)、kube-state-metrics(K8s对象指标)、cAdvisor(容器指标,已内置于kubelet)。
  • 存储与查询层:Prometheus Server负责指标存储、聚合与告警规则评估。
  • 可视化与告警层:Grafana提供仪表盘,Alertmanager处理告警通知。
Operator集群监控架构(Prometheus + Grafana) 数据采集层(Targets) Node Exporter kube-state-metrics cAdvisor (kubelet) 自定义Exporter 存储与查询层 Prometheus Server(TSDB + 告警规则) 可视化与告警层 Grafana Alertmanager
架构要点:Prometheus的Pull模型要求所有目标端点暴露 /metrics 接口。在Kubernetes中,通过ServiceMonitor或PodMonitor资源自动发现目标,无需手动维护Target列表。

4.2 Prometheus部署(Operator方式)

推荐使用 Prometheus Operator 在K8s集群中部署,它通过CRD(Custom Resource Definition)管理Prometheus、Alertmanager及相关配置,大幅降低运维复杂度。

4.2.1 部署步骤

  1. 安装Prometheus Operator:使用Helm Chart或直接应用kube-prometheus-stack。
  2. 创建Prometheus实例:定义Prometheus CR,指定副本数、存储卷、资源限制。
  3. 配置ServiceMonitor:定义哪些Service的 /metrics 端点需要被抓取。
  4. 验证抓取状态:通过Prometheus Web UI的“Targets”页面确认所有端点均为UP。

4.2.2 核心配置示例

apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
  name: operator-prometheus
  namespace: monitoring
spec:
  replicas: 2
  retention: 15d
  resources:
    requests:
      memory: 4Gi
      cpu: 2
    limits:
      memory: 8Gi
      cpu: 4
  storage:
    volumeClaimTemplate:
      spec:
        storageClassName: fast-ssd
        resources:
          requests:
            storage: 100Gi
  serviceMonitorSelector:
    matchLabels:
      team: ops
资源规划提示:Prometheus的内存消耗与时间序列基数(Series Cardinality)强相关。对于100节点规模的Operator集群,建议至少分配4Gi内存和100Gi SSD存储。如果Series数超过1000万,需考虑水平分片(Thanos或Cortex)。

4.3 Grafana部署与数据源配置

Grafana负责将Prometheus中的指标转化为可视化仪表盘。部署方式同样推荐使用Helm Chart,并预先导入社区成熟的Kubernetes监控模板。

4.3.1 部署命令

helm repo add grafana https://grafana.github.io/helm-charts
helm repo update
helm install grafana grafana/grafana \
  --namespace monitoring \
  --set persistence.enabled=true \
  --set persistence.size=10Gi \
  --set adminPassword='your-strong-password' \
  --set datasources."datasources\.yaml".apiVersion=1 \
  --set datasources."datasources\.yaml".datasources[0].name=Prometheus \
  --set datasources."datasources\.yaml".datasources[0].type=prometheus \
  --set datasources."datasources\.yaml".datasources[0].url=http://operator-prometheus:9090 \
  --set datasources."datasources\.yaml".datasources[0].access=proxy \
  --set datasources."datasources\.yaml".datasources[0].isDefault=true

4.3.2 推荐仪表盘ID

仪表盘名称 Grafana ID 适用场景
Kubernetes Cluster Overview 315 集群全局资源视图(CPU/内存/网络/磁盘)
Node Exporter Full 1860 单节点详细指标(磁盘IO、网络流量、CPU各模式)
Kubernetes Pod Resources 6417 Pod级别资源使用与Request/Limit对比
Kubernetes Capacity Planning 10914 容量规划专用:节点资源分配率、预留率、碎片率

4.4 核心指标采集详解

Operator集群的资源监控聚焦于四大类指标:CPU、内存、磁盘、网络。每类指标又分为节点级和Pod级两个维度,分别对应Node Exporter和cAdvisor的数据源。

4.4.1 CPU指标

指标名称 数据源 说明 常用PromQL
node_cpu_seconds_total Node Exporter 节点CPU各模式(user/system/iowait/idle)累计时间 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)
container_cpu_usage_seconds_total cAdvisor 容器CPU使用累计时间 rate(container_cpu_usage_seconds_total{container!=""}[5m])
container_spec_cpu_quota cAdvisor Pod的CPU Limit(以微核为单位) container_spec_cpu_quota / 100000
成本优化关键:对比 container_cpu_usage_seconds_total 与 container_spec_cpu_quota,可以计算CPU利用率(Usage / Limit)。如果利用率长期低于20%,说明资源过度预留,是成本优化的首要目标。

4.4.2 内存指标

指标名称 数据源 说明 常用PromQL
node_memory_MemTotal_bytes Node Exporter 节点物理内存总量 node_memory_MemTotal_bytes
node_memory_MemAvailable_bytes Node Exporter 节点可用内存(含缓存和缓冲区) node_memory_MemAvailable_bytes
container_memory_working_set_bytes cAdvisor 容器真实物理内存使用量(最准确) container_memory_working_set_bytes{container!=""}
container_spec_memory_limit_bytes cAdvisor Pod的内存Limit container_spec_memory_limit_bytes
注意:不要使用 container_memory_usage_bytes 进行成本分析,因为它包含已缓存但未使用的页面,会高估实际使用量。始终使用 container_memory_working_set_bytes 作为Pod内存使用的真实依据。

4.4.3 磁盘指标

指标名称 数据源 说明 常用PromQL
node_filesystem_size_bytes Node Exporter 文件系统总大小 node_filesystem_size_bytes{mountpoint="/"}
node_filesystem_avail_bytes Node Exporter 文件系统可用空间 node_filesystem_avail_bytes{mountpoint="/"}
node_disk_io_time_seconds_total Node Exporter 磁盘IO时间累计,用于计算IOPS和延迟 rate(node_disk_io_time_seconds_total[5m])
container_fs_usage_bytes cAdvisor 容器使用的磁盘空间(仅rootfs) container_fs_usage_bytes{container!=""}

4.4.4 网络指标

指标名称 数据源 说明 常用PromQL
node_network_receive_bytes_total Node Exporter 节点网络接收字节累计 rate(node_network_receive_bytes_total[5m])
node_network_transmit_bytes_total Node Exporter 节点网络发送字节累计 rate(node_network_transmit_bytes_total[5m])
container_network_receive_bytes_total cAdvisor 容器网络接收字节累计 rate(container_network_receive_bytes_total{container!=""}[5m])
container_network_transmit_bytes_total cAdvisor 容器网络发送字节累计 rate(container_network_transmit_bytes_total{container!=""}[5m])
核心指标采集流程与数据源映射 数据源 Node Exporter cAdvisor (kubelet) kube-state-metrics 自定义Exporter 指标分类 CPU指标 内存指标 磁盘指标 网络指标 存储与可视化 Prometheus TSDB (15天保留期) Grafana Dashboard (可视化与告警) 成本分析引擎 (利用率/预留率/碎片率)

4.5 指标采集验证与常见问题

部署完成后,必须验证指标是否正确采集。以下是快速验证清单:

  • Prometheus Targets状态:访问 http://<prometheus-service>:9090/targets,确认所有Endpoint显示为UP。
  • 指标查询测试:在Prometheus的Graph页面执行 up{job="node-exporter"},应返回所有节点的UP值(1表示正常)。
  • Grafana数据源连通性:在Grafana中测试数据源,返回“Data source is working”。
  • 仪表盘数据填充:导入推荐仪表盘后,确认图表有数据点,而非“No data”。
常见问题与排查:
  • Targets显示DOWN:检查网络策略(NetworkPolicy)是否阻止了Prometheus到Exporter的流量;检查Service的端口名称是否为 http-metrics。
  • 指标数据缺失:确认Exporter的 /metrics 端点可访问;检查Prometheus的 scrape_timeout 是否过短(默认10s,对于高负载节点建议调整为30s)。
  • 内存使用率过高:检查Series基数,使用 prometheus_tsdb_head_series 指标查看当前活跃序列数。如果超过500万,考虑增加资源或启用远程存储。

4.6 成本优化视角的指标选择

在成本优化场景中,并非所有指标都同等重要。建议优先关注以下成本敏感指标:

优化维度 核心指标 优化目标
CPU过度预留 container_cpu_usage_seconds_total / container_spec_cpu_quota 将利用率从20%提升至60%以上
内存浪费 container_memory_working_set_bytes / container_spec_memory_limit_bytes 减少内存Limit,避免碎片化
磁盘IO瓶颈 node_disk_io_time_seconds_total + node_disk_io_now 识别高IO等待节点,迁移至SSD或调整Pod分布
网络带宽浪费 container_network_receive_bytes_total + container_network_transmit_bytes_total 识别跨AZ流量,优化Pod亲和性策略
最佳实践:在Grafana中为每个成本敏感指标创建独立的“成本面板”,并设置周环比和月环比趋势线。当资源利用率出现异常波动时,能够快速定位到具体的Namespace、Deployment或Pod,为后续的垂直伸缩(Vertical Pod Autoscaler)或资源重构提供数据支撑。