1. 课程导论：为什么K8s存储容量规划至关重要？常见存储瓶颈与故障案例
1.1 存储容量规划的“盲区”
在Kubernetes集群的日常运维中，CPU和内存资源通常受到高度关注，而存储容量却常常沦为“事后补救”的对象。许多团队在应用迁移上云时，只关注了Pod的副本数和计算资源，却忽略了有状态应用对持久化存储的消耗模型。这种规划盲区会导致集群在业务高峰期突然出现Pod挂起、节点磁盘压力、甚至整个集群不可用等严重故障。
⚠️ 核心观点： 存储容量规划不是简单的“买多少块硬盘”，而是从应用I/O模型、PVC声明周期、存储后端性能到集群资源预留的全链路量化过程。缺少这一环，K8s集群的稳定性将建立在沙丘之上。
1.2 常见存储瓶颈与故障案例
以下表格总结了生产环境中最常见的四类存储相关故障，它们都与容量或性能规划不足直接相关：
| 故障类型 | 典型现象 | 根因分析 | 影响范围 |
|---|---|---|---|
| 节点磁盘压力 | Pod被驱逐（Evicted）、节点状态为DiskPressure | 容器日志、镜像层、EmptyDir临时数据占满系统盘 | 单节点所有Pod |
| PVC容量耗尽 | 应用只读、数据库写入失败、Pod CrashLoopBackOff | PV实际容量小于应用数据增长速率，未设置配额或监控 | 单个有状态应用 |
| 存储后端性能瓶颈 | I/O延迟飙升、kubelet挂载超时、AttachDetach操作卡死 | 后端存储（如NFS、Ceph、云盘）IOPS或吞吐量达到上限 | 共享同一存储后端的所有应用 |
| PV回收失败 | PVC删除后PV无法释放，资源泄漏 | ReclaimPolicy设置不当或存储插件残留数据 | 集群可用存储池逐渐萎缩 |
1.3 故障案例深度复盘
案例一：日志洪流导致节点“假死”
场景： 某微服务应用在促销活动期间日志量暴增100倍，Pod的stdout日志被kubelet写入宿主机/var/log/pods目录。由于节点系统盘仅分配了40GB，且未配置日志轮转，系统盘在15分钟内被写满。
后果： 节点触发DiskPressure，kubelet开始驱逐Pod；由于该节点运行着多个核心服务，驱逐导致级联故障，最终集群部分服务不可用。
教训： 必须为系统盘预留足够的缓冲空间（建议≥20%），并配置日志轮转策略（如logrotate或容器运行时参数）。
案例二：数据库PVC“静默”写满
场景： 一个MySQL有状态集使用20GB的PVC存储binlog和业务数据。运维团队未设置存储配额和监控告警。随着业务增长，binlog在3天内填满了整个卷，数据库进入只读模式，导致上游服务大面积报错。
后果： 恢复过程需要手动扩容PVC、重建Pod并回放binlog，整体恢复耗时超过2小时。
教训： 有状态应用必须设置PVC使用率告警（如≥80%触发），并提前规划扩容流程。
1.4 存储容量规划的核心维度
有效的容量规划需要从以下四个维度进行量化评估，缺一不可：
- 容量维度： 应用数据总量 + 日志/临时数据 + 快照/备份空间 + 预留缓冲（通常建议额外预留30%~50%）。
- 性能维度： 顺序/随机读写IOPS、吞吐量（MB/s）、延迟要求（ms级）。
- 扩展维度： 存储后端是否支持在线扩容？扩容步长是多少？扩容是否导致业务中断？
- 生命周期维度： 数据保留周期、备份策略、回收策略（Retain/Delete/Recycle）。
💡 规划公式： 集群总存储需求 = Σ(应用数据量 × 副本数 × (1 + 冗余系数)) + 系统预留 + 日志/监控存储 + 临时构建缓存。
1.5 存储故障与规划缺失的关系图
下图展示了从“规划缺失”到“典型故障”的因果链路，帮助理解为什么容量规划必须前置：
1.6 课程核心目标
通过本课程，你将掌握以下能力，从而彻底告别“存储救火队”的工作模式：
- 量化评估： 能够根据应用类型（数据库、消息队列、AI训练、日志系统）准确估算存储容量和性能需求。
- 集群资源估算： 从PVC数量、副本因子、存储后端开销到节点磁盘预留，建立完整的集群存储资源计算模型。
- 规划与扩容策略： 制定合理的存储配额、监控阈值、扩容流程和备份恢复方案。
- 故障预防： 通过容量规划提前识别风险点，避免DiskPressure、PVC写满等常见故障。
📌 课前思考： 你的集群中是否已经发生过因存储容量不足导致的故障？当时是如何恢复的？如果提前做了容量规划，是否可以避免？带着这些问题开始本课程的学习，效果会更好。