今天发现一个 Pod 一直处于 ContainerCreating 状态，通过 Describe 查看，发现以下错误。
Warning FailedMount 15s kubelet, node-2 MountVolume.WaitForAttach failed for volume "pvc-504feeb6-ae42-45ba-996b-5e8e1039b601" : rbd image kube/kubernetes-dynamic-pvc-bbfd3466-9f2f-11ea-8e91-5a4125e02b87 is still being used
意思就是说该 Pod 启动需要挂载 PVC，但是这个 PVC 目前正被使用。可以确定的是除了这个 Deployment 之外，没有其他 Deployment 在使用这个 PVC，那这是为什么呢？
我们先来看看如果一个 Pod 需要挂载卷，在创建 Pod 的过程中，卷的整个流程如下：
（1）第一步是先创建卷
（2）第二步在节点上挂载卷
（3）将卷映射到 Pod 中
在删除 Pod 的时候，卷的卸载过程和上面正好相反。所以初步怀疑是在删除 Pod 的时候，原节点由于某些原因从节点上卸载卷失败，我们来具体排查一下。
1、通过上面 Pod 的错误信息，我们可以获取到如下有用信息
rbd image kube/kubernetes-dynamic-pvc-bbfd3466-9f2f-11ea-8e91-5a4125e02b87 is still being used
我们可以从上面的信息获取到 rbd 的镜像信息，拆分如下：
- rbd 池：kube
- rbd 镜像：kubernetes-dynamic-pvc-bbfd3466-9f2f-11ea-8e91-5a4125e02b87
2、我们通过 ceph 命令可以获取到该镜像被哪个节点使用，如下：
# rbd info kube/kubernetes-dynamic-pvc-bbfd3466-9f2f-11ea-8e91-5a4125e02b87
rbd image 'kubernetes-dynamic-pvc-bbfd3466-9f2f-11ea-8e91-5a4125e02b87':
size 100 GiB in 25600 objects
order 22 (4 MiB objects)
snapshot_count: 0
id: fb236b8b4567
block_name_prefix: rbd_data.fb236b8b4567
format: 2
features: layering
op_features:
flags:
create_timestamp: Tue May 26 17:03:15 2020
access_timestamp: Tue May 26 17:03:15 2020
modify_timestamp: Tue May 26 17:03:15 2020
主要关注 block_name_prefix 的值。
然后通过一下的命令获取到具体的节点：
# rados listwatchers -p kube rbd_header.fb236b8b4567
watcher=192.168.100.181:0/154937577 client.194364 cookie=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
lrwxrwxrwx 1 root root 11 7月 27 09:04 /dev/rbd/kube/kubernetes-dynamic-pvc-bbfd3466-9f2f-11ea-8e91-5a4125e02b87 -> ../../rbd4
可以看到这个 rbd 镜像被挂载到 /dev/rbd4 上，我们可以直接通过 rbd unmap 命令卸载，如下：
# rbd unmap /dev/rbd4
不过我这里并没有这么容易，当我在卸载的时候报如下错误。
# rbd unmap /dev/rbd4
rbd: sysfs write failed
rbd: unmap failed: (16) Device or resource busy
一看到这个问题，就想到有时候在 umount 的时候，也会遇到 Device busy，所以第一反应是使用 lsof，看是否能找到哪个进程占用了，如下：
# lsof 2>/dev/null | grep rbd4
但是我并没有找到任何进程，二脸懵逼…
最后只有疯狂百度了，找到了两种解决方式。
（1）通过 rbd unmap -o force 进行强制卸载
（2）通过 grep 'rbd4' /proc/*/task/*/mountinfo 来查找进程 PID
当把这个 rbd 镜像从原节点卸载过后，就可以看到 Pod 可以正常启动了。
写在最后
由于我是使用的 Deployment 来管理的有状态应用，正常使用 StatefulSet 不会出现这种问题，那使用 Deployment 该如何避免这种问题呢？
- 使用
ReadWriteMany访问模式的 pvc - 将
maxSurge设置为0，避免在更新过程中产生多余的 pod
这两种方式都有利有弊，具体情况需要使用者去权衡。