Kubernetes持久卷动态供给通过StorageClass和CSI插件自动创建PV并绑定PVC，容量回收策略应优先在数据库类生产环境选择Retain，在CI/CD和测试环境选择Delete，同时配合云盘容量监控与手动清理避免成本失控。
Kubernetes持久卷动态供给怎么做：StorageClass到PVC的完整链路
动态供给解决的是一个很实际的问题：Pod需要存储，但管理员不可能守在集群旁边逐个手工创建PV，尤其当几百个Pod同时申请云盘时，手工模式基本走不通，动态供给让PVC提交后，由StorageClass自动触发底层存储创建,几秒到几十秒内完成绑定。
为什么需要动态供给
- 手动创建PV无法匹配不同容量、地域、云盘类型和访问模式。
- PVC只声明需求，不关心底层实现,运维不必提前规划所有PV。
- 动态供给依赖CSI驱动,云厂商和开源存储都提供对应插件。
- 扩容、快照、删除等操作可以走统一接口,减少脚本维护。
动态供给的四个关键对象
- StorageClass：存储模板，定义provisioner、reclaimPolicy、parameters、allowVolumeExpansion。
- PVC：用户请求，声明容量、访问模式、StorageClass名称。
- PV：实际存储资源,由CSI插件动态创建并绑定到PVC。
- CSI插件：真正操作云盘、本地盘或网络文件系统。
从零搭建动态供给的实操步骤
- 确认集群已经安装CSI插件，执行
kubectl get csidrivers查看驱动列表。 - 创建StorageClass,关键字段如下。
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: fast-essd provisioner: diskplugin.csi.alibabacloud.com parameters: type: cloud_essd regionId: cn-shanghai reclaimPolicy: Delete allowVolumeExpansion: true
创建PVC引用该StorageClass。
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mysql-data
spec:
accessModes:
- ReadWriteOnce
storageClassName: fast-essd
resources:
requests:
storage: 100Gi
- 执行
kubectl get pvc mysql-data查看状态,状态为Bound表示绑定成功。 - 如果一直Pending，执行
kubectl describe pvc mysql-data,在Events里能看到云盘创建失败的具体原因。
持久卷容量回收机制对比：Delete与Retain策略生产环境怎么选
删除PVC之后，云盘到底删不删，取决于StorageClass里的reclaimPolicy，这个字段决定PV和底层存储的去留，选错策略，轻则多花冤枉钱,重则数据不可恢复。
三种回收策略的状态差异
| 策略 | PVC删除后PV状态 | 底层云盘/存储 | 数据可恢复性 | 成本影响 |
|---|---|---|---|---|
| Delete | 删除 | 自动释放 | 不可恢复 | 立即停止计费 |
| Retain | Released | 保留 | 可手动恢复 | 继续计费 |
| Recycle | 清理数据后重新可用 | 保留 | 不可恢复 | 保留计费 |
Recycle策略在多数CSI插件中已经废弃,不建议在新集群使用。
生产环境容量回收选择逻辑
- 数据库、日志、监控等有状态服务优先使用Retain，删除PVC不会误删数据，即使Pod或PVC重建,云盘仍然保留。
- CI/CD流水线、临时分析任务优先使用Delete,避免残留大量闲置云盘。
- 行业共识认为，Retain策略虽然增加人工清理成本,但对关键数据是必要保护。
- 无状态应用的缓存目录可以用Delete,配合Pod生命周期自动清理。
Retain策略手动释放完整步骤
- 删除PVC后,PV进入Released状态。
- 执行
kubectl get pv找到对应PV。 - 执行
kubectl delete pv <pv-name>删除PV对象。 - 登录云控制台或使用云CLI删除对应云盘。
- 确认云盘ID与PV的volumeHandle字段一致,防止误删其他盘。
简米云上海地域ESSD云盘价格与持久卷性能匹配场景
在上海地域部署生产集群时，云盘选型和回收策略往往同时决定成本和数据安全，简米云上海地域ESSD云盘的单位容量价格通常高于高效云盘，但IOPS和时延表现更适合数据库类持久卷，具体价格以云厂商控制台实时显示为准,不同可用区可能存在细微差异。
不同工作负载的云盘选型
- MySQL、PostgreSQL：选择ESSD PL1或PL2,配合Retain策略。
- Elasticsearch热节点：选择ESSD PL2,扩容时需关注节点数和分片分布。
- 日志归档、备份存储：高效云盘即可,Delete策略控制成本。
- 通用Web应用的会话共享目录：ESSD PL1足够,访问模式用ReadWriteMany。
容量回收与云盘计费的关系
Delete策略下，PVC删除后云盘自动删除，不产生后续费用，Retain策略下，PVC删除后云盘仍在计费，需要定期巡检Released PV，业内专家指出，相当一部分云成本超支来自孤儿云盘,而不是运行中的计算实例。
上海地域生产场景：Retain加定期回收
用户在上海地域部署生产Kubernetes集群，数据库PVC误删除后，通过Retain策略找回数据，操作路径是：PVC被删除，PV变为Released，云盘仍存在，重新创建PVC并指定PV名称即可重新绑定，这个过程中，云盘一直在计费，直到手动删除，所以需要每周运行一次Released PV清理脚本。
持久卷扩容与回收的常见陷阱及排查路径
动态供给不是一劳永逸，扩容和回收环节有很多隐性条件，多数情况下,问题暴露在挂载失败或Pending状态。
PVC扩容的隐藏条件
- StorageClass必须设置allowVolumeExpansion为true。
- 文件系统类型支持在线扩容,块设备可能只支持离线扩容。
- 某些云盘类型对扩容次数或步长有限制。
- 扩容命令如下。
kubectl patch pvc mysql-data -p '{"spec":{"resources":{"requests":{"storage":"200Gi"}}}}'
执行后使用kubectl get pvc mysql-data -w观察容量变化,Pod内文件系统通常会自动扩展。
PersistentVolumeClaim误删后的恢复场景
- Delete策略下，PVC误删会联动删除云盘，无法直接恢复,只能依赖云盘快照。
- Retain策略下，可通过手动重建PVC绑定Released PV来恢复。
- 具体步骤：
kubectl get pv | grep Released，复制PV名称，编辑PVC的volumeName字段为该PV名称,创建PVC后自动绑定。 - 注意恢复后的PV仍然保留原回收策略,后续删除PVC仍会进入Released状态。
节点标签、可用区与云盘挂载失败
云盘类型的持久卷通常限制单可用区，Pod调度到与云盘不同可用区的节点会挂载失败，解决办法是检查PV的nodeAffinity字段，或者为节点增加可用区标签,确保调度器不会跨可用区分配Pod。
持久卷动态供给与容量回收常见问题
持久卷动态供给失败PVC一直Pending怎么排查？
执行kubectl describe pvc <pvc-name>查看Events，常见原因包括StorageClass名称写错、CSI插件未运行、云盘配额不足、可用区不匹配，多数情况下，Events中会直接给出create volume failed的详细错误,按错误信息修正即可。
持久卷容量回收机制中Retain策略如何手动释放云盘？
先删除PVC，PV进入Released状态，记录PV的volumeHandle云盘ID，执行kubectl delete pv <pv-name>，再到云控制台删除该云盘，不能跳过PV直接删云盘，否则集群会残留异常PV,后续清理更麻烦。
持久卷动态供给和静态供给的区别是什么？
动态供给由StorageClass按需创建PV，静态供给由管理员预先创建PV再绑定PVC，动态供给更适合云环境和自动化场景，静态供给在本地存储或特殊权限场景仍有使用，当前Kubernetes生态中，CSI插件基本取代了早期FlexVolume,动态供给已成为云上持久卷的主流创建方式。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/642881.html
