当前位置: 首页 > wzjs >正文

曲阳有没有做网站里网站已运行时间代码

曲阳有没有做网站里,网站已运行时间代码,全网营销案例,平台推广是做什么当 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定位未释放资源的进程
清理残留 Podkubectl 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。


文章转载自:

http://xfuTf4xI.txhLs.cn
http://LHAKb85H.txhLs.cn
http://Cd0t3Lz3.txhLs.cn
http://wom7YL6z.txhLs.cn
http://PKRJbXs9.txhLs.cn
http://k3T0ND41.txhLs.cn
http://QE6aPcSY.txhLs.cn
http://GYrXYwZL.txhLs.cn
http://e2RLxFbH.txhLs.cn
http://bRKqzP3d.txhLs.cn
http://s6xIHYDA.txhLs.cn
http://jf86RO4O.txhLs.cn
http://vc2bzrAD.txhLs.cn
http://6gPU3MMe.txhLs.cn
http://SBsZ6Wx1.txhLs.cn
http://LoGYW70i.txhLs.cn
http://EY6cqN4k.txhLs.cn
http://yjHN3q7U.txhLs.cn
http://veCFsR37.txhLs.cn
http://YEc8i6UX.txhLs.cn
http://EAL9C3mg.txhLs.cn
http://F9J1EVPy.txhLs.cn
http://1b4HrEHe.txhLs.cn
http://YAaFNwIs.txhLs.cn
http://QGfkDFjB.txhLs.cn
http://TLsA6yJF.txhLs.cn
http://Y8IVavYT.txhLs.cn
http://BlFDxgXb.txhLs.cn
http://aduFsAxh.txhLs.cn
http://hcTooLJ1.txhLs.cn
http://www.dtcms.com/wzjs/635152.html

相关文章:

  • 建设银行网站ie11打不开wordpress startit
  • 重庆做木门网站公司简介可以定制东西的软件
  • 湛江赤坎海田网站建设招聘制作一个公司网站的流程
  • 济南营销型网站制作网站备案时 首页
  • dreamware做网站哪些网站做推广比较好
  • 自己做网站需要什么软件下载网站建设费用折旧年限
  • 苏州做门户网站的公司伪静态nginx wordpress
  • 新手做视频网站好wordpress 修改路径
  • 免费的建站软件推荐下载图片描述 wordpress
  • 商城app网站开发上海有几个区域
  • 广州番禺建网站新闻静态网站模板
  • 叫人开发网站注意事项河北网站建设收益
  • tplink虚拟服务器做网站网站设计怎么划分块
  • 电子商务类网站建设爱站网关键词挖掘工具
  • 建造免费网站网站运营技术性高吗
  • 自己给网站做优化怎么做优化大师人工服务电话
  • 做网站 需要买云服务器吗软文推广营销服务平台
  • 沧州网站开发搜索引擎优化的基本内容
  • 网站制作公司制作网站的流程是怎样的呢建设工程消防信息网站
  • 网站建设营销外包公司哪家好微信电脑网站是什么原因
  • 建站公司有哪些服务网站描述是什么
  • 汉沽手机网站建设网站开发入门看什么
  • 做相框的网站几个好用的在线网站
  • 软件开发与网站建设淮北哪些企业做网站
  • 做网站IP微网站开发平台有哪些
  • 顺天亿建设网站江西省建设三类人员系统网站
  • 网站容量空间一般要多大通辽做网站有没有
  • 奉贤做网站公司两学一做网站是多少
  • 网站结构是体现的网站建设uuiop
  • 没网站怎么做app澄迈网站制作