Kubernetes排错(十七) ：kubelet日志报device or resource busy

当 Kubernetes 节点上的 kubelet 日志报 device or resource busy 错误时，通常表示系统在尝试卸载某个存储设备或目录时发现其仍被占用。此问题可能由未释放的挂载点、残留的进程或存储驱动问题引发。以下是详细的排查步骤和解决方案：

一、错误原因分析

常见场景	具体表现
Pod 未正常终止	Pod 或容器未完全退出，导致挂载的存储卷（如 PVC、hostPath）无法卸载。
进程占用挂载点	主机上的进程（如日志收集工具、备份脚本）正在访问挂载点下的文件。
存储驱动/文件系统问题	文件系统（如 NFS、CephFS）存在锁或缓存未释放，导致卸载失败。
Kubelet 或容器运行时问题	Kubelet 或容器运行时（containerd、Docker）未正确清理资源，残留挂载点。
多副本挂载冲突	多个 Pod 尝试挂载同一存储资源（如 hostPath），导致竞争条件。

二、排查步骤与命令

1. 确认挂载点状态

检查哪些挂载点无法卸载：

# 查看当前挂载的存储卷（过滤 Kubernetes 相关挂载）
mount | grep -E 'kubernetes|kubelet' # 查看 kubelet 日志中的具体报错路径
journalctl -u kubelet --since "10 minutes ago" | grep "device or resource busy"

2. 查找占用进程

使用 lsof 或 fuser 检查挂载点是否被进程占用：

# 查找占用挂载点的进程（替换为实际挂载路径）
lsof +f -- /var/lib/kubelet/pods/<pod-id>/volumes/kubernetes.io~<volume-type>/<volume-name>
fuser -v -m /path/to/mountpoint

3. 检查相关 Pod 状态

确认是否有残留的 Pod 或容器仍在使用存储卷：

# 列出所有 Pod（包括已终止的）
kubectl get pods --all-namespaces --field-selector spec.nodeName=<node-name># 检查特定 Pod 的状态
kubectl describe pod <pod-name> -n <namespace>

4. 检查存储配置

根据存储类型排查配置问题：

• NFS/CephFS：检查服务端日志，确认是否有未释放的锁或会话。

• hostPath：确认目录未被主机上的其他进程占用。

• CSI 驱动：检查 CSI 插件日志，确认存储操作是否超时或失败。

三、解决方案

方案 1：强制终止残留进程

若发现有进程占用挂载点，手动终止相关进程：

# 通过 lsof 获取 PID 并终止
lsof +f -- /path/to/mountpoint | awk '{print $2}' | xargs kill -9# 或使用 fuser 终止进程
fuser -km /path/to/mountpoint  # -k 表示 kill，-m 指定挂载点

方案 2：清理残留 Pod 或容器

删除未正确退出的 Pod 或容器：

# 删除指定 Pod（慎用 --force，可能丢失数据）
kubectl delete pod <pod-name> -n <namespace> --force --grace-period=0# 重启 kubelet 清理资源（重启后会自动清理残留挂载）
systemctl restart kubelet

方案 3：手动卸载挂载点

如果自动卸载失败，尝试手动卸载：

# 卸载挂载点（强制）
umount -f /path/to/mountpoint# 若提示 "busy"，尝试 lazy 卸载（延迟卸载）
umount -l /path/to/mountpoint

方案 4：优化存储配置

针对不同存储类型调整配置：

• NFS 存储：添加 soft 和 intr 挂载选项，防止客户端无限重试。

  volumes:- name: nfs-volumenfs:server: nfs-serverpath: /exportreadOnly: false
  mountOptions:- soft- intr- timeo=30- retrans=2

• CSI 驱动：更新驱动版本或调整 VolumeAttachment 超时时间。

方案 5：修复文件系统

检查文件系统错误并修复：

# 对设备进行文件系统检查（如 ext4）
fsck /dev/sdX# 若为 NFS，检查服务端状态
systemctl status nfs-server

四、预防措施

1. Pod 优雅终止：

   • 确保 Pod 的 terminationGracePeriodSeconds 足够长（默认 30 秒）。

   • 在容器中实现 SIGTERM 信号处理逻辑，确保释放资源。

2. 存储卷管理：

   • 避免多个 Pod 共享 hostPath 卷。

   • 使用 emptyDir.medium: Memory 减少对磁盘的依赖。

3. 监控与告警：

   • 监控节点挂载点状态（如 Prometheus + node-exporter）。

   • 设置告警规则检测 kubelet 的 volume_manager 错误。

五、高级调试工具

• strace 跟踪系统调用：

  strace -f -p $(pidof kubelet) -e trace=file,umount 2>&1 | grep "EBUSY"

• 检查内核日志：

  dmesg | grep "EBUSY"

总结

步骤	关键命令/操作	目的
查找占用进程	lsof +f -- /path / fuser -v -m /path	定位未释放资源的进程
清理残留 Pod	kubectl delete pod --force	强制删除未正确终止的 Pod
手动卸载挂载点	umount -f -l /path	强制解除挂载点占用
优化存储配置	调整 mountOptions 或 CSI 参数	避免存储驱动超时或锁冲突

案例详解

背景​

在 kubernetes 环境中，可能会遇到因目录被占用导致 pod 一直 terminating:

Aug 27 15:52:22 VM-244-70-centos kubelet[906978]: E0827 15:52:22.816125  906978 nestedpendingoperations.go:270] Operation for "\"kubernetes.io/secret/b45f3af4-3574-472e-b263-c2b71c3b2ea0-default-token-fltdk\" (\"b45f3af4-3574-472e-b263-c2b71c3b2ea0\")" failed. No retries permitted until 2021-08-27 15:54:24.816098325 +0800 CST m=+108994.575932846 (durationBeforeRetry 2m2s). Error: "UnmountVolume.TearDown failed for volume \"default-token-fltdk\" (UniqueName: \"kubernetes.io/secret/b45f3af4-3574-472e-b263-c2b71c3b2ea0-default-token-fltdk\") pod \"b45f3af4-3574-472e-b263-c2b71c3b2ea0\" (UID: \"b45f3af4-3574-472e-b263-c2b71c3b2ea0\") : unlinkat /var/lib/kubelet/pods/b45f3af4-3574-472e-b263-c2b71c3b2ea0/volumes/kubernetes.io~secret/default-token-fltdk: device or resource busy"

找出目录被谁占用的​

看下目录哪个进程 mount 了:

$ find /proc/*/mounts -exec grep /var/lib/kubelet/pods/0104ab85-d0ea-4ac5-a5f9-5bdd12cca589/volumes/kubernetes.io~secret/kube-proxy-token-nvthm {} + 2>/dev/null
/proc/6076/mounts:tmpfs /var/lib/kubelet/pods/0104ab85-d0ea-4ac5-a5f9-5bdd12cca589/volumes/kubernetes.io~secret/kube-proxy-token-nvthm tmpfs rw,relatime 0 0

根据找出的进程号，看看是谁干的:

$ ps -ef | grep -v grep | grep 6076
root        6076    6057  0 Aug26 ?        00:01:54 /usr/local/loglistener/bin loglistener -c /usr/local/loglistener/etc/loglistener.conf

看下完整的进程树:

$ pstree -apnhs 6076
systemd,1 --switched-root --system --deserialize 22└─dockerd,1809 --config-file=/etc/docker/daemon.json└─docker-containe,1868 --config /var/run/docker/containerd/containerd.toml└─docker-containe,6057 -namespace moby -workdir /data/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby/9a8457284ce7078ef838e78b79c87c5b27d8a6682597b44ba7a74d7ec6965365 -address /var/run/docker/containerd/docker-containerd.sock -containerd-binary /usr/bin/docker-containerd -runtime-root ...└─loglistener,6076 loglistener -c /usr/local/loglistener/etc/loglistener.conf├─{loglistener},6108├─{loglistener},6109├─{loglistener},6110├─{loglistener},6111└─{loglistener},6112

反查 Pod​

如果占住这个目录的进程也是通过 Kubernetes 部署的，我们可以反查出是哪个 Pod 干的。

通过 nsenter 进入容器的 netns，查看 ip 地址，反查出是哪个 pod:

$ nsenter -n -t 6076
$ ip a 
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00inet 127.0.0.1/8 scope host lovalid_lft forever preferred_lft foreverinet6 ::1/128 scope host valid_lft forever preferred_lft forever
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 10000link/ether 52:54:00:ca:89:c0 brd ff:ff:ff:ff:ff:ffinet 192.168.244.70/24 brd 192.168.244.255 scope global eth1valid_lft forever preferred_lft foreverinet6 fe80::5054:ff:feca:89c0/64 scope link valid_lft forever preferred_lft forever
$ kubectl get pod -o wide -A | grep 192.168.244.70
log-agent-24nn6                                      2/2     Running            0          84d     192.168.244.70    10.10.10.22    <none>           <none>

如果 pod 是 hostNetwork 的，无法通过 ip 来分辨出是哪个 pod，可以提取进程树中出现的容器 id 前几位，然后查出容器名:

$ docker ps | grep 9a8457284c
9a8457284ce7        imroc/loglistener     "/usr/local/logliste…"   34 hours ago        Up 34 hours                             k8s_loglistener_log-agent-wd2rp_kube-system_b0dcfe14-1619-43b5-a158-1e2063696138_1

Kubernetes 的容器名就可以看出该容器属于哪个 pod。