Kubernetes集群健康监控实战：用Prometheus构建节点预警系统

当Kubernetes集群规模扩大时，节点稳定性成为运维团队最头疼的问题之一。想象一下凌晨三点被报警叫醒，发现生产环境多个节点突然变成NotReady状态——这种被动救火的体验想必不少运维工程师都深有体会。与其在故障发生后手忙脚乱地排查，不如建立一套完善的预防性监控体系，让集群自己"告诉"你哪里可能出问题。

1. 监控体系架构设计

现代Kubernetes监控体系通常采用分层设计，从基础设施层到应用层形成完整的观测链条。对于节点健康监控，我们需要关注以下几个核心组件：

• 数据采集层 ：Node Exporter负责收集主机级指标（CPU、内存、磁盘等）
• Kubernetes指标层 ：kube-state-metrics暴露集群状态指标（节点状态、Pod状态等）
• 存储计算层 ：Prometheus实现指标存储和告警计算
• 可视化层 ：Grafana提供监控仪表盘
• 告警通知层 ：Alertmanager处理告警路由和通知

这种架构的优势在于各组件职责明确，且全部采用开源方案，避免了厂商锁定。下面是一个典型的监控数据流向示意图：

Node Metrics → Node Exporter → Prometheus → Alertmanager
                                      ↓
                                   Grafana

2. 关键组件部署与配置

2.1 Node Exporter部署

Node Exporter需要运行在每个工作节点上，建议直接使用DaemonSet部署：

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-exporter
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: node-exporter
  template:
    metadata:
      labels:
        app: node-exporter
    spec:
      containers:
      - name: node-exporter
        image: prom/node-exporter:v1.3.1
        ports:
        - containerPort: 9100
          name: metrics
      hostNetwork: true
      hostPID: true
      tolerations:
      - operator: "Exists"

部署后验证指标是否正常采集：

curl http://<node-ip>:9100/metrics | grep 'node_memory_MemAvailable_bytes'

2.2 Prometheus核心配置

Prometheus需要正确配置抓取规则，以下是关键的scrape_configs片段：

scrape_configs:
  - job_name: 'node-exporter'
    kubernetes_sd_configs:
    - role: endpoints
    relabel_configs:
    - source_labels: [__meta_kubernetes_pod_node_name]
      target_label: node
    - source_labels: [__meta_kubernetes_namespace]
      action: keep
      regex: monitoring
  - job_name: 'kube-state-metrics'
    static_configs:
    - targets: ['kube-state-metrics.monitoring.svc:8080']

3. 关键监控指标解析

3.1 基础资源指标

这些指标来自Node Exporter，反映节点本身的健康状况：

指标名称	告警阈值	说明
node_memory_MemAvailable_bytes	<10%总内存	可用内存不足
node_filesystem_avail_bytes	<15%	磁盘空间不足
node_load1	>CPU核心数*2	CPU负载过高
node_network_up	==0	网络不可用

3.2 Kubernetes特有指标

这些指标来自kube-state-metrics，反映Kubernetes视角的节点状态：

# 节点Ready状态
kube_node_status_condition{condition="Ready",status="true"}

# PLEG健康状态
kubelet_pleg_relist_duration_seconds{quantile="0.99"} > 5

# Kubelet心跳
time() - kube_node_status_condition{condition="Ready"}.timestamp > 300

4. 告警规则配置实战

4.1 内存压力预警

以下Prometheus告警规则可以在内存不足前提前预警：

groups:
- name: node-alerts
  rules:
  - alert: NodeMemoryPressure
    expr: (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes > 0.9
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "高内存使用率 ({{ $value }}%)"
      description: "节点 {{ $labels.node }} 内存使用率超过90%"

4.2 磁盘空间预警

结合inode和可用空间的双重检查：

  - alert: NodeDiskPressure
    expr: |
      (node_filesystem_avail_bytes{fstype=~"ext4|xfs"} / node_filesystem_size_bytes{fstype=~"ext4|xfs"} < 0.15)
      or
      (node_filesystem_files_free{fstype=~"ext4|xfs"} / node_filesystem_files{fstype=~"ext4|xfs"} < 0.1)
    for: 10m
    labels:
      severity: critical

4.3 Kubelet健康检查

监控kubelet心跳和PLEG延迟：

  - alert: KubeletUnresponsive
    expr: |
      time() - kubelet_node_name{job="kubelet"} > 300
      or
      kubelet_pleg_relist_duration_seconds{quantile="0.99"} > 10
    labels:
      severity: critical
    annotations:
      runbook: "https://github.com/kubernetes-monitoring/kubernetes-mixin/blob/master/runbook.md#alert-name-kubeletunresponsive"

5. Grafana可视化实战

5.1 节点健康状态面板

创建包含以下核心组件的仪表盘：

1. 节点状态矩阵 ：用状态面板显示各节点Ready状态
2. 资源使用热图 ：显示CPU/内存/磁盘使用趋势
3. 网络流量图 ：监控节点网络进出流量
4. 异常事件日志 ：集成Kubernetes事件显示

推荐直接导入官方的Node Exporter仪表盘（ID：1860）并进行定制化修改。

5.2 预警指标关联分析

通过Grafana的Transform功能，可以建立指标间的关联关系。例如：

1. 当内存使用率高时，关联显示该节点上运行的Pod内存请求
2. 当磁盘空间不足时，显示占用空间最大的容器
3. 当网络异常时，显示该节点上的网络策略配置

6. 高级监控技巧

6.1 预测性监控

使用Prometheus的预测函数提前发现潜在问题：

# 基于线性回归预测4小时后内存是否耗尽
predict_linear(node_memory_MemAvailable_bytes[6h], 4*3600) < 0

# 磁盘空间耗尽预测
predict_linear(node_filesystem_avail_bytes[24h], 24*3600) < 0

6.2 动态阈值调整

对于波动较大的指标，可以使用基于历史数据的动态阈值：

# 使用周同比数据作为基准
(
  node_load1 
  > 
  avg_over_time(node_load1[7d] offset 7d) * 2
)
and
(
  node_load1 
  > 
  avg_over_time(node_load1[1h]) * 1.5
)

7. 告警优化与事件处理

7.1 告警分级策略

根据影响程度将告警分为三级：

1. Critical ：节点即将不可用（如磁盘将满）
2. Warning ：性能下降但节点仍可用（如CPU负载高）
3. Info ：需要关注的异常（如容器重启频繁）

7.2 告警抑制规则

避免告警风暴的合理抑制配置：

inhibit_rules:
- source_match:
    severity: 'critical'
  target_match:
    severity: 'warning'
  equal: ['node']

在实际运维中，我们发现最有效的预警规则往往不是最复杂的，而是那些能准确反映业务影响的简单指标。例如，某电商平台发现其节点NotReady事件中，70%都伴随着特定的内存增长模式，于是针对性地优化了内存告警规则，使故障预警准确率提升了40%。