pv是集群管理员配置的独立于pod的存储资源，需定义capacity、accessmodes、storageclassname、volumemode和回收策略，并通过hostpath/nfs/csi等后端对接真实存储，静态供给需手动创建并确保与pvc匹配，动态供给则由storageclass自动完成。
配置 PersistentVolume（PV）是 Kubernetes 实现数据持久化的基础环节。它不是直接给 Pod 用的，而是由集群管理员预先准备好的“存储资源池”，供 PVC 按需申请绑定。关键在于明确 PV 的来源、容量、访问方式和回收策略，且必须与 PVC 的请求匹配才能成功绑定。
PV 的核心字段必须配全
PV 是一个独立于 Pod 的集群级资源，YAML 中至少要定义以下几项：
-
capacity.storage：声明可用容量，比如
10Gi，必须是 PVC 请求值的精确匹配或更大 -
accessModes：指定读写权限组合，常见如
ReadWriteOnce（单节点读写）、ReadWriteMany（多节点并发读写），必须与 PVC 一致 - storageClassName：关联对应的 StorageClass，若为空则属于“无类 PV”，只能被未指定 storageClassName 的 PVC 绑定
-
volumeMode：默认
Filesystem；若后端支持块设备（如 AWS EBS），可设为Block -
回收策略（persistentVolumeReclaimPolicy）：决定 PV 被释放后的处理方式，
Retain（手动清理）、Delete（自动删除底层存储）、Recycle（已弃用）
根据存储类型选择 backend 配置
PV 本身不提供存储，只是对接真实后端的抽象。不同后端写法差异大，常见几种：
Kubernetes Security Posture Scorecard
下载
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
-
hostPath：仅用于单节点开发/测试，指定节点本地路径，如
path: /mnt/data；生产环境禁用 -
local：比 hostPath 更规范的本地盘，需配合
nodeAffinity确保 Pod 调度到对应节点，适合高性能本地 SSD -
nfs：填
server地址和path，适用于共享文件系统场景 -
CSI 驱动后端（如 aws-ebs、gce-pd、cephfs）：通过
csi.driver和volumeAttributes描述，依赖已安装的 CSI 插件
静态 PV 需手动创建并确保状态可用
管理员执行 kubectl apply -f pv.yaml 后，PV 进入 Available 状态才可被 PVC 绑定。常见失败原因：
- 节点上
hostPath或local.path不存在或权限不足 - NFS server 不可达，或 export 权限未开放（如缺少
no_root_squash） - accessModes 或 storageClassName 与 PVC 不匹配，导致始终处于
Pending - 容量小于 PVC request，例如 PVC 申 10Gi，PV 只有 5Gi
动态供应更推荐，但 PV 仍由系统自动创建
真正需要你“配置 PV”的场景，其实是定义好 StorageClass 并启用动态供应。此时无需手写 PV YAML —— 当 PVC 创建时，Kubernetes 会按 StorageClass 中指定的 provisioner（如 ebs.csi.aws.com）自动调用云厂商 API 创建 PV，并完成绑定。你只需确保：
- StorageClass 已存在且
provisioner字段正确 - PVC 显式设置
storageClassName指向该 SC - 底层存储插件（如 CSI Driver）已部署并运行正常
