为什么 Kubernetes 需要 PV 和 PVC
容器本身强调可重建，但业务数据不能随 Pod 删除而消失。Kubernetes 为了解决有状态应用的数据持久化问题，引入了 PV 和 PVC 这两个核心对象。
PV 是 PersistentVolume，代表集群中一块已经准备好的持久化存储资源；PVC 是 PersistentVolumeClaim，代表应用对存储资源的申请。应用不需要关心底层是云硬盘、NFS、Ceph 还是其他存储，只需要声明容量、访问模式和存储类型，由平台完成匹配或动态创建。
可以把 PV 理解为“平台提供的存储资源”，PVC 理解为“应用提交的存储需求”。这种抽象让应用部署和底层存储解耦，是 Kubernetes 持久化存储的基础。
PV、PVC、StorageClass 的职责
PV、PVC 和 StorageClass 经常一起出现，但职责不同：
- PV：描述一块可用存储资源，包括容量、访问模式、回收策略和后端路径。
- PVC：描述应用希望申请的存储，包括容量、访问模式和可选的存储类。
- StorageClass：描述如何动态创建 PV，包括 provisioner、参数和绑定策略。
如果没有 StorageClass，管理员通常需要提前创建 PV；如果有动态供给能力，用户提交 PVC 后，系统可以自动创建匹配的 PV。
一个简单的 PVC 示例
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: app-data
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 20Gi
storageClassName: standardPod 中引用该 PVC：
volumes:
- name: data
persistentVolumeClaim:
claimName: app-data应用真正看到的是挂载目录，PVC 背后的存储资源则由 Kubernetes 和存储插件处理。这种方式让应用 YAML 更稳定，也便于平台统一管理存储配额与类型。
动态供给是怎么工作的
动态供给的典型流程是：用户创建 PVC，控制器发现没有现成 PV 满足条件，于是根据 StorageClass 调用 CSI 插件创建后端存储，再生成 PV 并与 PVC 绑定。绑定完成后，Pod 才能把卷挂载进容器。
动态供给的价值在于减少人工准备 PV 的工作量，也能让不同业务按需申请不同等级的存储。例如普通应用使用标准云盘，数据库使用高性能存储，归档任务使用低成本存储。对于平台团队来说，StorageClass 是把存储能力产品化的重要入口。
访问模式和回收策略
访问模式常见有三类：ReadWriteOnce 表示单节点读写；ReadOnlyMany 表示多节点只读；ReadWriteMany 表示多节点读写。不是所有后端存储都支持所有模式，尤其是 ReadWriteMany 通常需要共享文件系统或特定分布式存储支持。
回收策略主要包括 Retain 和 Delete。Retain 表示 PVC 删除后 PV 和后端数据保留，需要人工处理；Delete 表示 PVC 删除后底层存储也可能被删除。生产环境要特别谨慎，核心业务数据不应因为误删 PVC 就不可恢复。
如果你正在做更完整的 Kubernetes 生产实践，可以结合 Kubernetes 最佳实践相关内容继续扩展存储、网络和发布治理能力。
常见 Pending 问题
PVC 长时间 Pending 是最常见的入门问题。排查时可以按下面顺序看：
- StorageClass 是否存在。
- PVC 请求的容量和访问模式是否被支持。
- CSI 插件是否正常运行。
- 后端存储配额是否充足。
- 绑定模式是否等待 Pod 调度后再创建。
常用命令：
kubectl get pvc,pv,storageclass
kubectl describe pvc app-data
kubectl get pods -n kube-system | grep csi
如果 PVC 已经 Bound，但 Pod 无法启动，则要继续看挂载事件、节点插件、权限、文件系统格式和后端存储可达性。存储问题经常跨越 Kubernetes 对象、节点组件和外部存储系统，不能只看一个事件就下结论。
有状态应用使用建议
数据库、消息队列、对象网关这类应用使用 PVC 时，建议优先配合 StatefulSet，而不是普通 Deployment。StatefulSet 能提供稳定网络身份和稳定存储绑定，更适合有状态副本管理。
同时要注意：PVC 解决的是数据持久化入口，不等于完整高可用。数据一致性、主从复制、备份恢复、扩容缩容和灾难恢复仍然要由应用架构和存储系统共同承担。
总结
PV 和 PVC 的核心价值，是把“应用需要存储”和“平台提供存储”解耦。PVC 负责声明需求，PV 负责承载资源，StorageClass 负责动态供给。理解这三者关系后，Kubernetes 持久化存储就不再只是 YAML 配置，而是一套围绕资源申请、绑定、挂载、回收和治理的完整机制。
常见问题
PV 和 PVC 为什么要分开设计？
PV 表示集群中的存储资源，PVC 表示工作负载对存储的声明。分离后，应用开发者只需要声明容量和访问模式，平台侧负责提供具体存储实现，从而降低应用和底层存储的耦合。
PVC 一直 Pending 应该怎么排查？
先看 PVC 事件，确认是否存在匹配的 StorageClass、容量、访问模式和可用 PV；如果是动态供给，还要检查 CSI 插件、存储后端配额和权限。很多 Pending 问题不是应用错误，而是存储供给链路没有满足声明条件。
PV/PVC 适合所有有状态服务吗？
不一定。PV/PVC 提供持久化存储抽象，但数据库、消息队列等有状态服务还需要考虑一致性、备份、拓扑分布、故障恢复和升级策略。存储卷只是基础能力，不等于完整的有状态应用治理。
转载请注明出处：https://www.cloudnative-tech.com/p/7351/
