容器的overlay文件系统

序言

    由小看大，由虚拟看抽象，其实你也不知道这是一个vm还是一个容器，还是一个物理机。

    容器最常用的文件系统就是overlay的文件系统了，那么了解这个又有什么作用呢？

overlay文件系统

    在使用容器的时候，默认情况下都是使用overlay的驱动来存储，能增强性能，并且当使用overlay2的驱动的时候，可以明显的减少inode的使用量，所以一般在使用容器的时候，会把容器的进程运行在一个单独的目录中，毕竟在使用磁盘的时候，如果已经格式化了，那么磁盘的inode数量就确定了。

   在使用overlay2的文件系统的时候，overlay的驱动是自动加载的，就是当你启动docker进程之后，就会自动加载模块。

    当启动容器之后，那么就会自动挂载相应的目录，一个目录是merged目录，也就是容器层所在的目录，而另外一个则是共享内存空间。在使用mount查看的时候，在其中可以看到文件系统的分层结构，分为lower层，用来存储只读的信息，而merge层，用来显示，也就是容器层，为了节约相应的空间，lower层都是用链接来实现。work目录主要是overlay内部使用的目录，在下载的时候可以看到：

    在最lower的层次，会有一个link的文件，用来表示指向，也就是里面的短名称的链接指向一个文件目录，存在一个小写的l文件来表示这种指向，lower层表示为只读层，由docker自行管理。

    运行一个容器之后，会生成两个目录，一个是init目录，表示初始化的，而另外一个目录则是真正使用的目录，所有的挂载文件也会放在此目录中，在这个里面lower表示lower，也就是底层只读，而对于容器层，则是merged目录，而merged目录只有在运行的时候，才会存在，当容器不运行的时候，merged目录是不存在的。

    而对于diff目录的存在，是将容器增删改的文件放置的目录，也就相当于读写层。

    当容器的内容发生改变之后，那么相应的文件夹内的内容也会发生改变：

    可以看到diff目录中记录了相关被修改和增加删除的文件，而merged目录中则能看到所有的文件。

    总结：overlay的文件存储，就像中文一样，覆盖，从而将所有的目录进行merge，挂载在一个目录之上，从而反应为一个目录。以上所述，又有什么作用？

    

overlay文件系统

     1 背景故事

    使用的事微服务架构，几百个服务在几个物理机上，每个物理机上都运行着几十个docker，突然，大量的服务出现告警，重启试试。。。并不能正常启动。

    2 查看物理机的磁盘空间

    当大量容器无法启动的时候，一般都是因为物理机的磁盘空间不足导致，从而查看物理机的磁盘空间使用率，发现正常。。。

    3 查看docker的日志

    出现报错，无法创建文件，也就是达到了磁盘配额，此处模拟太复杂，可以使用两种磁盘配额的方式，一种是使用grpjquota，一种是project quota来实现。总之就是容器的磁盘空间已经满了，从而容器无法启动。

    4 释放容器的磁盘空间

    在一般的情况下，进行释放磁盘，可以使用df找到相应的merge目录，然后使用磁盘空间，而当容器无法启动的时候，必须使用inspect找到容器相关的diff目录，然后清除相关的磁盘空间；在上面的图中，可以看到创建文件，会直接写入到diff目录中。

    

    其实，最简单的方法就是直接删除容器，然后重新拉一个容器是最好的。当然，要看是否要保留相关的日志，而且要看容器是否是有状态的，无状态的可以直接删除，然后重新拉取镜像运行就好了。

    

    文件系统，挂载，在一棵树上吊死？不可能的。。。联合文件系统，Emm，一种新的思路。。。在使用overlay fs的时候，主要好玩的地方在于，你可以不进入容器，然后删除容器里面的文件，也可以创建文件，也可以修改，但是有些东西删除了会出现问题。。。慎重删除

    在进行删除文件的时候，也反应了另外的一种思路，就是如何找到容器的相关文件，只读的，可读写的，都在不同的目录中。

    限制，到处都是限制。。。在使用容器的时候，不但要限制容器使用的磁盘，还要限制容器使用的cpu，还要限制容器使用的内存，这三个参数是最基本的。