云原生从容器化部署走进规模化生产后，存储成了有状态应用和数据密集型负载的争夺焦点。AI 训练场景把矛盾推到极致：数十 GB/s 的聚合读吞吐、毫秒级的检查点写入、PB 级容量，还要在成本上说得过去。把 CSI 接口演进和万卡集群的分层设计放在一起看，才知道标准化的接口层是这一切的地基。
CSI 解决了什么
CSI 出现之前，Kubernetes 用 in-tree 插件对接各家存储：厂商代码要合进主干仓库，发布节奏被绑死在 K8s 版本上，插件与核心组件耦合出大量稳定性风险。CSI 把存储能力抽象成三组 gRPC 服务——Identity 声明驱动身份与能力，Controller 管卷的创建删除快照，Node 负责节点侧挂载卸载。厂商实现一套驱动，任何支持 CSI 的编排系统都能复用。
apiVersion: storage.k8s.io/v1
kind: CSIDriver
metadata:
name: example.csi.driver
spec:
attachRequired: true
podInfoOnMount: true
volumeLifecycleModes:
- Persistent
- Ephemeral
配合 csi-provisioner、csi-attacher、csi-snapshotter 这些 sidecar 容器，控制面形成完整闭环。部署驱动时先核对 CSIDriver 对象的能力声明，attachRequired 与 podInfoOnMount 的取值直接影响调度行为——声明与实际能力不符，问题会在挂载阶段以最难排查的形式暴露。
增量快照：检查点场景的刚需
传统全量快照在训练集群上不可持续：频繁全量备份拖垮训练效率，存储成本也失控。社区推进的 Changed Block Tracking API 用变更位图记录数据块差异，支持查询自上次快照以来的变更块列表、按变更块创建增量快照。落到 AI 场景就是三件事：备份窗口缩短、空间利用率上升、恢复点目标可以设得更密。训练中断后回滚到最近检查点，靠的就是这套机制。
验收增量快照能力别只看功能开关：用 kubectl get volumesnapshotcontents 核对实际快照链，再对恢复出的卷跑数据校验（比对文件数与关键校验和），恢复路径没实测过的快照能力等于没有。
AI 负载的四个特征与分层对策
大模型训练的存储画像很特殊。训练数据以顺序读为主，要求聚合吞吐；检查点以突发大块写为主，对延迟抖动敏感；日志与元数据是小文件随机访问；多租户还要 QoS 隔离。单一存储系统同时满足四项不现实，分层是唯一解：NVMe 全闪扛热数据与活跃检查点，SSD/HDD 混合层接低频历史数据，对象存储做归档与长期版本保留。文件系统选 Lustre、GPFS 或 JuiceFS 这类支持高并发读写的并行文件系统，经 CSI 驱动接入集群。
容量规划按最坏情况算：万卡集群的参数、数据、日志、中间结果合计奔着 PB 级去，控制面与数据面分离才能弹性扩容。落地路径建议先千卡规模验证全套链路，把检查点写入耗时、数据加载等待时间盯出基线，再扩到万卡——存储瓶颈在千卡时就会显形，不必等万卡才暴露。
COSI 补上对象存储的缺口
块和文件存储有 CSI，对象存储的 Bucket 语义却不适合 PersistentVolume 抽象。COSI（容器对象存储接口）用三件套补位：BucketClaim 声明请求、Bucket 是实际资源、BucketAccess 把访问凭证注入 Pod。它已进 CNCF 沙箱，成熟后与 CSI 形成互补——块文件对象三类存储都有标准化接入。数据集分发走对象存储、训练热数据走并行文件系统的组合，会是一段时间内的标准答案。
存储方案没有终局，接口标准化加负载分层这两条主线看清了，后续每次生态演进都知道该往哪里接入。
评论0