1. 课程导论与背景：为什么需要将 Prometheus 接入 Kubernetes 存储组件拓扑图？租户配额校准的痛点与价值
1.1 从“黑盒监控”到“拓扑感知”的演进
在 Kubernetes 环境中，存储组件（如 CSI 驱动、PV/PVC、存储后端）的监控长期停留在“黑盒”模式：Prometheus 仅采集存储 Pod 的 CPU/内存指标，或通过 kubelet-volume-stat 获取简单的磁盘使用量。这种模式无法回答以下关键问题：
- 哪个租户（Namespace） 正在消耗哪个存储后端（如 Ceph RBD、NFS、vSphere）的容量？
- 存储拓扑路径 中，是 CSI 控制器、节点插件还是后端集群出现了性能瓶颈？
- 租户的配额（如 PVC 大小限制、IOPS 上限）是否与实际使用量匹配？
将 Prometheus 接入 Kubernetes 存储组件拓扑图，本质上是将存储资源的使用关系从“平面指标”升级为“有向拓扑”，使监控数据具备租户维度的上下文。
核心转变： 从“这个 PV 用了 80%” → “租户 A 在存储池 fast-tier 上的 PV 用了 80%，且该租户的 IOPS 配额已超限 120%”。
1.2 存储拓扑图的组成与数据流
下图展示了 Kubernetes 存储组件拓扑的核心节点与 Prometheus 采集路径：
1.3 租户配额校准的四大痛点
在没有拓扑感知的监控体系下，租户配额校准面临以下实际困难：
| 痛点 | 具体表现 | 后果 |
|---|---|---|
| 1. 容量归属模糊 | 无法区分同一存储后端上不同租户的实际消耗 | 超卖导致存储性能争抢，SLA 无法保障 |
| 2. 配额与拓扑脱节 | 租户配额仅绑定 PVC 大小，未关联 CSI 驱动或存储池 | 配额调整时无法评估对后端的影响 |
| 3. 指标孤岛 | Prometheus 存储指标与 Kubernetes 资源指标分离 | 排障时需要手动关联多个 Grafana 面板 |
| 4. 缺乏动态校准 | 配额变更后，监控告警阈值无法自动同步 | 人工操作延迟导致配额溢出或资源浪费 |
1.4 拓扑接入后的价值
通过将 Prometheus 接入存储组件拓扑图，租户配额校准获得以下能力：
- 端到端可见性： 从 Pod → PVC → PV → CSI → 存储后端，每个环节的指标都携带
namespace、storageclass、provisioner标签。 - 精准配额计算： 基于拓扑路径聚合租户的实际使用量，与配额上限进行实时对比。
- 自动化校准规则： 当租户使用量连续 3 个周期超过配额 80% 时，自动触发扩容建议或告警。
- 成本分摊依据： 拓扑数据可直接用于存储成本的多租户计费报表。
实战案例： 某金融科技公司接入拓扑图后，将租户存储配额校准周期从“每周人工核对”缩短为“实时自动校准”，存储资源利用率提升 35%，因配额超限导致的 P0 故障减少 80%。
1.5 课程目标与学习路径
本课程将带领你完成以下关键任务：
- 部署与配置： 在 Kubernetes 集群中部署 Prometheus Operator，并启用 CSI 指标采集。
- 拓扑建模： 使用 Prometheus Relabel 规则和 Recording Rules 构建存储拓扑标签体系。
- 配额校准： 编写 PromQL 查询，实现租户维度的容量、IOPS、带宽配额校准。
- 告警与自动化： 配置基于拓扑的告警规则，并通过 Webhook 实现配额自动调整。
下图展示了本课程的核心知识模块与学习路径：