解决K8S中Pod无法正常Mount PVC的问题

今天发现一个Pod一直处于ContainerCreating状态，通过Describe查看，发现以下错误。

WarningFailedMount15skubelet,node-2MountVolume.WaitForAttachfailedforvolume"pvc-504feeb6-ae42-45ba-996b-5e8e1039b601":rbdimagekube/kubernetes-dynamic-pvc-bbfd3466-9f2f-11ea-8e91-5a4125e02b87isstillbeingused

意思就是说该Pod启动需要挂载PVC，但是这个PVC目前正被使用。可以确定的是除了这个Deployment之外，没有其他Deployment在使用这个PVC，那这是为什么呢?

我们先来看看如果一个Pod需要挂载卷，在创建Pod的过程中，卷的整个流程如下：(1)第一步是先创建卷 (2)第二步在节点上挂载卷 (3)将卷映射到Pod中

在删除Pod的时候，卷的卸载过程和上面正好相反。所以初步怀疑是在删除Pod的时候，原节点由于某些原因从节点上卸载卷失败，我们来具体排查一下。

1、通过上面Pod的错误信息，我们可以获取到如下有用信息

rbdimagekube/kubernetes-dynamic-pvc-bbfd3466-9f2f-11ea-8e91-5a4125e02b87isstillbeingused

我们可以从上面的信息获取到rbd的镜像信息，拆分如下：

• rbd池：kube
• rbd镜像：kubernetes-dynamic-pvc-bbfd3466-9f2f-11ea-8e91-5a4125e02b87

2、我们通过ceph命令可以获取到该镜像被哪个节点使用，如下：

#rbdinfokube/kubernetes-dynamic-pvc-bbfd3466-9f2f-11ea-8e91-5a4125e02b87
rbdimage'kubernetes-dynamic-pvc-bbfd3466-9f2f-11ea-8e91-5a4125e02b87':
size100GiBin25600objects
order22(4MiBobjects)
snapshot_count:0
id:fb236b8b4567
block_name_prefix:rbd_data.fb236b8b4567
format:2
features:layering
op_features:
flags:
create_timestamp:TueMay2617:03:152020
access_timestamp:TueMay2617:03:152020
modify_timestamp:TueMay2617:03:152020

主要关注block_name_prefix的值。

然后通过以下的命令获取到具体的节点：

#radoslistwatchers-pkuberbd_header.fb236b8b4567
watcher=192.168.100.181:0/154937577client.194364cookie=18446462598732840971

其中，将从block_name_prefix获取到的值将rbd_data修改为rbd_header，然后通过以上命令获取即可。

从上面输出的信息可以看到这个rbd镜像被挂载到192.168.100.181主机上，这时候我们需要切换到该主机进行具体的操作。

3、查看具体的文件系统挂载信息

ls/dev/rbd/kube/kubernetes-dynamic-pvc-bbfd3466-9f2f-11ea-8e91-5a4125e02b87-l
lrwxrwxrwx1rootroot117月2709:04/dev/rbd/kube/kubernetes-dynamic-pvc-bbfd3466-9f2f-11ea-8e91-5a4125e02b87->../../rbd4

可以看到这个rbd镜像被挂载到/dev/rbd4上，我们可以直接通过rbd unmap命令卸载，如下：

#rbdunmap/dev/rbd4

不过我这里并没有这么容易，当我在卸载的时候报如下错误。

#rbdunmap/dev/rbd4
rbd:sysfswritefailed
rbd:unmapfailed:(16)Deviceorresourcebusy

一看到这个问题，就想到有时候在umount的时候，也会遇到Device busy，所以第一反应是使用lsof，看是否能找到哪个进程占用了，如下：

#lsof2>/dev/null|greprbd4

但是我并没有找到任何进程，二脸懵逼…..

最后只有疯狂百度了，找到了两种解决方式。(1)通过rbd unmap -o force进行强制卸载 (2)通过grep ‘rbd4’ /proc/*/task/*/mountinfo来查找进程PID

当把这个rbd镜像从原节点卸载过后，就可以看到Pod可以正常启动了。