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处理告警通知。
架构要点:Prometheus的Pull模型要求所有目标端点暴露
/metrics 接口。在Kubernetes中,通过ServiceMonitor或PodMonitor资源自动发现目标,无需手动维护Target列表。
4.2 Prometheus部署(Operator方式)
推荐使用 Prometheus Operator 在K8s集群中部署,它通过CRD(Custom Resource Definition)管理Prometheus、Alertmanager及相关配置,大幅降低运维复杂度。
4.2.1 部署步骤
- 安装Prometheus Operator:使用Helm Chart或直接应用kube-prometheus-stack。
- 创建Prometheus实例:定义Prometheus CR,指定副本数、存储卷、资源限制。
- 配置ServiceMonitor:定义哪些Service的
/metrics端点需要被抓取。 - 验证抓取状态:通过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]) |
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)或资源重构提供数据支撑。