Kubernetes 存储体系：从 emptyDir 到 CSI 持久化
背景与问题界定 某在线教育平台的实时录制系统需要在 Kubernetes 上运行——录制器 Pod 必须将音视频切片直接写入持久化存储，同时后端的转码 Worker 要读取这些文件进行 HLS 格式转换。起初团队采用了 StatefulSet 配 emptyDir 的方案，结果 Pod 因节点故障重建后所有录制数据丢失，用户端出现大面积的"回放缺失"投诉。更麻烦的是，跨 AZ 部署时，一个 AZ 中写入的 PV 无法被另一个 AZ 的 Pod 挂载，导致转码系统只能在本地读取而无法负载均衡。Kubernetes 的存储体系从 ephemeral 到持久化、从静态绑定到动态供给、从本地磁盘到分布式存储，是一套分层和扩展性极强的设计，但每个阶梯都有不同的故障模型和性能特征。 目标拆解与工程约束 存储生命周期与 Pod 生命周期解耦：Pod 重建后必须能自动挂载到之前写入数据的存储卷，保证有状态服务的"状态"不随 Pod 死亡而消失，同时支持 StatefulSet 的 volumeClaimTemplate 自动创建和绑定 PVC。 跨可用区访问与快照：存储后端必须支持跨 AZ 的 ReadWriteMany（RWX）访问模式——视频文件在一个 AZ 写入后需要被其他 AZ 的 Worker 立即读取，同时支持 CSI Snapshot 机制进行小时级定期快照防止数据损坏。 性能 Predictability：不同业务对存储 IOPS 和 Throughput 的要求差异极大——MySQL 需要低延迟（< 1ms）的块存储，日志系统需要高吞吐的顺序写，AI 训练则需要大带宽的并行文件系统。存储类（StorageClass）必须提供明确的性能分层。 存储成本可视化管理：无限制的 PVC 动态供给可能导致存储成本失控，需要利用 ResourceQuota 和 LimitRange 限制 namespace 级别的存储请求上限，同时通过标签追踪每块 PV 的归属项目。 方案设计 我们设计了四层存储性能分层模型，通过 StorageClass 的参数差异实现不同性能级别的选择： ...