第七章 k8s 存储：PV/PVC 详解
前置概念回顾
- Volume（卷）：用于解决Pod重建后容器内部文件丢失的问题，是容器持久化存储的基础概念。但规模化场景下，多Pod与多存储的绑定关系极为复杂，人工管理成本极高，因此需要更抽象的存储管理机制。
PV/PVC 的诞生背景
- 规模化企业中团队分工高度细化，各团队职责明确：
- 基础设施部门：负责维护Linux系统、物理机、Kubernetes集群，完成集群扩容、资源回收等底层基础设施工作。
- 存储部门：负责管理各类存储资源，包括EMC2、Ceph、MFS、NFS、iSCSI等，负责存储硬件状态监控、容量管理、故障恢复等工作。
- 业务部门：需要同时理解Kubernetes平台、存储特性、业务代码逻辑，才能编写资源清单、完成代码部署，跨部门沟通成本极高。
- 为降低跨部门沟通成本，实现业务与存储的解耦，Kubernetes官方提出了PV（持久卷）、PVC（持久卷申请）的抽象机制。
核心概念与绑定逻辑
核心定义
- PVC（PersistentVolumeClaim，持久卷申请）：由业务部门创建，用于声明业务对存储的需求，核心属性包括存储容量、读写策略（单节点读写、多节点只读、多节点读写）、存储类型、回收策略等。
- PV（PersistentVolume，持久卷）：由存储部门创建，是将后端各类存储资源抽象为Kubernetes集群内的存储对象，每个PV对应一份后端存储资源，自带容量、读写策略、存储类型等属性。
绑定流程
PVC与PV的绑定分为预选和优选两个阶段：
- 预选阶段：筛选出满足PVC基本要求的PV，要求包括：容量≥需求、读写策略匹配、存储类型匹配，不满足要求的PV直接淘汰。
- 优选阶段：在满足预选条件的PV中，选择最优的PV，优先选择容量最接近需求、资源浪费最少的PV（例如需求为5GB时，5GB的PV优先级高于6GB、4GB的PV）。
绑定成功后，Pod直接绑定PVC，即可使用后端对应的存储资源，无需关心存储的具体实现细节。
机制价值
- 实现业务侧与存储侧的完全解耦：业务侧只需声明存储需求，无需和后端存储团队逐一沟通对接；存储侧只需负责维护PV资源，无需关心业务的具体使用场景。
- 仅当业务所需的存储类型无对应PV时，才需要跨部门沟通创建对应PV，大幅降低沟通与管理成本。
AI 总结
本小节主要讲解了Kubernetes中PV/PVC机制的设计背景、核心概念与绑定逻辑，该机制通过抽象存储资源，实现了业务团队与存储团队的解耦，大幅降低了规模化集群下多Pod与多存储绑定的管理成本，是K8s存储体系的核心设计之一，帮助业务侧无需关心底层存储细节即可便捷使用持久化存储。、Kubernetes集群，完成集群扩容、资源回收等底层基础设施工作。
- 存储部门：负责管理各类存储资源，包括EMC2、Ceph、MFS、NFS、iSCSI等，负责存储硬件状态监控、容量管理、故障恢复等工作。
- 业务部门：需要同时理解Kubernetes平台、存储特性、业务代码逻辑，才能编写资源清单、完成代码部署，跨部门沟通成本极高。
- 为降低跨部门沟通成本，实现业务与存储的解耦，Kubernetes官方提出了PV（持久卷）、PVC（持久卷申请）的抽象机制。