1. Kubernetes 存储架构总览：存储核心组件（PV、PVC、StorageClass）的关系与设计哲学
1.1 存储抽象层：从物理到逻辑的映射
Kubernetes 的存储体系并非直接暴露底层存储设备，而是通过三层抽象模型将存储资源的供给与消费解耦。这种设计使得集群管理员与应用开发者可以各司其职，无需互相依赖底层细节。
核心设计哲学： 存储是基础设施，应用不应感知具体实现。PV 代表存储资源，PVC 代表资源请求，StorageClass 代表资源模板。
1.2 三大核心组件定义与职责
| 组件 | 全称 | 角色 | 生命周期 | 创建者 |
|---|---|---|---|---|
| PV | PersistentVolume | 存储资源实例（类似物理磁盘） | 独立于 Pod，可持久存在 | 集群管理员 |
| PVC | PersistentVolumeClaim | 存储资源请求（类似订单） | 与 Pod 绑定，Pod 删除后可能保留 | 应用开发者 |
| StorageClass | StorageClass | 存储类模板（类似商品目录） | 全局资源，长期存在 | 集群管理员 |
1.3 三组件协作流程
- 管理员预置 PV：手动创建或通过 StorageClass 动态供给。
- 开发者声明 PVC：指定所需存储大小、访问模式（ReadWriteOnce / ReadOnlyMany / ReadWriteMany）。
- Kubernetes 控制平面匹配：寻找满足 PVC 需求的 PV，或触发 StorageClass 动态创建新 PV。
- Pod 挂载使用：Pod 通过 volume 字段引用 PVC，系统将 PV 挂载到容器路径。
- 回收策略执行：PVC 删除后，PV 按 Retain / Delete / Recycle 策略处理。
最佳实践： 生产环境强烈推荐使用 StorageClass 动态供给，避免管理员手动管理 PV 池。仅特殊场景（如已有 NFS 共享、遗留存储）才使用静态 PV。
1.4 三组件关系架构图
1.5 访问模式与回收策略
PV 和 PVC 的匹配不仅依赖容量大小，还依赖访问模式的兼容性。Kubernetes 定义了三种标准访问模式：
- ReadWriteOnce（RWO）：单节点读写挂载，大多数块存储（如 AWS EBS、GCE PD）默认模式。
- ReadOnlyMany（ROX）：多节点只读挂载，适用于共享配置或静态数据。
- ReadWriteMany（RWX）：多节点读写挂载，仅 NFS、CephFS、GlusterFS 等网络文件系统支持。
常见陷阱： 许多用户误以为 PVC 可以绑定到任意 PV。实际上，PVC 的访问模式必须与 PV 完全匹配，且 PV 的剩余容量必须 ≥ PVC 请求容量。不匹配时 PVC 将保持 Pending 状态。
1.6 动态供给 vs 静态供给对比
| 维度 | 静态供给（Static Provisioning） | 动态供给（Dynamic Provisioning） |
|---|---|---|
| PV 创建方式 | 管理员手动创建 PV 对象 | StorageClass 自动创建 PV |
| 适用场景 | 已有外部存储（如 NFS 共享、iSCSI LUN） | 云存储（AWS EBS、GCE PD、Azure Disk） |
| 灵活性 | 低，需要预先规划容量 | 高，按需创建，自动回收 |
| 管理成本 | 高，需持续维护 PV 池 | 低，只需配置 StorageClass 参数 |
| 回收策略 | 通常 Retain（保留数据） | 通常 Delete（自动删除底层存储） |
1.7 设计哲学总结
Kubernetes 存储架构的三大设计原则：
- 关注点分离：管理员管资源（PV/StorageClass），开发者管需求（PVC），互不侵入。
- 声明式接口：用户只需声明“我需要多少存储、什么访问模式”，系统自动完成匹配与供给。
- 可插拔后端：通过 CSI（Container Storage Interface）和 StorageClass 参数，同一套 API 可对接数十种存储后端。