排查定位
PVC 停在 Pending，意味着「申请没被满足」。适用平台是 Kubernetes，原因集中在四类：没有可匹配的静态 PV、引用的 StorageClass 不存在、动态制备失败（驱动或云侧报错）、以及绑定模式为 WaitForFirstConsumer 时正在等 Pod 调度。判断的关键动作是 describe PVC 看事件，因为具体原因几乎都会写在事件里，靠猜效率很低。
基本信息
| 适用平台 | Kubernetes（PVC 为命名空间级，PV 为集群级） |
|---|---|
| 现象 | PVC 的 STATUS 停留在 Pending，不进入 Bound |
| 关键信息源 | kubectl describe pvc 的 Events 段 |
| 与 Pod 的关系 | WaitForFirstConsumer 模式下要先有消费者 Pod 才会制备 |
典型使用场景
- 新业务上线卷没起来：核对 StorageClass 名与默认类配置
- 云上扩可用区后失败：驱动在目标区没有可用存储或配额不足
- 精简集群没有默认类：PVC 没有可用类，报错信息也不总是直观
- 有状态服务迁移：静态 PV 的容量或访问模式与 PVC 不匹配
- 批量创建 PVC 混用旧模板：模板里写着已下线的类名
排查命令
排查命令
kubectl get pvc -A # 找 Pending 的对象
kubectl describe pvc data-claim -n prod # 事件原文最关键
kubectl get events -n prod --field-selector involvedObject.name=data-claim --sort-by=.lastTimestamp
kubectl get sc # 存储类是否存在、哪个是默认
kubectl get sc fast-ssd -o yaml # 看 provisioner 与参数
kubectl -n kube-system get pod -l app=csi-driver -o wide # 驱动控制器是否正常常见事件线索
| 事件关键词 | 可能原因 | 处理方向 |
|---|---|---|
| no persistent volumes available for this claim | 静态 PV 容量、类或模式不匹配 | 补建符合条件的 PV 或改用动态制备类 |
| storageclass not found | 引用的 StorageClass 不在集群里 | 改 PVC 的类名或恢复该类 |
| provisioning failed | 制备器或云驱动侧错误 | 看事件原文与驱动日志，核对配额与可用区 |
| waiting for first consumer to be created | WaitForFirstConsumer 的正常等待 | 先解决 Pod 调度问题，卷会随之制备 |
| quota exceeded | 云侧配额或容量不足 | 扩容配额或换可用区 |
事件是判断的主导信息：同样是 Pending，背后的原因差别很大，只看状态不做 describe 属于空转。
WaitForFirstConsumer 的 Pending 通常是正常状态，含义是卷要等 Pod 调度到节点后再按该节点所在拓扑创建，此时应优先排查 Pod 为什么调度不上去。