Kubernetes存储编排实战：PV/PVC动态供给与StatefulSet配置指南

Kubernetes存储编排是容器化应用绕不开的一环，尤其对数据库、消息队列等有状态服务。很多故障源于对PV/PVC生命周期和动态供给机制理解不透彻。本文以MySQL主从为例，覆盖StorageClass、StatefulSet、PVC扩容与故障排查的完整链路。

PV、PVC与StorageClass的基本关系

PV是集群级的存储资源，PVC是命名空间内的使用申请，StorageClass负责按PVC声明自动创建PV，这个过程称为动态供给。数据卷的释放策略由reclaimPolicy决定：Retain保留数据、Delete删除云盘，生产环境建议Retain，避免误删后数据无法找回。

创建StorageClass接入CSI存储驱动

以NFS CSI驱动为例，先部署插件再创建StorageClass：

kubectl apply -f csi-driver-nfs.yaml

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: nfs-csi
provisioner: nfs.csi.k8s.io
parameters:
  server: 10.0.0.5
  share: /data/nfs
reclaimPolicy: Retain

云厂商环境一般自带云盘CSI（如alicloud-disk、ebs.csi），声明storageClassName时写对应名称即可，无需自建Provisioner。

StatefulSet的持久化：volumeClaimTemplates

StatefulSet为每个副本提供稳定网络标识与独立存储，volumeClaimTemplates为每个Pod自动创建PVC，且序号与Pod名绑定：

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  serviceName: mysql
  replicas: 2
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: ["ReadWriteOnce"]
      storageClassName: nfs-csi
      resources:
        requests:
          storage: 20Gi

执行后mysql-0与mysql-1各自挂载独立卷，数据互不干扰，这是有状态服务的基本要求。

访问模式与数据一致性的取舍

ReadWriteOnce支持单节点读写，适合MySQL单实例；NFS等多节点共享文件系统可ReadWriteMany，但注意多写并发一致性风险。副本间数据一致性交给应用层（主从复制）处理，不要依赖存储层多写。

PV/PVC扩容与数据迁移

启用allowVolumeExpansion后可直接修改PVC申请大小：

kubectl edit pvc data-mysql-0
# 修改 resources.requests.storage: 20Gi 为 50Gi

扩容后无需重启Pod。需要迁移数据时，用逻辑备份/导入或临时克隆卷，避免在运行期直接切换底层存储路径。

存储故障排查命令清单

kubectl get pvc,pv
kubectl describe pvc data-mysql-0
kubectl logs -n kube-system -l app=csi-controller
kubectl exec -it mysql-0 -- df -h

Pod一直Pending且事件提示volume not found，优先检查StorageClass驱动是否在线；PVC Pending则查看底层存储配额是否不足。存储问题大多出在驱动与配额层，日志是定位的第一入口。