k8s 深入篇———— 一些容器操作的原理[三]

前言

简单介绍一下一些容器的操作原理。

正文

docker exec 是怎么做到进入容器里的呢。

比如说：

这里有一个容器，我们可以exec 进去:

 docker exec -it b265 /bin/sh

我们为什么能看到和容器内部一样的场景呢？

首先我们知道了为什么容器进程只能看到规定的namespace了，那么如果我们能拿到这个namespace的信息，那么我们就能看到容器进程一样的场景了。

docker inspect --format '{{ .State.Pid }}' b26585ee826b

上面可以查看容器进程。

可以查看namespace信息。

#define _GNU_SOURCE
#include <fcntl.h>
#include <sched.h>
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>

#define errExit(msg) do { perror(msg); exit(EXIT_FAILURE);} while (0)

int main(int argc, char *argv[]) {
int fd;

fd = open(argv[1], O_RDONLY);
if (setns(fd, 0) == -1) {
errExit("setns");
}
execvp(argv[2], &argv[2]);
errExit("execvp");
}

写入到文件中，然后编译:

tee exectest.c <<- 'EOF'
> #define _GNU_SOURCE
> #include <fcntl.h>
> #include <sched.h>
> #include <unistd.h>
> #include <stdlib.h>
> #include <stdio.h>
>
> #define errExit(msg) do { perror(msg); exit(EXIT_FAILURE);} while (0)
>
> int main(int argc, char *argv[]) {
> int fd;
>
> fd = open(argv[1], O_RDONLY);
> if (setns(fd, 0) == -1) {
> errExit("setns");
> }
> execvp(argv[2], &argv[2]);
> errExit("execvp");
> }
> EOF

gcc -o exectest exectest.c

然后运行./exectest:

./exectest /proc/17240/ns/mnt /bin/sh

那么看下这个进程看到的信息是啥：

./exectest /proc/17240/ns/mnt /bin/sh

看到的信息：

这段代码的的核心操作，则是通过 open() 系统调用打开了指定的 Namespace 文件，并把

这个文件的描述符 fd 交给 setns() 使用。在 setns() 执行后，当前进程就加入了这个文件

对应的 Linux Namespace 当中了

你也可以将网络带进去:

正如上所示，当我们执行 ifconfig 命令查看网络设备时，我会发现能看到的网卡“变

少”了：只有两个。而我的宿主机则至少有四个网卡。这是怎么回事呢？

实际上，在 setns() 之后我看到的这两个网卡，正是我在前面启动的 Docker 容器里的网

卡。也就是说，我新创建的这个 /bin/bash 进程，由于加入了该容器进程（PID=25686）

的 Network Namepace，它看到的网络设备与这个容器里是一样的，即：/bin/bash 进程

的网络设备视图，也被修改了。

而一旦一个进程加入到了另一个 Namespace 当中，在宿主机的 Namespace 文件上，也

会有所体现。

其实就是将自己的namespace 指向了原来容器进程的namespace。

查看进程号:

发现和原来的17240进程的net一样。

此外，Docker 还专门提供了一个参数，可以让你启动一个容器并“加入”到另一个容器的

Network Namespace 里，这个参数就是 -net，比如:

docker run -it --net container:4ddf4638572d busybox ifconfig

而如果我指定–net=host，就意味着这个容器不会为进程启用 Network Namespace。这

就意味着，这个容器拆除了 Network Namespace 的“隔离墙”，所以，它会和宿主机上

的其他普通进程一样，直接共享宿主机的网络栈。这就为容器直接操作和使用宿主机网络提

供了一个渠道。

docker commit 干了啥？ 比如我们提交一个容器。

docker commit，实际上就是在容器运行起来后，把最上层的“可读写层”，加上原先容

器镜像的只读层，打包组成了一个新的镜像。当然，下面这些只读层在宿主机上是共享的，

不会占用额外的空间。

而由于使用了联合文件系统，你在容器里对镜像 rootfs 所做的任何修改，都会被操作系统

先复制到这个可读写层，然后再修改。这就是所谓的：Copy-on-Write。

而正如前所说，Init 层的存在，就是为了避免你执行 docker commit 时，把 Docker 自己

对 /etc/hosts 等文件做的修改，也一起提交掉。

前面我已经介绍过，容器技术使用了 rootfs 机制和 Mount Namespace，构建出了一个同

宿主机完全隔离开的文件系统环境。这时候，我们就需要考虑这样两个问题：

1. 容器里进程新建的文件，怎么才能让宿主机获取到？
2. 宿主机上的文件和目录，怎么才能让容器里的进程访问到？
   
   这正是 Docker Volume 要解决的问题：Volume 机制，允许你将宿主机上指定的目录或
   
   者文件，挂载到容器里面进行读取和修改操作。

在 Docker 项目里，它支持两种 Volume 声明方式，可以把宿主机目录挂载进容器的 /test

目录当中：

docker run -v /test ...
docker run -v /home:/test ...

而这两种声明方式的本质，实际上是相同的：都是把一个宿主机的目录挂载进了容器的/test 目录。

只不过，在第一种情况下，由于你并没有显示声明宿主机目录，那么 Docker 就会默认在宿

主机上创建一个临时目录 /var/lib/docker/volumes/[VOLUME_ID]/_data，然后把它挂载

到容器的 /test 目录上。而在第二种情况下，Docker 就直接把宿主机的 /home 目录挂载

到容器的 /test 目录上

当容器进程被创建之后，尽管开启了 Mount Namespace，但是在它执行 chroot（或者 pivot_root）之前，容器进程一直可以看到宿主机上的整个文件系统

而宿主机上的文件系统，也自然包括了我们要使用的容器镜像。这个镜像的各个层，保存在

/var/lib/docker/aufs/diff 目录下，在容器进程启动后，它们会被联合挂载在

/var/lib/docker/aufs/mnt/ 目录中，这样容器所需的 rootfs 就准备好了。

所以，我们只需要在 rootfs 准备好之后，在执行 chroot 之前，把 Volume 指定的宿主机

目录（比如 /home 目录），挂载到指定的容器目录（比如 /test 目录）在宿主机上对应的

目录（即 /var/lib/docker/aufs/mnt/[可读写层 ID]/test）上，这个 Volume 的挂载工作

就完成了。

更重要的是，由于执行这个挂载操作时，“容器进程”已经创建了，也就意味着此时

Mount Namespace 已经开启了。所以，这个挂载事件只在这个容器里可见。你在宿主机

上，是看不见容器内部的这个挂载点的。这就保证了容器的隔离性不会被 Volume 打破。

注意：这里提到的 " 容器进程 "，是 Docker 创建的一个容器初始化进程
(dockerinit)，而不是应用进程 (ENTRYPOINT + CMD)。dockerinit 会负责
完成根目录的准备、挂载设备和目录、配置 hostname 等一系列需要在容器
内进行的初始化操作。最后，它通过 execv() 系统调用，让应用进程取代自
己，成为容器里的 PID=1 的进程。

而这里要使用到的挂载技术，就是 Linux 的绑定挂载（bind mount）机制。它的主要作

用就是，允许你将一个目录或者文件，而不是整个设备，挂载到一个指定的目录上。并且，

这时你在该挂载点上进行的任何操作，只是发生在被挂载的目录或者文件上，而原挂载点的

内容则会被隐藏起来且不受影响

所以，在一个正确的时机，进行一次绑定挂载，Docker 就可以成功地将一个宿主机上的目

录或文件，不动声色地挂载到容器中。

这样，进程在容器里对这个 /test 目录进行的所有操作，都实际发生在宿主机的对应目录

（比如，/home，或者 /var/lib/docker/volumes/[VOLUME_ID]/_data）里，而不会影响

容器镜像的内容。

那么，这个 /test 目录里的内容，既然挂载在容器 rootfs 的可读写层，它会不会被 docker

commit 提交掉呢？

也不会。

这个原因其实我们前面已经提到过。容器的镜像操作，比如 docker commit，都是发生在

宿主机空间的。而由于 Mount Namespace 的隔离作用，宿主机并不知道这个绑定挂载的

存在。所以，在宿主机看来，容器中可读写层的 /test 目录

（/var/lib/docker/aufs/mnt/[可读写层 ID]/test），始终是空的。

不过，由于 Docker 一开始还是要创建 /test 这个目录作为挂载点，所以执行了 docker

commit 之后，你会发现新产生的镜像里，会多出来一个空的 /test 目录。毕竟，新建目录

操作，又不是挂载操作，Mount Namespace 对它可起不到“障眼法”的作用。

实验:

docker run -d -v /test nginx

查看挂载信息:

那么是哪一个呢？

docker inspect a9c79

直接看这个好了。

docker exec -it a9c79 /bin/bash

然后运行一下:

在里面写了一下文件.

然后看下这个目录里面有不。

然后我们看下读写层有不:

有一个test 目录，但是是空的。

可以确认，容器 Volume 里的信息，并不会被 docker commit 提交掉；但这个挂载点目录 /test 本身，则会出现在新的镜像当中。

如果你执行 docker run -v /home:/test 的时候，容器镜像里的 /test 目录下本来就有内容的话，你会发现，在宿主机的 /home 目录下，也会出现这些内容。这是怎么回事？为什么它们没有被绑定挂载隐藏起来呢？（提示：Docker 的“copyData”功能）

结

下一节k8s的本质。