故障现象一：Pod 反复 Crash，日志显示“MountVolume.SetUp failed”
当 Pod 启动后持续 CrashLoopBackOff，且通过 kubectl logs 或 kubectl describe pod 检查时，发现事件中反复出现 “MountVolume.SetUp failed for volume …” 错误，这通常意味着存储卷挂载阶段发生了不可恢复的故障。该错误是 CrashLoop 的根因之一，必须优先排查。
1. 错误日志定位与解读
使用以下命令快速定位故障 Pod 的挂载错误：
# 查看 Pod 事件，过滤 MountVolume 相关错误
kubectl describe pod <pod-name> -n <namespace> | grep -A 10 "MountVolume.SetUp failed"
# 查看 kubelet 日志（需在节点上执行）
journalctl -u kubelet -n 100 --no-pager | grep "MountVolume.SetUp failed"典型错误输出示例：
MountVolume.SetUp failed for volume "pvc-data" : rpc error: code = Internal
desc = "mount failed: exit status 32
Mounting command: mount
Mounting arguments: -t nfs4 10.0.1.100:/exports/data /var/lib/kubelet/pods/xxx/volumes/.../pvc-data
Output: mount.nfs4: Connection timed out"2. 根因分类矩阵
根据生产环境统计，“MountVolume.SetUp failed” 的根因可归纳为以下四类：
| 根因类别 | 典型错误特征 | 常见后端存储 | 影响范围 |
|---|---|---|---|
| 网络连通性故障 | Connection timed out / No route to host | NFS、CephFS、iSCSI | 单节点或跨节点 |
| 存储服务端异常 | access denied / permission denied | NFS、Ceph RBD | 全局 |
| 卷配置不匹配 | invalid argument / wrong fs type | HostPath、Local PV | 单 Pod |
| 节点存储驱动故障 | driver not supported / plugin not found | CSI 驱动、FlexVolume | 单节点 |
3. 故障排查流程（SVG 流程图）
以下流程图展示了从发现错误到定位根因的标准排查路径：
4. 常见场景与快速修复
场景一：NFS 存储挂载超时
- 现象：Pod 事件中反复出现
mount.nfs4: Connection timed out - 根因：工作节点与 NFS 服务器之间的防火墙规则未放通 2049 端口，或 NFS 服务端未启动
- 快速修复：在节点上执行
showmount -e <nfs-server-ip>测试可达性；检查安全组/iptables 规则
场景二：CSI 驱动未就绪
- 现象：错误日志包含
driver not supported或plugin not found - 根因：CSI 驱动 DaemonSet 未部署到该节点，或驱动版本与 Kubernetes 版本不兼容
- 快速修复：检查
kubectl get csidriver确认驱动注册状态；重启节点上的 kubelet 服务
场景三：PV/PVC 绑定状态异常
- 现象：Pod 事件显示
volume not found或access denied - 根因：PVC 与 PV 的 accessModes 不匹配，或 PV 已被其他 Pod 独占使用
- 快速修复：执行
kubectl get pv查看状态是否为Bound；检查 PVC 的accessModes是否包含ReadWriteMany
5. 关键排查命令速查表
| 排查目标 | 命令 | 预期输出 |
|---|---|---|
| 查看 Pod 挂载事件 | kubectl describe pod <pod> | grep -A 5 MountVolume |
显示具体挂载路径和错误原因 |
| 测试 NFS 可达性 | showmount -e <nfs-ip> |
列出 NFS 导出的目录列表 |
| 检查 CSI 驱动状态 | kubectl get csidriver |
显示已注册的 CSI 驱动名称 |
| 验证 PV 状态 | kubectl get pv <pv-name> -o yaml |
查看 PV 的 claimRef、accessModes 等字段 |
| 节点 kubelet 日志 | journalctl -u kubelet -n 50 --no-pager |
过滤出 MountVolume 相关错误行 |
6. 避坑指南
- 不要直接重启 Pod：CrashLoop 的根本原因在存储层，重启 Pod 只会重复触发挂载失败，浪费集群资源。
- 区分临时性故障与永久性故障：如果错误是
Connection timed out，可能是网络抖动，可等待 30 秒后重试；如果是permission denied，则必须修改存储端配置。 - 注意 Pod 亲和性对挂载的影响：当 Pod 被调度到与存储服务端网络隔离的节点时，即使 PVC 绑定正常，挂载仍会失败。后续章节将详细讲解如何通过 Pod 亲和性规则避免此类问题。