先看事件，再看状态：挂载失败的定位路径
当Pod一直处于ContainerCreating或CrashLoopBackOff时，Kubernetes存储故障排查的第一步是查看事件：kubectl describe pod <pod-name>。事件中常见的错误如“FailedMount”、“VolumeMount failed”等，会直接指出是PV/PVC绑定问题、CSI驱动调用失败，还是节点上设备未就绪。根据事件类型，可以快速缩小到三类：卷声明问题、驱动问题、底层存储问题。
PV/PVC绑定状态：从Pending到Bound的陷阱
如果PVC一直处于Pending，说明没有匹配的PV。检查kubectl get pv和kubectl get pvc，确认存储类（StorageClass）是否一致、访问模式是否匹配、容量是否满足。一个常见误区是忘记指定StorageClass，导致使用了默认类，而默认类可能不存在或指向错误的存储后端。另外，动态供给时，StorageClass的provisioner必须与集群中的CSI驱动一致，否则PVC无法创建PV。
CSI驱动与节点注册：挂载失败的隐形杀手
若PV/PVC已Bound，但Pod仍挂载失败，问题往往出在CSI驱动。检查CSI控制器和节点插件是否正常运行：kubectl get pods -n <csi-namespace>。节点上的CSI驱动需要正确注册到kubelet，若驱动未安装或版本不兼容，kubelet无法调用CSI接口。此外，某些云厂商的CSI驱动（如AWS EBS CSI）要求节点具有特定的IAM权限，若权限缺失，卷挂载会超时。参考Amazon EBS官方文档，EBS卷必须与实例处于同一可用区，否则无法附加，这同样适用于Kubernetes节点：如果PV指定了可用区，而Pod调度到其他区的节点，挂载必然失败。
底层存储设备：从lsblk到文件系统的验证
当事件显示设备找不到或格式错误时，需要登录节点检查底层设备。使用lsblk查看块设备是否出现，如lsblk -f可以显示文件系统类型和UUID。若设备存在但未格式化，需要创建文件系统；若设备不存在，则可能是云盘附加失败或本地磁盘未识别。对于云盘（如EBS），确认卷已附加到实例且处于同一可用区；对于本地存储，检查磁盘是否被系统识别。GNU Parted手册提供了分区操作指南，但通常Kubernetes使用的云盘已预分区，只需格式化即可。
节点条件与kubelet：被忽视的挂载前提
节点上的kubelet负责执行挂载操作。如果kubelet配置了错误的根目录或挂载传播设置，可能导致挂载失败。检查节点状态：kubectl describe node <node>，查看Conditions是否正常。另外，文件系统锁或挂载点残留也可能导致失败，此时重启kubelet或清理挂载点可解决。但需注意，重启kubelet会影响节点上的Pod，应谨慎操作。
常见误区与规避建议
误区一：只检查Pod事件，忽略PVC状态。事件可能被滚动覆盖，应结合PV/PVC的Events一起看。误区二：忽略存储类配置。动态供给依赖StorageClass，错误配置会导致PV创建失败。误区三：在节点上手动挂载后重启kubelet，这可能导致挂载点冲突。建议通过CSI驱动管理卷生命周期。误区四：忽略云厂商限制。如EBS卷的可用区限制，跨区挂载必然失败。
参考资料
延伸阅读