PV/PVC/StorageClass 核心资源完全解读你是不是也遇到过——Pod 重启后数据全没了？PVC 一直报 P

你是不是也遇到过——Pod 重启后数据全没了？PVC 一直报 Pending 不知道咋回事？想用云硬盘结果 Pod 始终调度不到有存储的节点上？

我干了十年 SRE，头三年也被这些问题折磨得够呛。Kubernetes 存储这块是很多刚入门同学的第一道坎——弄懂了高兴得像过年，弄错了整个集群炸掉。今天把 PV、PVC、StorageClass 这几个核心概念掰开揉碎讲清楚，读完这些，你可以：

分清楚静态和动态两种配存方式，什么时候用哪种
自己上手配一套存储（哪怕只是在 minikube 上玩）
搞明白 PVC 卡在 Pending 到底是谁的锅
在大规模集群里少踩几个坑

看这篇文章之前，你至少得：

知道 kubectl 怎么跑，能连上 Kubernetes 集群（我测试用的是 Kubernetes v1.31 和 v1.32，K8s 官方现在推荐的 kubectl 版本策略可以到官方文档核对）
对 namespace 和 Pod 的基础概念有模糊印象，不懂可以去翻 Namespace 概念恶补
最好有个实验环境（minikube 就行，我 MacOS 上能跑通，Linux 也没差）

一、到底谁管谁？三个概念的关系

PV（PersistentVolume） ：集群级别的存储资源，可以理解成管理员提前“买好”的一块盘。定义的是一个持久化存储在宿主机上的目录，比如某个 NFS 挂载点。

PVC（PersistentVolumeClaim） ：开发者对存储的“下单”。声明我需要多少空间、什么访问模式，Kubernetes 帮你匹配现成的 PV，或者让 StorageClass 动态造一个出来。

StorageClass：存储的“模板”或“出货员”。定义用哪个插件（provisioner）、用什么回收策略、绑定模式是即时还是等 Pod 调度再说。

（顺便提一嘴，早期还有 PV 的 Recycle 回收策略，现在已经被标记为弃用了，新版本里别碰它。）

我画了一个调用流程图，虽然不是美术生作品但能看懂：

用户(开发)           管理员
   |                  |
   |  搞一个 PVC       |  预定义 StorageClass
   | --------->        |
   |                  |
   |   k8s 控制器      |
   |   根据 StorageClass
   |   去调用 CSI 插件
   |                  |
   |   <—— 动态创建 PV ——|
   |                  |
   |   Pod 挂载 PVC ——> 能用啦!
   |                  |

二、静态 PV：管理员当苦力，自己绑盘

静态 PV 是每个节点的入⾏配存课。说白了就是：你去云服务商那边开好一个块存储/文件存储，拿到它的 ID 或挂载地址，手写一个 PV 的 YAML 告诉 K8s“这有一块现成的存储”。

PV YAML 长什么样

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-example
spec:
  capacity:
    storage: 10Gi
    accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  nfs:
    server: 192.168.1.100
    path: /exports/data

几个重要字段：

accessModes：ReadWriteOnce（RWO，单节点读写）、ReadOnlyMany（ROX，多节点只读）、ReadWriteMany（RWX，多节点读写）
persistentVolumeReclaimPolicy：PVC 删了后 PV 咋办，后面会讲
storage：容量声明

PVC 申请这块 PV

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 5Gi
  # 不指定 storageClassName 意味着只找静态 PV，或者加 "v" 1.0 版本里使用空字符串表示禁用动态供应
  storageClassName: ""

# 操作
kubectl apply -f pv.yaml
kubectl apply -f pvc.yaml
kubectl get pv,pvc

预期输出里看到的 PVC STATUS 应该是 Bound。如果 Pending，八成是 PV 没匹配上（容量不够、accessMode 不对、标签没对上）。

三、动态 PV：StorageClass 是硬核生产力

动态 PV 是生产环境的标配。你不用去云平台手动开盘，只要写好 StorageClass，PVC 一提交，自动帮你创建对应的存储卷。

StorageClass YAML

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: kubernetes.io/aws-ebs   # 云厂商示例，实际请根据自己后端替换
parameters:
  type: gp3
  fsType: ext4
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer   # 关键参数
allowVolumeExpansion: true                # 允许 PVC 扩容，好功能

provisioner 这里换成你自己的 CSI 驱动名称，比如阿里云是 diskplugin.csi.alibabacloud.com，GKE 里可能是 pd.csi.storage.gke.io。没有 CSI 但手上只有 NFS 服务器？往下彩蛋 1有惊喜。

用 PVC 直接触发动态创建

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: dynamic-pvc
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi
  storageClassName: fast-ssd   # 指向上面那个 StorageClass

kubectl apply -f storageclass.yaml
kubectl apply -f pvc-dynamic.yaml
kubectl get pvc

你会看到 PVC 短时间内变成 Bound，回头看 PV 列表还会多出来一个自动生成的 PV，命名通常是 pvc-xxxx-xxxx。动态配存的魅力就在这里——运维不用手动绑盘了。

四、经典彩蛋三连

🎁 彩蛋 1：怎么让 NFS 服务器支持动态 PV？

官方文档里没有内置的 NFS provisioner，但是社区有个宝贝：nfs-subdir-external-provisioner。假设你已经有一台 NFS 服务器 192.168.1.100 和导出目录 /exports/k8s，动手试试这个：

# nfs-storageclass.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: nfs-dynamic
provisioner: k8s-sigs.io/nfs-subdir-external-provisioner
parameters:
  archiveOnDelete: "false"  # PVC 删除时，是否归档数据
---
# provisioner Deployment 需要另外部署，建议直接克隆官方项目
# https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner

具体 deployment 模板官方 GitHub 仓库里给得很清楚。部署完这个 provisioner，NFS 也可以玩动态 PV 了。我在某次交付测试环境中就靠这招搞定了没有云存储的场景。

🎁 彩蛋 2：跨可用区调度必坑术 —— volumeBindingMode: WaitForFirstConsumer

云硬盘最让人崩溃的故障现象：Pod 被调度到可用区 A 的节点，而 PV 却创建在可用区 B 的存储后端里。后果是 Pod 永远挂载不上卷。

解决方案很简单——在 StorageClass 加上 volumeBindingMode: WaitForFirstConsumer。效果是：PV controller 先不急着建盘，等 Scheduler 先把 Pod 调度到某个节点，再用这个节点的拓扑信息（比如 failure-domain.beta.kubernetes.io/zone）去对应可用区建盘。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: zone-aware-storage
provisioner: disk.csi.xxx   # 换成你的云 CSI
volumeBindingMode: WaitForFirstConsumer

这个参数会让 PV 的动态创建延迟到 Pod 调度完成之后。我做过的生产集群只要跨可用区都强制用这个模式。

🎁 彩蛋 3：回收策略复仇记——别让数据莫名其妙没了

动态 PV 的默认回收策略是 Delete。这意味着如果你不小心把 PVC 删了，底层的云硬盘数据也一起永远消失了。数据库生产环境里这绝对是灾难。

补救方法有两个：

① 创建 StorageClass 时把 reclaimPolicy 写成 Retain：

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: safe-storage
provisioner: ebs.csi.aws.com
reclaimPolicy: Retain   # 打死不删数据

② 对已经存在的动态 PV，手动改回收策略：

kubectl patch pv <pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'

改成 Retain 后，PVC 被删除时 PV 不会被自动回收，而是标记成 Released 状态。数据还在，后续你可以人工清理或者重新绑定。

所以我个人的铁律是：StorageClass 的 reclaimPolicy 生产环境用 Retain，测试环境才用 Delete。丢了数据真的没后悔药。

五、生产环境配置优化技巧

说实话我对 Kubernetes 存储的参数了解也还在不断更新，这里给你列几个我实际验证过的优化点：

启用 Volume Expansion：StorageClass 里加上 allowVolumeExpansion: true，以后想增加 PVC 的容量直接改 .spec.resources.requests.storage 就行。Kubernetes v1.34 之后已经支持缩小 PVC 容量了（不过还有些限制，别太指望）。
关注 CSI 驱动版本：比如 Ceph RBD 要用最新 CSI，老版本的内核模块经常出问题。kube-system 命名空间下有 CSI 控制器的 Pod，可以检查日志有没有报错。
掌握几个高性价比的排查命令：

查看 PVC 具体状态和事件

kubectl describe pvc

看 PV 是否有异常条件

kubectl get pv -o wide

查看具体 StorageClass 定义

kubectl get sc -o yaml
为性能关键应用单独配置 StorageClass：数据库要 IOPS，就用 SSD 类型的 StorageClass；ELK 日志不频繁访问，可以用吞吐量型的 StorageClass。很多云平台支持定义不同的性能参数，例如 GKE 里有参数能配置到 1GB/s 的存储带宽。

六、常见错误速查——别再猜了

现象

可能原因

专治命令

PVC 一直 Pending

StorageClass 里 provisioner 名称写错了，或者 CSI 插件没装

kubectl get sc -A，确保 StorageClass 存在；kubectl describe pvc 看详细事件

PVC 已经 Bound，但 Pod 启动不成功

后端存储出问题了（NFS 服务挂掉、磁盘配额满、权限不对）

在节点上手挂盘测试：mount -t nfs server:/path /mnt/test

Pod 无法调度

PVC 使用了 WaitForFirstConsumer，但 pod 本身有问题或者没有调度到符合条件的节点

先检查 pod 的 nodeSelector 或 affinity 是否限制了调度

删除 PVC 后 PV 不见了

回收策略是 Delete，被系统自动清理了

恢复数据基本不可能，吸取教训改用 Retain

StorageClass 没找到报错

PVC 里填的 storageClassName 在集群里不存在

kubectl get sc 确认可用项

另外有同学问过我：我辛辛苦苦在 StorageClass 里配了 NFS 的所有 export 规则，为什么 PVC 还是报 ProvisioningFailed？检查一下 pure_export_rules 或 mountOptions 字段的拼写和值的合法性。例如 NFS 场景里，别忘了设置 nfsvers=4 或者 3 来匹配版本。这类问题往往是配置细节导致的。

总结一下几个核心要点

到底用静态还是动态 PV？ 新集群一律上 StorageClass（动态），省心省力。静态 PV 留给那些遗留系统或特殊的本地存储场景。
回收策略很重要：生产用 Retain 保数据，测试用 Delete 省资源。反正我生产必开 Retain。
跨可用区部署必配 WaitForFirstConsumer，否则调度和存储分离的坑你早晚踩到。
PVC Pending 时先查 StorageClass 是否存在，然后 describe pvc 看事件详情，基本上能看出是谁的问题。
CSI 生态是主流：从 1.13 开始，K8s 就主推 CSI 驱动。插件种类特别多（AWS EBS、Azure Disk、GCE PD、Ceph RBD、NFS 等），找到适合你存储后端的，参考官方安装指引即可。

最后留个问题给你：你遇到过最难忘的 Kubernetes 存储故障是什么？用 Retain 还是 Delete 策略出过事故吗？欢迎在评论区聊聊你的“血泪史”——也希望对你有用，可以分享给刚入门 K8s 存储的同学看一看，少踩几个坑。

后续我还会写一篇《K8s 存储排胆硬刚实战》深入 CSI 驱动调试和存储故障恢复～

PV/PVC/StorageClass 核心资源完全解读