2. K8s存储选型：PV/PVC基础、StorageClass配置、本地存储 vs 网络存储、性能对比分析
聊到vLLM的模型缓存，存储选型是个绕不开的话题。我见过不少团队，模型推理的代码写得漂漂亮亮，结果卡在I/O上，加载一个70B的模型要等半小时。说白了，存储没选对，后面全是坑。
这一章，咱们就掰开揉碎，把K8s里的存储选型讲清楚。我会结合自己踩过的坑，帮你理清PV/PVC、StorageClass，以及本地存储和网络存储的取舍。
2.1 PV/PVC基础：别被概念绕晕
先说说PV和PVC。这两个概念，刚接触K8s的人容易搞混。我刚开始也犯过这毛病，以为PV就是硬盘，PVC就是申请单。嗯，这么理解其实也没错，但不够准确。
PV（PersistentVolume），是集群管理员预先准备好的一块存储资源。它可以是NFS、Ceph、本地磁盘，甚至是云上的EBS。PV的生命周期独立于Pod，Pod挂了，PV还在。
PVC（PersistentVolumeClaim），是用户对存储的请求。你告诉K8s：我要5GB的存储，访问模式是ReadWriteOnce。K8s就会去找一个满足条件的PV，绑定到一起。
这里有个关键点：PVC和PV的绑定是一对一的。一个PVC只能绑定一个PV，绑定后其他Pod就不能再用这个PV了。除非你把PVC删掉，或者PV的回收策略允许重新绑定。
核心概念速记：
- PV = 存储资源（管理员视角）
- PVC = 存储请求（用户视角）
- 绑定关系：PVC → PV（一对一）
- 生命周期：PV独立于Pod
举个例子，你部署vLLM时，模型文件可能放在一个共享存储上。这时候你写一个PVC，声明需要100GB的存储空间，访问模式是ReadOnlyMany（多个Pod同时读）。K8s就会自动匹配一个满足条件的PV。
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: model-cache-pvc
spec:
accessModes:
- ReadOnlyMany
resources:
requests:
storage: 100Gi
storageClassName: fast-nvme
这段YAML，说白了就是告诉K8s：我要100GB的只读存储，而且要用fast-nvme这个StorageClass。至于底层是本地SSD还是网络盘，由StorageClass决定。
2.2 StorageClass配置：动态供给的秘密
手动创建PV再绑定PVC，在小规模集群里还行。一旦节点多了，模型版本迭代频繁了，手动管理PV就是噩梦。这时候就需要StorageClass出场了。
StorageClass的作用，就是实现动态供给。你只需要定义好PVC，K8s会自动根据StorageClass的配置，创建对应的PV并绑定。整个过程自动化，省心省力。
我个人习惯，在生产环境里一定会用StorageClass。原因很简单：模型缓存的大小和数量是动态变化的。今天缓存一个7B模型，明天可能换成13B的，手动管理PV根本跟不上节奏。
来看一个StorageClass的配置示例：
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: fast-nvme
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer
这里有个细节：volumeBindingMode: WaitForFirstConsumer。什么意思呢？就是PV不会提前创建，而是等到第一个Pod调度到某个节点后，才在那个节点上创建PV。这对本地存储特别重要，因为本地存储是跟节点绑定的。
避坑指南：我曾经在配置本地SSD的StorageClass时，忘了加WaitForFirstConsumer。结果PV创建在了节点A，Pod却调度到了节点B，数据根本读不到。嗯，这个坑踩过一次就记住了。
对于网络存储（比如NFS、Ceph），volumeBindingMode可以设为Immediate。因为网络存储不依赖具体节点，PV可以提前创建好，Pod调度到任何节点都能访问。
2.3 本地存储 vs 网络存储：性能与灵活性的博弈
这是存储选型的核心问题。vLLM加载模型时，I/O性能直接决定了启动速度。你想想看，一个70B的模型，文件大小可能超过140GB。如果存储的吞吐量不够，加载时间会非常夸张。
我做个对比表格，方便你直观理解：
| 特性 | 本地存储（Local SSD/NVMe） | 网络存储（NFS/Ceph/GlusterFS） |
|---|---|---|
| 读写延迟 | 极低（微秒级） | 较高（毫秒级） |
| 吞吐量 | 极高（数GB/s） | 受网络带宽限制 |
| 数据共享 | 不支持跨节点共享 | 支持多节点同时读写 |
| 数据持久性 | 节点故障后数据丢失 | 数据独立于节点，更可靠 |
| 运维复杂度 | 低（直接挂载磁盘） | 高（需要维护存储集群） |
| 适用场景 | 模型缓存、高频读取 | 模型分发、多副本共享 |
看到这个表格，你可能会问：那到底选哪个？我的建议是：看你的模型加载频率和集群规模。
- 如果模型加载频繁（比如每天多次重启Pod），本地存储是首选。加载速度能快一个数量级。
- 如果模型需要多节点共享（比如多个推理Pod共用同一个模型文件），网络存储更合适。虽然慢一点，但省去了数据拷贝的麻烦。
- 如果集群规模很大（几十个节点），网络存储的运维成本会很高。这时候可以考虑本地存储 + 数据预拉取的方案。
注意：本地存储有个致命问题——节点故障。如果节点宕机，本地磁盘上的模型缓存就全丢了。所以，本地存储只适合做缓存，不适合做持久化存储。模型文件的原始副本，一定要放在可靠的地方（比如对象存储或分布式文件系统）。
2.4 性能对比分析：数据说话
光说理论不够，咱们看一组实际测试数据。我在一个测试集群里，分别用本地NVMe和NFS加载同一个70B模型（约140GB），记录加载时间。
| 存储类型 | 顺序读吞吐量 | 模型加载时间（70B） | CPU使用率 |
|---|---|---|---|
| 本地NVMe（单盘） | 3.5 GB/s | 40秒 | 低 |
| 本地SATA SSD | 550 MB/s | 4分15秒 | 中 |
| NFS（万兆网络） | 800 MB/s | 2分55秒 | 高（网络协议开销） |
| Ceph（万兆网络） | 600 MB/s | 3分50秒 | 高 |
看到差距了吧？本地NVMe比NFS快了4倍多。如果你的推理服务对启动时间敏感（比如需要快速扩容应对流量高峰），本地存储的优势非常明显。
但话说回来，NFS也有它的价值。我记得有一次，我们需要在10个节点上同时部署同一个模型。如果用本地存储，每个节点都得单独拷贝一次模型文件，耗时不说，还容易出错。用NFS的话，一个副本挂上去，所有节点都能读，省事多了。
2.5 知识体系总览
为了让你更直观地理解本章的知识结构，我画了一张图：
这张图把本章的核心逻辑串起来了。从存储选型决策出发，三个分支分别对应PV/PVC基础、StorageClass配置、本地 vs 网络存储。最下面给出了决策逻辑和性能数据，方便你快速回顾。
2.6 实战建议：我的选型清单
最后，我分享一下自己在实际项目中的选型清单。每次做存储选型时，我都会按这个顺序过一遍：
- 先看模型大小：如果模型超过50GB，优先考虑本地NVMe。加载时间差距太大了。
- 再看节点数量：如果只有3-5个节点，本地存储 + 手动拷贝模型文件也能接受。超过10个节点，必须上网络存储或自动化分发工具。
- 然后看数据持久性要求：模型缓存丢了可以重新下载，所以本地存储没问题。但如果是训练数据或日志，必须用网络存储或对象存储。
- 最后看运维能力：如果团队没有专门的存储运维人员，尽量选云服务商提供的托管存储（比如AWS EFS、Azure Files），别自己搭Ceph。
一个小技巧：我习惯在PVC里加上selector字段，手动指定PV的标签。这样能确保PVC绑定到预期的PV上，避免K8s自动匹配到不合适的存储。尤其是在混合使用本地存储和网络存储的集群里，这个技巧很实用。
好了，存储选型这部分就聊到这儿。下一章咱们会深入讲模型缓存的生命周期管理，包括缓存预热、淘汰策略和一致性保证。到时候再结合存储选型，把整个缓存体系搭起来。