《深入剖析kubernetes》中容器基础技术的入门理解（二）

用做于记录学习过程以及理清思路，文章相当于我对于书中部分复述加上一些我自己的理解。有不对的地方请多多指教。

mount ns

我之前也一直认为，只要通过mount namespace就实现了我现在所看到的docker的文件系统（与其他docker隔离且是一个初始的文件系统的样子）。但后来学习完这个部分发现不仅仅是这样的。
mount namespace介绍一文中介绍到：mount namespace加上shared subtree这一整套实现了不同mount ns之间在同一个挂载点下的各种关系（比如共享 私有 主从等）。

在mountns中，系统会把每个进程的挂载点信息保存在/proc//{mountinfo,mounts,mountstats}三个文件中：

ianhui@node1:~/code$ ls -1 /proc/$$/mount*
/proc/1883758/mountinfo
/proc/1883758/mounts
/proc/1883758/mountstats

当创建mount namespace时，内核将拷贝一份当前namespace的挂载点信息列表到新的mount namespace中，此后两个mount namespace就没有了任何关系

如果需要有关系，在shared substree中可以设定两个namespace的关系，如果是docker那当然失望拥有私有的mount namespace

举个例子就是如果在不同的namespace中，对于同一个挂载点下如果一个namespace新挂载一个目录，那么在另一个namespace中就可能无法看到这些修改。这是因为每个namespace都有自己的视图，对于同一个文件系统的修改可能不会被同步到其他的namespace中。

但是这又有一个问题，实际上，对于同一个挂载点下的子文件，它们的初始状态是可以被所有的namespace看到的。书中也给了一个例子：通过clone()系统调用创建一个新的子进程并为他启用一个mount namespace。而这个子进程执行的是一个/bin/bash也就是一个shell。
此时如果进入容器执行ls命令，就会发现一个有趣的现象：你会发现里面有宿主机的很多文件。

所以就如我刚刚所说的，namespace仅仅解决了ns之间对于挂载点的认知。在容器启动时，容器内部的文件系统视图与宿主机的文件系统视图还是相同的，也就是说，容器内部的文件系统是基于宿主机的文件系统实现的。但是，容器内部的文件系统是与宿主机的文件系统隔离开来的，容器内部的文件修改不会影响到宿主机的文件系统，反之亦然。

但我们实际上希望的是每个容器不仅仅是隔离的而且他的文件系统不能与宿主机文件系统的视图有联系，这样会带来很多安全隐患。

一个简单的想法就是在创建了namespace之后紧接上一个把目录全部重新挂载也就是挂载一个看上去跟新的操作系统一模一样的文件夹到根挂载点中。反正都已经是隔离的，跟其他ns也没什么联系。说到这也可以发现mount namespace的比较特别的地方：他对容器视图的改变一定要伴随着挂载操作才能生效。

那么如果我们希望创建新容器的时候看到的是一个独立的隔离环境，我们能想到可以重新挂载整个根目录“/”，由于每个namespace的挂载点视图我们刚刚说了是隔离的，所以其他ns并不能看见。

而在linux中，一个名为chroot的命令可以直接帮你完成这个操作。这个chroot操作能改变任意进程的根目录到指定目录。也就是说如果进程chroot到目录/home/test，那么这个进程的视图中这个文件夹的目录就是根目录。

在docker中一般也是在创建容器时先创建ns然后新建一个临时文件夹，然后使用chroot函数改变进程的根目录到这个文件夹中。

容器镜像

由于复用的原因，比如我项目a用golang写的所以我容器理所应当帮我下载了golang镜像，这种情况下。我当然不希望我其他项目的底层镜像需要重新下一个完整的golang，要是能够复用相同的部分最好。所以，容器镜像被设计为组合式，也就是增量式。把底层的依赖环境细粒度化，相同的部分复用，不同部分就各自创建。