3. 应用存储需求分析：从应用类型推导存储需求
在 Kubernetes 集群中，存储容量规划的第一步并非直接计算集群总容量，而是从应用本身出发。应用的类型——有状态还是无状态——直接决定了其对存储的依赖程度和需求特征。本节将建立从应用类型到存储需求（容量、IOPS、吞吐量）的推导模型。
3.1 应用类型与存储依赖矩阵
有状态应用与无状态应用在存储需求上存在本质差异。下表总结了核心区别：
| 对比维度 | 无状态应用 | 有状态应用 |
|---|---|---|
| 数据持久性 | 不需要持久存储，Pod 重启后数据可丢失 | 必须持久化数据，Pod 重启后数据需保留 |
| 存储类型 | 通常仅使用临时卷（emptyDir）或 ConfigMap | 使用 PersistentVolume（PV），如块存储、文件存储 |
| 容量需求 | 极小（通常 < 1 GiB），用于缓存或日志 | 较大（数 GiB ~ 数 TiB），取决于数据规模 |
| IOPS 需求 | 低，偶发读写 | 高，持续随机读写或顺序读写 |
| 吞吐量需求 | 低，通常 < 10 MB/s | 高，可达数百 MB/s 甚至 GB/s |
| 典型场景 | Web 前端、API 网关、批处理任务 | 数据库、消息队列、分布式文件系统、AI 训练 |
规划要点： 无状态应用的存储需求通常可以忽略不计，但需注意其临时卷的磁盘空间可能影响 Pod 调度。有状态应用才是容量规划的核心对象，需要逐类分析。
3.2 有状态应用存储需求推导模型
对于有状态应用，存储需求由三个核心指标构成：容量、IOPS 和 吞吐量。推导过程遵循“应用特征 → 工作负载模型 → 指标计算”的路径。
下图展示了从应用类型到存储需求的推导流程：
3.3 容量需求推导方法
容量需求是存储规划的基础指标。推导公式如下：
容量需求 = 数据基数 + 数据增长量 + 冗余系数 + 系统开销
其中：
- 数据基数：应用初始数据量（如数据库初始大小、文件存储总量）
- 数据增长量：按日/月/年增长率计算，通常取 30%~100% 作为规划周期内的增长
- 冗余系数：副本数、备份空间、快照空间，通常为 1.5x ~ 3x
- 系统开销：日志、临时文件、元数据，通常为 5%~10%
实战案例： 某电商平台订单数据库，当前数据量 500 GiB，月增长 10%，规划周期 12 个月，副本数 2，备份保留 7 天。计算：
数据基数 = 500 GiB
增长后 = 500 × (1 + 0.1)^12 ≈ 1569 GiB
冗余系数 = 2（副本）× 1.2（备份） = 2.4
容量需求 ≈ 1569 × 2.4 × 1.05（系统开销）≈ 3954 GiB ≈ 4 TiB
数据基数 = 500 GiB
增长后 = 500 × (1 + 0.1)^12 ≈ 1569 GiB
冗余系数 = 2（副本）× 1.2（备份） = 2.4
容量需求 ≈ 1569 × 2.4 × 1.05（系统开销）≈ 3954 GiB ≈ 4 TiB
3.4 IOPS 需求推导方法
IOPS（每秒输入输出操作数）反映存储系统的随机读写能力。推导步骤：
- 识别读写比例： 典型数据库读写比 70:30（读多写少），日志系统 90:10，视频监控 10:90（写多读少）。
- 估算并发数： 应用的最大并发连接数或线程数。
- 计算单次 IO 大小： 数据库通常 4 KiB ~ 16 KiB，文件系统 64 KiB ~ 1 MiB。
- 计算总 IOPS： 总 IOPS = 并发数 × 每并发 IOPS × 峰值系数（通常 1.5 ~ 3）。
示例：PostgreSQL 数据库，并发 100，每并发 20 IOPS，峰值系数 2
总 IOPS = 100 × 20 × 2 = 4000 IOPS3.5 吞吐量需求推导方法
吞吐量（MB/s）反映存储系统的顺序读写能力。与 IOPS 的关系：
吞吐量 (MB/s) = IOPS × 单次 IO 大小 (KiB) / 1024
示例：4000 IOPS × 16 KiB = 64000 KiB/s ≈ 62.5 MB/s对于流式应用（如视频处理、AI 训练），吞吐量是首要指标，IOPS 次之。推导时需关注：
- 顺序读写场景： 吞吐量 = 带宽需求 / 存储效率（通常 0.7 ~ 0.9）
- 混合场景： 吞吐量 = 随机 IOPS × 块大小 + 顺序带宽
3.6 常见有状态应用存储需求速查表
下表汇总了典型有状态应用的存储需求范围，可作为初步估算参考：
| 应用类型 | 容量范围 | IOPS 范围 | 吞吐量范围 | 推荐存储类型 |
|---|---|---|---|---|
| MySQL / PostgreSQL | 50 GiB ~ 2 TiB | 2000 ~ 10000 | 50 ~ 200 MB/s | SSD 块存储 |
| MongoDB / Cassandra | 100 GiB ~ 10 TiB | 5000 ~ 50000 | 100 ~ 500 MB/s | NVMe 块存储 |
| Redis（持久化模式） | 1 GiB ~ 100 GiB | 10000 ~ 100000 | 10 ~ 50 MB/s | 本地 SSD / 内存 |
| Kafka / Pulsar | 500 GiB ~ 50 TiB | 1000 ~ 5000 | 200 ~ 1000 MB/s | HDD 或 SSD 文件存储 |
| Elasticsearch | 200 GiB ~ 20 TiB | 3000 ~ 20000 | 100 ~ 500 MB/s | SSD 块存储 |
| AI 训练（数据加载） | 1 TiB ~ 100 TiB | 500 ~ 2000 | 500 ~ 5000 MB/s | 并行文件系统 |
注意： 上表为经验范围，实际需求需结合应用基准测试（如 fio、sysbench）和业务峰值数据。切勿直接套用，应针对每个应用进行独立评估。
3.7 无状态应用的存储注意事项
虽然无状态应用通常不需要持久存储，但以下场景仍需关注：
- 日志收集： 使用 emptyDir 卷时，需确保节点有足够磁盘空间（通常预留 10~20 GiB 每节点）。
- 缓存数据： 如使用 emptyDir 作为缓存，需根据缓存大小设置卷容量限制（通过 sizeLimit 参数）。
- ConfigMap/Secret： 挂载为卷时，Kubernetes 会消耗节点内存，需注意节点资源规划。
下图展示了无状态应用在存储方面的典型架构：
3.8 推导总结与检查清单
完成应用存储需求分析后，建议使用以下清单进行复核：
- ☐ 是否已区分有状态与无状态应用？
- ☐ 是否已收集每个有状态应用的数据基数、增长率、副本数？
- ☐ 是否已估算读写比例、并发数、单次 IO 大小？
- ☐ 是否已计算容量、IOPS、吞吐量三个指标？
- ☐ 是否已考虑峰值系数和冗余系数？
- ☐ 是否已参考基准测试数据或历史监控数据？
- ☐ 是否已为无状态应用预留节点磁盘空间？
完成上述分析后，即可进入下一阶段：将单个应用需求汇总为集群级别的资源估算。