1. 课程导论：云原生容量水位巡检的背景、痛点与目标
1.1 云原生容量管理的挑战
在云原生架构中，微服务、容器化与动态调度使得传统“峰值规划+静态扩容”模式彻底失效。Kubernetes 集群的 Pod 副本数、节点资源利用率、HPA 弹性行为以及中间件连接池等指标，呈现出高维、时变、非线性特征。运维团队面临的核心矛盾是：业务流量不可预测 与 基础设施资源有限 之间的平衡。
关键事实： 据 CNCF 调查报告，超过 60% 的 Kubernetes 生产事故与容量规划不足或资源争抢直接相关。传统基于阈值的告警往往在故障发生后才触发，缺乏“提前发现、提前干预”的能力。
1.2 传统巡检的四大痛点
| 痛点 | 表现 | 后果 |
|---|---|---|
| 被动响应 | 告警阈值固定，仅在资源耗尽时触发 | 业务受损、SLA 不达标 |
| 指标孤岛 | CPU/内存/磁盘/网络各自独立监控 | 无法关联分析容量瓶颈 |
| 人工依赖 | 依赖运维人员定期登录查看 Dashboard | 效率低、易遗漏、无法 7×24 覆盖 |
| 缺乏预测 | 只有当前状态，没有趋势分析 | 无法提前扩容或缩容 |
1.3 方案目标：从“被动告警”到“主动巡检”
本课程设计的 Prom 告警驱动的云原生容量水位巡检方案，旨在通过 Prometheus 生态构建一套自动化、可编程、可预测的容量巡检体系。核心目标如下：
- 自动化巡检：基于 PromQL 定期执行容量评估，无需人工介入。
- 多维度关联：融合节点、Pod、容器、中间件等多层指标。
- 趋势预测：利用线性回归或简单预测算法，提前发现容量拐点。
- 告警驱动闭环：巡检结果直接触发告警、自动扩缩容或工单流转。
- 可视化与报告：生成巡检报告，支持 Grafana 大盘与钉钉/企微通知。
1.4 Prometheus 在方案中的核心角色
Prometheus 不仅是监控数据采集与存储系统，更是整个容量巡检方案的 数据中枢与规则引擎。其核心能力体现在以下三个层面：
- 数据采集层：通过 kube-state-metrics、cAdvisor、Node Exporter 以及自定义 Exporter，采集集群全量资源指标。
- 规则评估层：利用 PromQL 编写容量巡检规则（如节点内存压力、Pod CPU 超分比、PVC 使用率趋势），由 Prometheus 定期评估。
- 告警触发层：当巡检规则命中阈值或趋势异常时，通过 Alertmanager 发送告警，驱动自动化运维动作。
设计理念： 本方案不引入额外重量级组件，完全基于 Prometheus 原生能力（Recording Rules、Alerting Rules、联邦集群）构建，降低运维复杂度。
1.5 方案整体架构
下图展示了本方案的核心组件与数据流关系：
1.6 巡检规则示例（提前预览）
为帮助理解方案落地形态，以下是一个典型的容量巡检 PromQL 规则，用于检测节点内存压力趋势：
# 节点内存使用率 7 天线性斜率（预测未来 24 小时是否超 90%）
- record: node:memory_usage_ratio:trend_7d
expr: |
deriv(
node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes
/
node_memory_MemTotal_bytes
[7d]
)
# 当预测 24 小时后内存使用率 >= 0.9 时告警
- alert: NodeMemoryPressureForecast
expr: |
node:memory_usage_ratio:trend_7d * 86400
+ (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes)
/ node_memory_MemTotal_bytes
>= 0.9
for: 5m
labels:
severity: warning
annotations:
summary: "节点 {{ $labels.instance }} 内存将在 24 小时内超过 90%"
注意： 上述规则仅为示例，实际生产环境中需根据业务特征调整预测窗口、斜率阈值以及告警严重级别。本课程后续章节将详细讲解如何设计、调优与测试此类规则。