overlay2空间耗尽主因是宿主机/var/lib/docker下upperdir、workdir或容器日志膨胀，需从宿主机定位：先df -h确认分区使用率，再du查大upper目录，grep关联容器，find扫描大日志；清理分三类——清空json.log（需重启容器）、处理deleted文件（kill -sigusr1或重启）、清理dangling layer；治本需xfs+pquota、daemon.json设overlay2.size、容器级日志限流及tmpfs隔离，并确保ext4挂载含dtype选项。
overlay2 耗尽空间，90% 以上不是容器内应用写爆了磁盘，而是 /var/lib/docker 所在宿主机分区被 upperdir、workdir 或日志文件悄悄填满——必须从宿主机视角定位和清理，不能只看容器内部。
查清到底是哪个目录在吃空间
overlay2 本身不占空间，它只是挂载点；真正消耗磁盘的是底层目录。先确认宿主机分区是否真的满了：
- 运行
df -h /var/lib/docker—— 如果 Use% ≥ 90%，问题就在这里 - 进到
/var/lib/docker/overlay2，用du -sh */upper | sort -hr | head -5找出最大的upper目录 - 再用
docker ps -q | xargs -n1 docker inspect --format='{{.ID}} {{.Name}}' | grep $(basename 上层目录路径)关联容器名（注意：basename后接的是上一步看到的目录名，如abc123.../upper中的abc123...） - 别漏掉
/var/lib/docker/containers—— 这里存着每个容器的*-json.log，单个日志文件可能达数十 GB，用find /var/lib/docker/containers -name "*-json.log" -size +1G快速扫描
快速释放空间的三类操作
不能等报警才动手，要分场景精准清理：
- 日志文件撑爆？直接清空：
cat /dev/null > /var/lib/docker/containers/*/console-json.log（注意：清完需重启对应容器，否则日志仍会追加到已删除但未关闭的句柄中） - 幽灵文件（deleted but still open）？运行
lsof +L1 | grep docker，找到 PID 后用lsof -p $PID确认哪些deleted文件还在写，然后kill -SIGUSR1 $PID（若进程支持日志 reopen）或重启容器 - 大量 dangling layer？运行
docker system df -v查 “Reclaimable” 列，再执行docker system prune -f --volumes（慎用，会删所有未使用卷）；更安全的是分步：docker image prune -f+docker builder prune+docker volume prune
避免反复踩坑的关键配置
临时清理治标，运行时约束才能治本。overlay2 本身不支持 per-container 磁盘配额，但可通过宿主机文件系统+Docker 配置组合实现：
- 宿主机必须用
xfs文件系统，并挂载时启用pquota：如mount -o pquota,uqnoenforce /dev/mapper/k8s-docker /var/lib/docker -
/etc/docker/daemon.json中加"storage-opts": ["overlay2.size=10G"]（仅对新容器生效，且依赖 xfs + pquota） - 容器启动时强制限制日志：
docker run --log-opt max-size=10m --log-opt max-file=3 ...，避免*-json.log无限增长 - 禁止容器内向
/tmp或/var/log写大量临时数据：改用--tmpfs /tmp:rw,size=100m或挂载 hostPath 独立目录
最常被忽略的一点：d_type=true。如果宿主机 ext4 分区没加 dtype 挂载选项（mount | grep "$(df . | tail -1 | awk '{print $1}')" | grep -o "dtype" 可查），overlay2 会退化为低效模式，copy-up 频率翻倍，upperdir 膨胀更快——这不是 Docker 配置能绕过的，必须改 fstab 并 remount。
