做网站版头图片网站的优化
当 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/mountpoint3. 检查相关 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四、预防措施
-
Pod 优雅终止：
-
确保 Pod 的
terminationGracePeriodSeconds足够长（默认 30 秒）。 -
在容器中实现
SIGTERM信号处理逻辑，确保释放资源。
-
-
存储卷管理：
-
避免多个 Pod 共享
hostPath卷。 -
使用
emptyDir.medium: Memory减少对磁盘的依赖。
-
-
监控与告警：
-
监控节点挂载点状态（如 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。