结论：这是块存储（iSCSI CSI）在节点侧挂载/发布阶段卡死造成的连续超时。先出现 Multi-Attach（卷仍挂在别的节点），随后在当前节点又报
rpc error: code = Aborted desc = An operation for targetPath ... already exists——典型是 旧的 targetPath/挂载点残留或 NodePublishVolume 还在“占坑”，导致后续挂载一直失败。

下面按“一次性恢复 + 根因修复”给你一套可直接执行的 SOP（以 iSCSI CSI 为例；非 iSCSI 的话跳过 iscsi 相关命令）。

一、一次性恢复（让 Pod 挂载成功）

目标：确保卷只挂在一个节点，清理旧节点残留与当前节点的 targetPath 占用，再重试。

1）确认卷现在被谁占用

# Pod在哪、事件
kubectl get pod <pod-name> -o wide
kubectl describe pod <pod-name> | sed -n '/Events/,$p'

# PVC/PV/卷ID
kubectl describe pvc <pvc-name>
kubectl describe pv  <pv-name> | egrep -i 'volumeHandle|nodeAffinity|AccessModes|StorageClass'

# VolumeAttachment（看附着到哪个node）
kubectl get volumeattachment | grep <pv-name或卷ID片段>
kubectl describe volumeattachment <va-name>

• 如果显示附着在另一个节点（且 PVC 是 RWO）：先在那个旧节点做第 2 步的卸载/登出，再删掉该 VA 记录。

2）在旧节点彻底脱挂（如果还附着）

# 找挂载点
findmnt | grep <pvc-name或pgdata目录>
lsof     | grep <挂载点>
# 确认无进程占用后卸载
sudo umount <挂载点> || sudo umount -l <挂载点>

# iSCSI 会话（如是 iSCSI）
sudo iscsiadm -m session
# 登出相关会话（匹配目标IQN/IP）
sudo iscsiadm -m node -T <iqn> -p <ip:port> --logout
# 清理节点记录（必要时）
sudo iscsiadm -m node -T <iqn> -p <ip:port> -o delete

公有云/外部存储还显示“已附着”时，需要在存储端强制脱挂（例如 AWS aws ec2 detach-volume --force / 云控制台操作）。

3）删除残留 VolumeAttachment（确认已脱挂后） - 备份、二次check

kubectl delete volumeattachment <va-name>

4）在当前节点清理占坑的 targetPath - 备份、二次check

错误 operation for targetPath ... already exists 说明 kubelet/CSI 认为该路径已有挂载或还在操作中。

# 找到 Pod 的 UID 与 CSI 路径
# 方式一：describe pod 里会有 pod UID
kubectl get pod <pod-name> -o jsonpath='{.metadata.uid}'

# 典型 targetPath（不同发行版路径略有差异）：
# /var/lib/kubelet/pods/<POD_UID>/volumes/kubernetes.io~csi/pvc-.../mount
sudo find /var/lib/kubelet/pods -maxdepth 4 -type d -name "pvc-85efabf0-7154-41a0-bab7-9c95f65c3c7f" -print

# 查看是否实际已挂载
findmnt | grep pvc-85efabf0-7154-41a0-bab7-9c95f65c3c7f
lsof    | grep pvc-85efabf0-7154-41a0-bab7-9c95f65c3c7f

# 若显示为已挂载但不可用 -> 卸载（必要时懒卸载）
sudo umount <targetPath> || sudo umount -l <targetPath>

# 目录不是挂载点但仍存在（CSI误判“占坑”）
# 确认不是挂载点后再移除目录
mountpoint -q <targetPath> || sudo rmdir <targetPath> 2>/dev/null || true

有时需要重启节点侧组件让 CSI 状态机复位：

# 重启 iSCSI/多路径服务（按你的系统/驱动为准）
sudo systemctl restart iscsid multipathd 2>/dev/null || true

# 滚动重启 CSI Node DaemonSet（名称按实际）
kubectl -n kube-system rollout restart ds/<csi-node-daemonset-name>

# 如仍卡住，可重启 kubelet
sudo systemctl restart kubelet
journalctl -u kubelet -S -10m | egrep -i 'csi|mount|publish|timeout|abort'

5）重建 Pod 并观察挂载成功 - 备份、二次check

kubectl delete pod <pod-name>
kubectl get pod <pod-name> -w
kubectl describe pod <pod-name> | sed -n '/Events/,$p'

二、可能的根因 & 对应修复

1. RWO 卷在旧节点未脱挂 → 新节点再挂载触发 Multi-Attach；清理旧挂载/强制脱挂并删 VA。
2. 节点侧残留 targetPath（前次异常终止/超时）→ operation ... already exists；需要卸载/删目录/重启 CSI 组件或 kubelet。
3. iSCSI/Multipath/udev 异常 → 设备不上线或发布失败；重启 iscsid/multipathd，udevadm settle，检查 dmesg、multipath -ll。
4. 节点 NotReady/网络抖动 → 导致前次挂载中断；先排稳节点（网络/磁盘/时钟/内核日志）。
5. 拓扑/可用区不匹配（跨 zone）→ 开启 StorageClass 的 WaitForFirstConsumer，保证卷按首次消费者拓扑分配。

三、防复发清单（建议立即改）

• StorageClass

  volumeBindingMode: WaitForFirstConsumer
  

  防止卷在错误的可用区/节点绑定。

• 有状态组件用 StatefulSet + PodDisruptionBudget，升级/迁移时避免并发驱逐。

• 巡检与告警：定期检查 VolumeAttachment 残留与节点 NotReady 事件。

• iSCSI 规范化：固定 IQN/门户，确保 iscsid/multipathd 自启动且配置正确。

• 需要多副本共享数据 用 RWX（NFS/EFS/CephFS），不要让多副本抢同一个 RWO 卷。

如果你把 CSI 驱动名称（如 csi-iscsi/csi-ebs 等）、当前 Pod 名/UID、PV 的 volumeHandle 与挂载节点贴出来，我可以把上面命令按你的环境写成逐行可执行的“强制脱挂 + 清理 targetPath + 重挂载”脚本。