背景
造成此问题的原因可以分为我们对容器卷的错误配置和docker泄漏(无法释放)写入这些卷的临时数据的问题。我们应该映射(到主机文件夹或其他持久性存储声明)所有容器的临时/日志/临时文件夹,在这些文件夹中我们的应用程序频繁和/或大量写入。Docker不负责清理默认情况下位于的所有自动创建的所谓的EmptyDirs /var/lib/docker/overlay2/*/diff/*
。容器停止后,泊坞窗应自动清除这些“非持久”文件夹中的内容,但显然不会(如果容器仍在运行,则它们甚至可能无法从主机端清除-它可以运行数月一次)。
解决方法
一种变通方法需要仔细的手动清理,并且尽管在其他地方已进行了描述,但您仍然可以从我的案例研究中找到一些提示,我试图使这些提示尽可能具有启发性和概括性。
所以发生了什么事?罪魁祸首的应用程序(以我为例clair-scanner
)成功地在几个月内将数百千兆字节的数据写入了/diff/tmp
docker的子文件夹overlay2
du -sch /var/lib/docker/overlay2/<long random folder name seen as bloated in df -haT>/diff/tmp
271G total
因此,由于其中的所有子文件夹/diff/tmp
都是不言自明的(所有子文件夹的格式clair-scanner-*
都已创建并且具有过时的创建日期),因此我停止了关联的容器(docker stop clair
),并小心地从中删除了这些过时的子文件夹diff/tmp
,并谨慎地从一个(最旧的)开始,然后测试对docker引擎的影响(确实需要重新启动[ systemctl restart docker
]来回收磁盘空间):
rm -rf $(ls -at /var/lib/docker/overlay2/<long random folder name seen as bloated in df -haT>/diff/tmp | grep clair-scanner | tail -1)
我收回了数百GB的磁盘空间,而无需重新安装docker或清除其整个文件夹。必须将所有正在运行的容器都停止在某一点,因为需要重新启动docker daemon来回收磁盘空间,因此请首先确保您的故障转移容器在一个/其他节点上正确运行。我希望该docker prune
命令也可以覆盖过时的/diff/tmp
(甚至/diff/*
)数据(通过另一个开关)。
现在已经有3年的历史了,您可以在Docker论坛上阅读其丰富多彩的历史,该论坛于2019年针对上述解决方案的应用程序日志提出了一个变体,似乎已经在多个设置中起作用:https:// forums.docker.com/t/some-way-to-clean-up-identify-contents-of-var-lib-docker-overlay/30604