Kubernetes中如何重启故障节点上绑定持久化卷的Pod

这种情况我处理过好多次了——当绑定了RBD ReadWriteOnce卷的节点彻底挂掉时，K8s会误以为卷还挂载在那个故障节点上，所以不让新Pod挂载，就会报那个Multi-Attach error。咱们一步步来搞定：

1. 确认节点已彻底无法恢复，移除K8s中的节点记录 #

首先得确认那个节点确实物理损坏、再也回不来了：

kubectl get nodes

找到状态为NotReady的故障节点，再用describe确认细节：

kubectl describe node <故障节点名称>

确认没问题后，手动删除K8s中的节点对象（这只是移除集群内的记录，不会对已损坏的物理机造成影响）：

kubectl delete node <故障节点名称>

2. 清理K8s中的VolumeAttachment记录 #

K8s会用VolumeAttachment对象跟踪卷和节点的绑定关系，即使节点删了，这个记录可能还在。先找到对应卷的Attachment：

kubectl get volumeattachments

找到关联你那个PVC的条目（可以通过描述信息里的PVC名称或PV ID判断），然后删除它：

kubectl delete volumeattachment <对应的attachment名称>

3. （可选）直接在Ceph集群中解绑RBD镜像 #

如果上面一步做完还是报错，说明Ceph那边还保留着这个镜像的挂载记录。那咱们直接去Ceph管理节点操作：

1. 先找到PV对应的RBD信息：

kubectl describe pv <你的PV名称>

在输出里找到RBD Image、RBD Pool这两个字段的值。
2. 登录Ceph管理节点，先查看当前映射的RBD镜像：

rbd showmapped

找到对应镜像的条目，然后强制解绑：

rbd unmap -f <pool名称>/<镜像名称>

再用rbd showmapped确认这个镜像已经没有映射记录了。

4. 让Deployment重建Pod #

现在卷的绑定记录都清干净了，重启Deployment或者删除旧Pod即可：

kubectl rollout restart deployment <你的Deployment名称>

或者直接删故障Pod（Deployment会自动重建）：

kubectl delete pod <故障Pod的名称>

一些注意事项 #

• 操作前一定要确认节点确实无法恢复，别误删正常节点！
• 直接操作Ceph时要仔细核对镜像名称，避免误操作其他业务的存储。
• 如果你的集群用的是Ceph CSI驱动（而不是老的in-tree rbd驱动），步骤基本一致，核心都是清理卷的挂载绑定记录。
• 事后可以考虑配置节点的自动驱逐策略，或者给关键业务设置PodDisruptionBudget，减少这类故障的影响。

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