GKE集群出现Multi-Attach卷错误，请求协助排查原因

常见触发原因 #

• PV访问模式限制：如果你的PersistentVolume（PV）使用ReadWriteOnce（RWO）访问模式，这类卷仅允许被单个节点挂载，当多个Pod尝试在不同节点挂载同一个PVC对应的PV时，就会触发该错误。
• Pod异常退出未释放卷：Pod因节点故障、OOMKilled或其他意外情况突然终止时，Kubernetes卷挂载控制器可能未及时完成卷的卸载操作，导致卷仍被标记为附着在原节点上，新Pod尝试挂载时就会出现冲突。
• 节点状态异常：原节点处于NotReady状态但Kubernetes未完成卷的清理流程，或者节点的kubelet进程挂掉，导致卷的附着状态未及时同步到API Server。
• 存储控制器延迟：GCP Persistent Disk的存储控制器在处理卷卸载请求时出现延迟，即便Pod已经被删除，卷的附着状态仍未同步到GKE控制平面。

排查步骤 #

1. 核对PV访问模式
   执行命令查看PV的配置细节：

   kubectl get pv <pv-name> -o yaml
   

   检查spec.accessModes字段，如果是ReadWriteOnce，确认是否有跨节点的Pod同时请求挂载该PVC。

2. 定位卷当前附着节点
   查看PV的详细状态信息：

   kubectl describe pv <pv-name>
   

   在Status区域的Attached字段会显示卷是否已附着，NodeAffinity字段可定位到当前挂载该卷的节点。

3. 检查节点与Pod状态

   • 查看集群所有节点的状态：

     kubectl get nodes
     

     若对应节点处于NotReady状态，检查节点是否正常运行，或是否需要驱逐节点上的残留Pod。
   • 查找所有使用该PVC的Pod：

     kubectl get pods -A -o wide | grep <pvcname>
     

     确认是否有Pod在原节点处于Terminating状态但无法完成清理。

4. 手动清理卷附着状态（谨慎操作）
   确认原节点已无相关Pod且卷未被使用时，可强制解除PV与PVC的关联：

   kubectl patch pv <pv-name> -p '{"spec":{"claimRef": null}}'
   

   操作完成后重新创建需要挂载该PVC的Pod。

5. 检查GCP存储侧状态
   登录GCP控制台找到对应的Persistent Disk，查看“已附着的实例”信息，如果卷仍被GKE节点附着，可手动在控制台解除附着，再回到GKE中同步状态。

内容的提问来源于stack exchange，提问作者Nani