解决 Kubernetes 节点上的挂载点卡住问题：一次深入探索

在Kubernetes的日常操作中，我们可能会遇到各种各样的挑战和问题。最近，我遇到了一个特别棘手的问题：即使Pod 和Persistent Volume (PV) 已经被删除，它们之间的挂载关系仍然存在，导致整个集群的节点都无法使用 df -h 命令。本文将分享我是如何发现并解决这个问题的。

问题描述

在Kubernetes集群的日常维护中，我们发现所有节点都无法正常执行 df -h 命令。这个命令通常用来查看文件系统的磁盘空间使用情况，它的卡住不仅影响了监控和日志分析，还暴露了可能存在的更深层次问题。

排查过程

• 通过mount -l 查看是否有挂载了停用的nas，发现并没有
• 通过lsblk查看磁盘识别是否正常，发现是挺正常的
• 通过ls访问已挂载磁盘是否可以正常读取，发现也是正常的
• 通过使用 strace df -h 命令进行跟踪

• 因为kubectl的指令无法直接通过uid查找到pod，所以我们通过输出json结果，然后进行查找，发现并没有这个pod存在

kubectl get pods --all-namespaces -o json | jq --arg UID "025bbccb-93fe-447a-9270-6e2589d25a33" '.items[] | select(.metadata.uid == $UID)'

• 然后我再通过下面的指令查了下，也没有这个pv，这就有点奇怪了，正常来说，pod和pv删除后应该会结束之间的挂载关系

kubectl get pv --all-namespaces |grep pvc-c60a0c76-462c-4371-a2e5-6c92e8524598

• 对于爱钻技术牛角尖的我来说，不一探究竟有点寝食难安啊，但是要怎么排查问题的源头呢？突然灵光一闪，可以通过mounts信息查看挂载源，然后顺腾摸瓜即可，于是执行指令cat /proc/mounts |grep pvc-c60a0c76-462c-4371-a2e5-6c92e8524598可以看到来源是一个service网段的地址，再继续追查了下，原来是有个开源的项目会自动创建容器化的NFS服务，然后在helm uninstall卸载的时候有bug，在删除NFS之前没有先删除应用侧的POD，导致mount hang住了。

解决过程

好了，在查清楚来龙去脉之后，解决这个问题也就分分钟的事了，我们可以通过umount -l <挂载的目录>进行卸载，也就是所谓的“懒卸载”（lazy unmount），好的，在执行后我们的df -h可以正常执行了。

总结

Kubernetes是一个强大但复杂的系统，正如我们所见，它有时也会出现一些不易察觉的问题。通过分享这次经历希望可以帮助到大家，当然也在提醒我们监控和日常巡检的重要性。

- END -