PV是集群级存储资源，PVC是命名空间级存储申请；PV由管理员配置或StorageClass动态创建，PVC通过匹配capacity、accessModes、storageClassName绑定PV；绑定一对一，Pod通过挂载PVC使用PV。
PV（PersistentVolume）和PVC（PersistentVolumeClaim）是 Kubernetes 中实现数据持久化的基础机制。容器默认是无状态的，重启或调度后数据会丢失，而 PV/PVC 提供了一种解耦存储供应与使用的抽象方式，让应用无需关心底层存储细节，也能可靠保存数据。
理解 PV 和 PVC 的角色分工
PV 是集群级别的资源，代表一块真实可用的网络存储（如 NFS、Ceph、云厂商的 EBS/EVS/Cloud Block Storage），由管理员预先配置或通过 StorageClass 动态创建；PVC 是命名空间级的“申请”，描述应用需要多大容量、什么访问模式（ReadWriteOnce / ReadOnlyMany / ReadWriteMany）、什么存储类等需求，Kubernetes 会自动将其绑定到匹配的 PV 上。
- PV 是“存储本身”，生命周期独立于 Pod，可被复用或回收
- PVC 是“存储租约”，Pod 通过挂载 PVC 来使用对应 PV 的空间
- 绑定关系是一对一的，一个 PVC 只能绑定一个 PV，一个 PV 一次只能被一个 PVC 绑定（除非是 ReadOnlyMany 模式且多 PVC 同时只读）
手动创建 PV 和 PVC 的典型流程
适用于 NFS、本地路径（测试用）等静态供应场景：
- 先定义 PV YAML：指定 capacity、accessModes、persistentVolumeReclaimPolicy（Retain / Recycle / Delete）、storageClassName 和实际后端参数（如 nfs.path 和 nfs.server）
- 再定义 PVC YAML：声明 resources.requests.storage、accessModes、storageClassName（需与 PV 一致），提交后等待 Bound 状态
- 在 Pod 或 StatefulSet 中通过 volumes[].persistentVolumeClaim.claimName 引用 PVC，再在 containers[].volumeMounts 中挂载
注意：若 storageClassName 为空，表示使用默认 StorageClass 或进入“无类”静态绑定模式；不匹配会导致 PVC 长期处于 Pending 状态。
用 StorageClass 实现动态存储供应
避免手动管理 PV，尤其在公有云或 Ceph RBD 等支持动态卷的环境中更实用：
- 创建 StorageClass 对象，关联 provisioner（如 kubernetes.io/aws-ebs、kubernetes.io/cinder、rook-ceph.rbd.csi.ceph.com）并配置参数（如 type: gp3、pool: replicapool）
- PVC 中指定 storageClassName，并设置 volumeMode（Filesystem 或 Block）和 dataSource（用于克隆或快照）
- Kubernetes 调用对应 provisioner 自动创建 PV 并完成绑定，整个过程无需人工干预
StorageClass 还可控制回收策略（reclaimPolicy）、是否允许卷扩容（allowVolumeExpansion: true）等关键行为。
常见问题与排查要点
当 PVC 卡在 Pending 或 Pod 报错 MountVolume.SetUp 失败时，优先检查：
- kubectl get pv,pvc 查看状态和事件（kubectl describe pvc xxx）
- 确认 PV 容量、访问模式、storageClassName 是否与 PVC 完全匹配
- 检查底层存储服务是否可达（如 NFS server 是否运行、权限是否正确；Ceph monitor 是否健康）
- 查看 provisioner Pod 日志（如 csi-provisioner、rook-ceph-operator）是否有报错
- 确认节点是否安装了对应插件（如 nfs-common、ceph-common 或 CSI Node Driver）
对于 StatefulSet 场景，建议配合 volumeClaimTemplates 使用，可自动为每个副本生成带序号的 PVC，天然支持有序部署与数据隔离。
