PVC 挂载失败排查：从绑定到节点挂载逐层定位

Pod 因存储无法启动时，先判断问题发生在 provisioning、attach 还是 mount。不同阶段由不同控制器负责，混在一起排查会浪费时间。

确认失败阶段

kubectl describe pod app-0 -n production
kubectl get pvc,pv -n production
kubectl describe pvc data-app-0 -n production
kubectl get volumeattachments

PVC 为 Pending 时检查 StorageClass、provisioner 和 WaitForFirstConsumer。PVC 已 Bound 但出现 Multi-Attach，常见原因是旧节点仍持有 RWO 卷。

检查 CSI 与节点

kubectl get pods -A | grep -i csi
kubectl logs -n kube-system daemonset/csi-node -c csi-plugin --since=20m
kubectl get csinode
journalctl -u kubelet --since '-20 min'

关注卷 ID、节点 ID、云平台错误码和超时。挂载阶段还可能因文件系统损坏、设备路径冲突、密钥错误或拓扑不匹配失败。

操作风险

• 不在未确认归属时手工 detach 正在使用的卷
• 不删除 PV 或 PVC 来“重试”生产数据卷
• 修复 node affinity 前核对卷所在可用区
• 文件系统修复前做好快照并确保卷未挂载

收尾清单

Pod 恢复后验证读写和数据完整性，并检查旧节点是否残留挂载。记录 CSI 版本、卷事件和云平台操作，为 attach/mount 延迟建立监控。