保姆级教程：给你的K8s集群装上“听诊器”，用Prometheus和Node Exporter提前预警NotReady

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，反映节点本身的健康状况：

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%。