直接回答：kubectl describe pvc 看 events——ProvisioningFailed 信息通常直给原因。故障点四类：StorageClass 不存在或名字写错（PVC 引用了一个没有的 SC）；provisioner 异常（动态供给的控制器挂了或云厂商凭证失效）；容量/参数不满足（没有可用 PV，或请求超出 provisioner 能力）；local PV 的调度约束（PV 绑定了特定节点，Pod 调度不到该节点就 Pending）。
展开解析：逐项展开：StorageClass 核对——kubectl get sc 列出现有的，PVC 的 storageClassName 逐字对照，注意留空与不写的区别（不写用默认 SC，集群没设默认 SC 就永远 Pending）；provisioner 排查——云厂商场景（EBS/PD/Ceph CSI）看对应 CSI controller 的 Pod 状态与日志，凭证过期（IAM 角色、secret）会报 Unauthorized；静态 PV 绑定——容量不足（PV 1Gi 对 PVC 2Gi）、accessModes 不匹配（PVC 要 RWX 但 PV 只 RWO）、volumeMode 不一致（Block vs Filesystem）、storageClassName 两边不等，任一不符都绑不上，kubectl get pv 看 Available 池；local PV——nodeAffinity 把 PV 钉在节点上，WaitForFirstConsumer 模式下 PVC 会等 Pod 调度后再绑定，这是特性不是故障，但 Pod 若因其他原因调度不了就形成连环 Pending。扩容与恢复：PVC 扩容要求 SC 的 allowVolumeExpansion: true 且底层支持，events 看 FileSystemResizePending（需 Pod 重启完成扩容）。预防：SC 参数模板化评审、PV 池容量监控、provisioner 的 Pod 健康告警。kubectl get events --sort-by 时间线经常一眼看出“供给失败重试”的循环。
追问方向：WaitForFirstConsumer 解决了什么调度问题？RWX 在不同存储后端的实现差异？
（约 490 字）