Docker宿主机磁盘爆掉的几种情况

磁盘爆掉的几种情况

系统磁盘没有空间，解决办法：删掉 /var/log/ 下边的带日期的日志，清空 /var/log/messages 内容
容器使用的大磁盘但是仍然空间不够，有三个地方会使用大量的磁盘
- 容器内部日志非常大，处理办法见方法一
- 容器内部产生非常多或者非常大的文件，但是这个文件的位置又通过volume 挂载到了物理机上，处理办法见方法二
- 对特别老的部署环境，还有可能是容器的系统日志没有限制大小，处理办法见方法三

现场的同学按如下方法依次检查

方法零：检查系统根目录下每个文件夹的大小

sudo du / -lh --max-depth=1 --exclude=overlay --exclude=proc

看看除了容器之外有没有其它目录使用磁盘特别大，如果有那么一层层进去通过du命令来查看，比如：

#sudo du / -lh --max-depth=1 --exclude=overlay --exclude=proc
16K	/dev
16K	/lost+found
4.0K	/media
17G	/home
136M	/boot
832K	/run
1.9G	/usr
75M	/tmp
12K	/log
8.5G	/var
4.0K	/srv
0	/proc
22M	/etc
84G	/root
4.0K	/mnt
508M	/opt
0	/sys
112G	/

那么这个案例中应该查看 /root下为什么用掉了84G（总共用了112G），先 cd /root 然后执行： sudo du . -lh –max-depth=1 –exclude=overlay 进一步查看 /root 目录下每个文件夹的大小

如果方法零没找到占用特别大的磁盘文件，那么一般来说是容器日志占用太多的磁盘空间，请看方法一

方法一：容器内部日志非常大（请确保先按方法零检查过了）

在磁盘不够的物理机上执行如下脚本：

sudo docker ps -a -q >containers.list
sudo cat containers.list | xargs sudo docker inspect $1 | grep merged | awk -F \" '{ print $4 }' | sed 's/\/merged//g' | xargs sudo du  --max-depth=0 $1 >containers.size 
sudo paste containers.list containers.size | awk '{ print $1, $2 }'  | sort -nk2 >real_size.log
sudo tail -10 real_size.log  | awk 'BEGIN {print "\tcontainer     size\tunit"} { print NR":\t" $0"\t kB" }'

执行完后会输出如下格式：

container     size	unit
1:	22690f16822f 3769980	 kb
2:	82b4ae98eeed 4869324	 kb
3:	572a1b7c8ef6 10370404	 kb
4:	9f9250d98df6 10566776	 kb
5:	7fab70481929 13745648	 kb
6:	4a14b58e3732 29873504	 kb
7:	8a01418b6df2 30432068	 kb
8:	83dc85caaa5c 31010960	 kb
9:	433e51df88b1 35647052	 kb
10:	4b42818a8148 61962416	 kb

第二列是容器id，第三列是磁盘大小，第四列是单位，占用最大的排在最后面

然后进到容器后通过 du / –max-depth=2 快速发现大文件

方法二：容器使用的volume使用过大

$sudo du -l /data/lib/docker/defaultVolumes --max-depth=1 | sort -rn
456012884	/data/lib/docker/defaultVolumes
42608332	/data/lib/docker/defaultVolumes/task_3477_g0_ark-metadb_miniDBPaaS-MetaDB_1
32322220	/data/lib/docker/defaultVolumes/task_3477_g0_dbpaas-metadb_dbpaas_1
27461120	/data/lib/docker/defaultVolumes/task_3001_g0_ark-metadb_miniDBPaaS-MetaDB_1
27319360	/data/lib/docker/defaultVolumes/task_36000_g0_ark-metadb_miniDBPaaS-MetaDB
27313836	/data/lib/docker/defaultVolumes/task_3600_g0_dbpaas-metadb_minidbpaas
27278692	/data/lib/docker/defaultVolumes/task_3604_g0_ark-metadb_miniDBPaaS-MetaDB_1
27277004	/data/lib/docker/defaultVolumes/task_3603_g0_ark-metadb_miniDBPaaS-MetaDB_1
27275736	/data/lib/docker/defaultVolumes/task_3542_g0_ark-metadb_miniDBPaaS-MetaDB
27271428	/data/lib/docker/defaultVolumes/task_3597_g0_ark-metadb_miniDBPaaS-MetaDB
27270840	/data/lib/docker/defaultVolumes/task_3603_g0_dbpaas-metadb_minidbpaas_1
27270492	/data/lib/docker/defaultVolumes/task_3603_g0_dbpaas-metadb_minidbpaas
27270468	/data/lib/docker/defaultVolumes/task_3600_g0_ark-metadb_miniDBPaaS-MetaDB
27270252	/data/lib/docker/defaultVolumes/task_3535_g0_ark-metadb_miniDBPaaS-MetaDB
27270244	/data/lib/docker/defaultVolumes/task_3538_g0_ark-metadb_miniDBPaaS-MetaDB
27270244	/data/lib/docker/defaultVolumes/task_3536_g0_ark-metadb_miniDBPaaS-MetaDB
25312404	/data/lib/docker/defaultVolumes/task_3477_g0_dncs-server_middleware-dncs_2

/data/lib/docker/defaultVolumes 参数是默认设置的volume存放的目录（一般是docker的存储路径下 –graph=/data/lib/docker) ，第一列是大小，后面是容器名

volume路径在物理机上也有可能是 /var/lib/docker 或者 /mw/mvdocker/ 之类的路径下，这个要依据安装参数来确定，可以用如下命令来找到这个路径：

sudo systemctl status docker -l | grep --color graph

结果如下，红色参数后面的路径就是docker 安装目录，到里面去找带volume的字眼：

找到 volume很大的文件件后同样可以进到这个文件夹中执行如下命令快速发现大文件：

du . --max-depth=2

方法三容器的系统日志没有限制大小

这种情况只针对2017年上半年之前的部署环境，后面部署的环境默认都控制了这些日志不会超过150M

按照方法二的描述先找到docker 安装目录，cd 进去，然后：

du ./containers --max-depth=2

就很快找到那个大json格式的日志文件了,然后执行清空这个大文件的内容：

echo '' | sudo tee 大文件名

一些其他可能占用空间的地方

机器上镜像太多，可以删掉一些没用的： sudo docker images -q | xargs sudo docker rmi
机器上残留的volume太多，删：sudo docker volume ls -q | xargs sudo docker volume rm
物理文件被删了，但是还有进程占用这个文件句柄，导致文件对应的磁盘空间没有释放，检查： lsof |　grep deleted 如果这个文件非常大的话，只能通过重启这个进程来真正释放磁盘空间

OverlayFS（overlay）的镜像分层与共享

OverlayFS使用两个目录，把一个目录置放于另一个之上，并且对外提供单个统一的视角。这两个目录通常被称作层，这个分层的技术被称作union mount。术语上，下层的目录叫做lowerdir，上层的叫做upperdir。对外展示的统一视图称作merged。　　

如下图所示，Overlay在主机上用到2个目录，这2个目录被看成是overlay的层。 upperdir为容器层、lowerdir为镜像层使用联合挂载技术将它们挂载在同一目录(merged)下，提供统一视图。

注意镜像层和容器层是如何处理相同的文件的：容器层（upperdir）的文件是显性的，会隐藏镜像层（lowerdir）相同文件的存在。容器映射（merged）显示出统一的视图。　　overlay驱动只能工作在两层之上。也就是说多层镜像不能用多层OverlayFS实现。替代的，每个镜像层在/var/lib/docker/overlay中用自己的目录来实现，使用硬链接这种有效利用空间的方法，来引用底层分享的数据。注意：Docker1.10之后，镜像层ID和/var/lib/docker中的目录名不再一一对应。　　创建一个容器，overlay驱动联合镜像层和一个新目录给容器。镜像顶层是overlay中的只读lowerdir，容器的新目录是可写的upperdir。