今天找了一个一直处于ContainerCreating状态的Pod，通过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是否需要挂载volume。在创建Pod的过程中，volume的整个过程如下：(1)第一步创建volume(2)第二步将volume挂载到节点上(3)将volume映射到豆荚。删除Pod时，volume的卸载过程与上述相反。所以初步怀疑是在删除Pod时，原节点由于某种原因未能从该节点卸载volume。让我们来看看。1、通过上面Pod的报错信息，我们可以得到如下有用的信息rbdimagekube/kubernetes-dynamic-pvc-bbfd3466-9f2f-11ea-8e91-5a4125e02b87isstillbeingused。从以上信息我们可以得到rbd的镜像信息，拆分如下：rbdpool:kuberbdimage:kubernetes-dynamic-pvc-bbfd3466-9f2f-11ea-8e91-5a4125e02b872，我们可以使用ceph命令获取图像被哪个节点使用，如下：#rbdinfokube/kubernetes-dynamic-pvc-bbfd3466-9f2f-11ea-8e91-5a4125e02b87rbdimage'kubernetes-dynamic-pvc-bbfd3466-9f2f-11ea-8e91-5a4125e02b87':size100Gi04objectsBinders2220)snapshot_count:0id:fb236b8b4567block_name_prefix:rbd_data.fb236b8b4567format:2features:layeringop_features:flags:create_timestamp:TueMay2617:03:152020access_timestamp:TueMay2617:03:152020modify_timestamp:TueMay2617:03:152020Mainlyfocusonthevalueofblock_name_prefix.然后通过以下命令获取具体节点：#radoslistwatchers-pkuberbd_header.fb236b8b4567watcher=192.168.100.181:0/154937577client.194364cookie=18446462598732840971其中，从block_name_prefix获取的值再通过上述命令修改后的值将是rbd_data即可从上面输出的信息可以看出，rbd镜像挂载到了192.168.100.181主机上。这个时候我们需要切换到这个主机上进行具体的操作。3、查看具体文件系统挂载信息ls/dev/rbd/kube/kubernetes-dynamic-pvc-bbfd3466-9f2f-11ea-8e91-5a4125e02b87-llrwxrwxrwx1rootroot117月2709:04/dev/rbd/kube/kubernetes-dynamic-pvc-bbfd3466-9f2f-11ea-8e91-5a4125e02b87->../../rbd4可以看到rbd镜像挂载在/dev/rbd4上，我们可以直接通过rbdunmap命令卸载，如下：#rbdunmap/dev/rbd4然而，这里对我来说并不那么容易。我卸载的时候报如下错误。#rbdunmap/dev/rbd4rbd:sysfwritefailedrbd:unmapfailed:(16)Deviceorresourcebusy看到这个问题的时候，以为有时候umount的时候会遇到Devicebusy，所以第一反应是用lsof看看能不能找到哪个进程被占用了，如下：#lsof2>/dev/null|greprbd4但是没有找到任何进程，看得我目瞪口呆。。。最后只能疯狂百度找到两个解决办法。(1)使用rbdunmap-oforce进行强制卸载(2)使用grep'rbd4'/proc/*/task/*/mountinfo查找进程PID。卸载原节点的rbd镜像后，可以看到Pod可以正常启动了。写在最后由于我是用Deployment来管理有状态的应用，所以正常使用StatefulSet是不会出现这个问题的，那么在使用Deployment的时候怎么避免这个问题呢？使用ReadWriteMany访问方式的PVC，将maxSurge设置为0，避免更新过程中产生冗余pod的两种方式各有利弊，具体情况需要用户自己权衡。本文转载自微信公众号《运维开发故事》，可通过以下二维码关注。转载本文请联系运维开发故事公众号。
