Overlay2 Inode 耗尽故障排查与恢复操作指南

故障现象与根因

磁盘容量充足（df -h 显示使用率仅50%），但容器写入报错 no space left on device。根本原因是 inode 耗尽。

• 检查命令：df -i。若 IUse% 达到100%，则确定是 inode 问题。
• 触发机制：Docker Overlay2 驱动为每个镜像层和容器层创建大量小文件。CI/CD 频繁构建、容器反复创建销毁，即使数据量很小，也会快速消耗 inode 配额。
• 数据量：一个典型 /dev/vda1 分区 inode 上限为 6553600，耗尽后无法创建任何新文件或目录。

快速定位与诊断

使用以下命令定位 inode 高占用目录，并确认 Docker 目录的负载情况。

• 全局扫描：for i in /*; do echo "$(find $i | wc -l) $i"; done | sort -nr | head。输出结果中，/var/lib/docker 目录通常排在前列。
• Docker 专项：find /var/lib/docker/overlay2 -type f | wc -l。统计 Overlay2 目录下的文件总数，数值越大，inode 压力越高。
• 资源总览：docker system df。查看镜像、容器、卷的磁盘占用和数量，快速识别无用资源。

清理与回收操作

执行清理命令释放 inode。注意操作顺序，先清理最占资源的项。

• 全量清理：docker system prune -a。删除所有未使用的镜像、容器、网络和构建缓存。谨慎使用，会移除所有未被容器引用的镜像层。
• 悬空卷清理：docker volume prune。删除未被任何容器挂载的匿名卷。
• 构建缓存清理：docker builder prune -a。删除 BuildKit 构建缓存。BuildKit 在大量构建场景下，缓存增长速度远超传统模式，占用大量 inode。
• 查看缓存占用：docker buildx du。显示 BuildKit 缓存的具体大小和文件数量。

自动化与架构优化

针对长期运行的 CI/Kubernetes 节点，设置自动回收策略，避免人工干预。

主要功能

• inode 使用率检测：通过 df -i 读取文件系统 inode 总数与已用数，输出百分比，判断是否接近100%上限。
• Overlay2 文件计数：使用 find /var/lib/docker/overlay2 -type f \| wc -l 统计存储驱动层文件总量，直接反映 inode 压力来源。
• Docker 资源总览：docker system df 聚合展示镜像、容器、卷的磁盘与 inode 占用，支持按类型筛选清理。
• 全量垃圾回收：docker system prune -a 递归删除所有未使用的镜像层、容器、网络和构建缓存，释放大量 inode。
• 构建缓存清理：docker builder prune -a 专门清除 BuildKit 构建过程中的中间缓存层，这些缓存文件数量多、体积小，是 inode 消耗大户。
• Kubelet 自动回收：设置 --image-gc-high-threshold 和 --image-gc-low-threshold 参数，当磁盘 inode 使用率达到阈值后，kubelet 自动触发镜像垃圾回收。

使用说明

• 先执行 df -i 确认 inode 使用率。若超过90%，优先执行 docker system prune -a。
• 清理构建缓存时，使用 docker buildx du 查看缓存占用，再用 docker buildx prune -a 删除。
• 对于 CI 节点，设置 docker image prune -a -f --filter "until=168h" 的定时任务。
• Kubernetes 节点需在 kubelet 配置文件中添加 --image-gc-high-threshold=80 参数。

同类竞品对比