目 录CONTENT

文章目录

解决Kubernetes中PVC无法Mount的问题!

乔克
2022-03-08 / 0 评论 / 0 点赞 / 1,681 阅读 / 2,236 字 / 正在检测是否收录...
温馨提示:
本文最后更新于 2022-03-08,若内容或图片失效,请留言反馈。部分素材来自网络,若不小心影响到您的利益,请联系我们删除。
广告 广告

今天发现一个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

这两种方式都有利有弊,具体情况需要使用者去权衡。

0

评论区