Docker 宿主机磁盘占满：镜像、容器日志与 OverlayFS 排查

Docker 宿主机磁盘占满后，可能出现容器无法启动、镜像拉取失败、应用无法写日志，甚至 Docker 服务异常。处理这类故障的关键是先找到空间真正被谁占用，再做可控清理。

一、确认磁盘和 inode

df -hT
df -ih
docker system df -v

容量还有空间但仍提示 No space left on device 时，要检查 inode。随后确认 Docker Root Dir：

docker info | grep -i 'Docker Root Dir'

二、定位主要占用

du -xhd1 /var/lib/docker | sort -h
du -xhd1 /var/lib/docker/containers | sort -h | tail
du -xhd1 /var/lib/docker/volumes | sort -h | tail
journalctl --disk-usage

常见来源包括：

• 容器 JSON 日志无限增长；

• 长期未清理的镜像、构建缓存和停止容器；

• OverlayFS 可写层写入大量临时文件；

• 匿名数据卷失去归属但仍占空间；

• 文件已删除，进程仍持有文件描述符；

• systemd journal 和应用日志同时增长。

可以用 lsof +L1 检查已删除但未释放的文件。

三、应急处理原则

先停止持续写入的异常任务或限流，再清理已确认无用的数据。执行以下命令前必须逐项核对影响：

docker container prune
docker image prune
docker builder prune

docker system prune -a --volumes 影响范围很大，生产环境不要直接执行。数据卷可能包含业务数据，不能根据“未挂载”就判断为无用。

对于失控的容器日志，应先保留必要现场，再截断对应日志或重启容器释放句柄。不要直接删除 OverlayFS 目录中的文件，否则容易破坏 Docker 元数据。

四、确认是否为容器可写层

docker ps --size
docker inspect <container_id>

如果业务把上传文件、缓存或数据库数据写进容器可写层，应迁移到明确的数据卷或外部存储。容器层适合临时数据，不适合作为持久化存储。

五、长期治理

• 为 Docker JSON 日志设置 max-size 和 max-file。

• 对镜像仓库、构建节点和生产节点制定不同的保留策略。

• 监控磁盘使用率、inode、增长速率和预计耗尽时间。

• 把 Docker Root Dir 放在独立分区，避免拖垮系统盘。

• 定期审计无主镜像、停止容器、构建缓存和数据卷。

• 应用日志优先输出到标准输出，并由日志系统集中采集和保留。

磁盘清理只是止血。真正的治理目标是让镜像、日志、可写层和数据卷都有明确的生命周期与容量边界。