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

你是不是也遇到过——Pod 重启后数据全没了PVC 一直报Pending不知道咋回事想用云硬盘结果 Pod 始终调度不到有存储的节点上我干了十年 SRE头三年也被这些问题折磨得够呛。Kubernetes 存储这块是很多刚入门同学的第一道坎——弄懂了高兴得像过年弄错了整个集群炸掉。今天把 PV、PVC、StorageClass 这几个核心概念掰开揉碎讲清楚读完这些你可以分清楚静态和动态两种配存方式什么时候用哪种自己上手配一套存储哪怕只是在 minikube 上玩搞明白 PVC 卡在 Pending 到底是谁的锅在大规模集群里少踩几个坑看这篇文章之前你至少得知道 kubectl 怎么跑能连上 Kubernetes 集群我测试用的是 Kubernetes v1.31 和 v1.32K8s 官方现在推荐的 kubectl 版本策略可以到官方文档核对对 namespace 和 Pod 的基础概念有模糊印象不懂可以去翻 Namespace 概念 恶补最好有个实验环境minikube 就行我 MacOS 上能跑通Linux 也没差一、到底谁管谁三个概念的关系PVPersistentVolume集群级别的存储资源可以理解成管理员提前“买好”的一块盘。定义的是一个持久化存储在宿主机上的目录比如某个 NFS 挂载点。PVCPersistentVolumeClaim开发者对存储的“下单”。声明我需要多少空间、什么访问模式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几个重要字段accessModesReadWriteOnceRWO单节点读写、ReadOnlyManyROX多节点只读、ReadWriteManyRWX多节点读写persistentVolumeReclaimPolicyPVC 删了后 PV 咋办后面会讲storage容量声明PVC 申请这块 PVapiVersion: 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预期输出里看到的 PVCSTATUS应该是Bound。如果Pending八成是 PV 没匹配上容量不够、accessMode 不对、标签没对上。三、动态 PVStorageClass 是硬核生产力动态 PV 是生产环境的标配。你不用去云平台手动开盘只要写好 StorageClassPVC 一提交自动帮你创建对应的存储卷。StorageClass YAMLapiVersion: 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.comGKE 里可能是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 # 指向上面那个 StorageClasskubectl 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 仓库里给得很清楚。部署完这个 provisionerNFS 也可以玩动态 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写成RetainapiVersion: 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 ExpansionStorageClass 里加上allowVolumeExpansion: true以后想增加 PVC 的容量直接改.spec.resources.requests.storage就行。Kubernetes v1.34 之后已经支持缩小 PVC 容量了不过还有些限制别太指望。关注 CSI 驱动版本比如 Ceph RBD 要用最新 CSI老版本的内核模块经常出问题。kube-system 命名空间下有 CSI 控制器的 Pod可以检查日志有没有报错。掌握几个高性价比的排查命令# 查看 PVC 具体状态和事件 kubectl describe pvc pvc-name # 看 PV 是否有异常条件 kubectl get pv -o wide # 查看具体 StorageClass 定义 kubectl get sc sc-name -o yaml为性能关键应用单独配置 StorageClass数据库要 IOPS就用 SSD 类型的 StorageClassELK 日志不频繁访问可以用吞吐量型的 StorageClass。很多云平台支持定义不同的性能参数例如 GKE 里有参数能配置到 1GB/s 的存储带宽。六、常见错误速查——别再猜了现象可能原因专治命令PVC 一直PendingStorageClass 里 provisioner 名称写错了或者 CSI 插件没装kubectl get sc -A确保 StorageClass 存在kubectl describe pvc看详细事件PVC 已经Bound但 Pod 启动不成功后端存储出问题了NFS 服务挂掉、磁盘配额满、权限不对在节点上手挂盘测试mount -t nfs server:/path /mnt/testPod 无法调度PVC 使用了WaitForFirstConsumer但 pod 本身有问题或者没有调度到符合条件的节点先检查 pod 的 nodeSelector 或 affinity 是否限制了调度删除 PVC 后 PV 不见了回收策略是Delete被系统自动清理了恢复数据基本不可能吸取教训改用RetainStorageClass 没找到报错PVC 里填的storageClassName在集群里不存在kubectl get sc确认可用项另外有同学问过我我辛辛苦苦在 StorageClass 里配了 NFS 的所有 export 规则为什么 PVC 还是报 ProvisioningFailed检查一下pure_export_rules或mountOptions字段的拼写和值的合法性。例如 NFS 场景里别忘了设置nfsvers4或者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 驱动调试和存储故障恢复