Basics of Container Isolation 容器隔离的实现原理

目录

容器隔离的实现原理

1. 使用cgroups实现资源隔离

自定义一个cgroup

设置进程的内存使用

启动一个docker 容器，观察cgroup的创建情况

2. 使用Namespaces进行资源分区

namespace继承关系引发的问题

3. 结合来使用Namespaces 和chroot

4. 结论

参考文档

---

容器隔离的实现原理

docker 是一个神奇的工具，它能够轻松创建 docker 镜像并快速启动一个完全隔离资源的容器，但它是如何实现资源隔离的呢？

大致来说，docker通过Linux的cgroups 、namespaces、chroot实现容器隔离，在这篇文章中，我们将通过使用linux基础命令来构造进程隔离，就像docker容器中那样

1. 使用cgroups实现资源隔离

在 Linux 中，控制组 (cgroups) 是一项内核功能，它允许隔离一组进程的资源使用，例如 CPU、内存、磁盘 IO、网络等。

Linux 中的每种类型的资源都有一个 cgroup 层次结构。 这些层次结构表示为 /sys/fs/cgroup 中的伪文件系统。

在这个目录下可以看到很多cgroups：

allen@localhost:/sys/fs/cgroup$ ls

blkio cpu cpu,cpuacct cpuacct cpuset devices freezer hugetlb memory net_cls net_cls,net_prio net_prio perf_event pids rdma systemd unified

正如文件夹名称所固有的那样，这些条目中的每一个都负责一种类型的资源。 如果你进一步查看其中一个文件夹，可以看到可以各种属性控制文件。 例如，让我们看一下内存 cgroup：

allen@localhost:/sys/fs/cgroup$ ls memorycgroup.procs

memory.soft_limit_in_bytes memory.limit_in_bytes memory.max_usage_in_bytes memory.usage_in_bytes

如上面命令的输出所示，每一个文件都控制一个特定的属性。 例如，memory.limit_in_bytes 控制此 cgroup 中的进程可以使用的最大内存， cgroup.procs 的文件包含属于该 cgroup 的所有进程的列表。 你可以修改其中一些文件来改变 cgroup 的行为（如调整memory.soft_limit_in_bytes使这组cgroup有更大的内存使用率），其中一些文件由内核编写，用于维护cgroup 当前的状态。

自定义一个cgroup

你可以为特定资源（例如内存）创建一个属于自己的 cgroup，方法是在该资源的 cgroup 目录下创建一个目录。

allen@localhost:~# mkdir /sys/fs/cgroup/memory/allen

Linux kernel会自动在这个目录下创建一些必要的文件

allen@localhost:~# ls /sys/fs/cgroup/memory/allen
cgroup.clone_children memory.kmem.failcnt memory.kmem.tcp.limit_in_bytes memory.max_usage_in_bytes memory.move_charge_at_immigrate memory.stat tasks cgroup.event_control memory.kmem.limit_in_bytes memory.kmem.tcp.max_usage_in_bytes memory.memsw.failcnt memory.numa_stat memory.swappiness cgroup.procs memory.kmem.max_usage_in_bytes memory.kmem.tcp.usage_in_bytes memory.memsw.limit_in_bytes memory.oom_control memory.usage_in_bytes memory.failcnt memory.kmem.slabinfo memory.kmem.usage_in_bytes memory.memsw.max_usage_in_bytes memory.pressure_level memory.use_hierarchy memory.force_empty memory.kmem.tcp.failcnt memory.limit_in_bytes memory.memsw.usage_in_bytes memory.soft_limit_in_bytes notify_on_release

设置进程的内存使用

我们可以改写memory.limit_in_bytes 来限制内存使用大小，比如100kbs（表示最多使用100kbs）

echo 100000 > /sys/fs/cgroup/memory/sushil/memory.limit_in_bytes

通过将 shell 的 PID 写入 /sys/fs/cgroup/memory/allen/cgroup.procs，来将当前 shell 添加到此 cgroup。此操作的意义在于，当你用在继续使用bash时（属于当前用户的），它能够调用的内存资源是100kbs

allen@localhost:/sys/fs/cgroup# ps

PID TTY TIME CMD

1973 pts/1 00:00:00 sudo

1974 pts/1 00:00:00 su

1975 pts/1 00:00:00 bash

1983 pts/1 00:00:00 ps

allen@localhost:/sys/fs/cgroup# echo 1975 > /sys/fs/cgroup/memory/allen/cgroup.procs

启动一个docker 容器，观察cgroup的创建情况

我们启动一个 docker 容器，看看它是否创建了一个单独的 cgroup。

allen@localhost:~$ sudo docker run -d -m 100m nginx
Unable to find image 'nginx:latest' locally
latest: Pulling from library/nginx
c229119241af: Pull complete 
2215908dc0a2: Pull complete 
08c3cb2073f1: Pull complete 
18f38162c0ce: Pull complete 
10e2168f148a: Pull complete 
c4ffe9532b5f: Pull complete 
Digest: sha256:2275af0f20d71b293916f1958f8497f987b8d8fd8113df54635f2a5915002bf1
Status: Downloaded newer image for nginx:latest
17fa32e039f2dcd8ad7dfbb0a9eb192ff01f38f47a8befd7cbf3040ef5a4d20a

在这里，我们启动了一个内存限制为 100 MB 的 nginx container， 接下来我们将检查这个容器是否有内存 cgroup（cgroup 将使用容器 ID 创建）

allen@localhost:~$ lscgroup memory:/ | grep 17fa32e039f2dcd8ad7dfbb0a9eb192ff01f38f47a8befd7cbf3040ef5a4d20a
memory:/docker/17fa32e039f2dcd8ad7dfbb0a9eb192ff01f38f47a8befd7cbf3040ef5a4d20a

确实有创建内存的cgroup， 我们检查 memory.limit_in_bytes 文件看看内存限制是多少(该值是通过将 100MB 转换为 KB 来设置的)：

allen@localhost:~$ cat /sys/fs/cgroup/memory/docker/17fa32e039f2dcd8ad7dfbb0a9eb192ff01f38f47a8befd7cbf3040ef5a4d20a/memory.limit_in_bytes 104857600

通过以上操作我们可以了解到，容器可以通过cgroup 来限制每个容器的资源使用， 当你启动容器时，运行时会创建一个单独的 cgroup 来设置资源限制。

任何超过 cgroup 限制的行为，都会使内核终止该容器来处理，并且容器运行时将抛出 OOM 错误。接下来让我们了解一下Linux Namespaces的用法。

2. 使用Namespaces进行资源分区

Namespaces 是 Linux 内核的一项功能，它允许为一组进程划分资源。 简单来说，如果 cgroups 限制了资源的使用，Namespaces 则限制了进程可以看到的资源。 通过将进程放在Namespaces 中，你可以限制它可以看到的资源，它对内核资源进行分区，以便一组进程看到一组资源，而另一组进程看到另一组资源。Linux通过将一组资源和进程放在相同Namespaces 来工作（比如pid 101 ，对应资源net101、cpu101、memory101）。

以下是不同类型的Namespaces（请查看文章下方的参考文档了解更多）：

1. Mount (mnt)
2. Process ID (pid)
3. Network (net)
4. Interprocess Communication (ipc)
5. Unix Timesharing System (uts)
6. User ID (user)
7. Control Group (cgroup)

每个进程属于以上7种类型中的其中一种，你可以使用 lsns 命令在系统上查看不同的Namespaces ，每个进程都与一个命名空间关联，并且只能查看或使用与该命名空间关联的资源。

allen@localhost:~$ lsnsNS TYPE   NPROCS   PID USER        COMMAND
4026531835 cgroup      3  1588 allengcp /lib/systemd/systemd --user
4026531836 pid         3  1588 allengcp /lib/systemd/systemd --user
4026531837 user        3  1588 allengcp /lib/systemd/systemd --user
4026531838 uts         3  1588 allengcp /lib/systemd/systemd --user
4026531839 ipc         3  1588 allengcp /lib/systemd/systemd --user
4026531840 mnt         3  1588 allengcp /lib/systemd/systemd --user
4026531992 net         3  1588 allengcp /lib/systemd/systemd --user

namespace继承关系引发的问题

容器使用namespaces 来划分不同的资源。 例如，每个容器都有自己的主机名、自己的网络堆栈、自己的一组 cgroup，并且只能看到在其中运行的进程。 这是通过为每个容器创建单独的namespaces 来实现的。 namespace的一个特性是，子进程可以继承父进程的namespace。

这个继承的特性在容器技术中是要想办法屏蔽的，为了帮助读者理解这一点，请看下面的一个操作实例。

当你从当前的 shell（shl1） 启动另一个 shell(shl2)，shl2将成为当前 shl1 的子进程，并将继承其namespaces 。 我们先执行ps获取当前 shell 进程可以看到的进程列表, 接下来使用 sh命令启动一个新的 shell （shl2）,并调用ps查看进程表.

allen@localhost:~$ psPID TTY          TIME CMD1815 pts/1    00:00:00 bash16787 pts/1    00:00:00 ps
allen@localhost:~$ sh 
$psPID TTY          TIME CMD1815 pts/1    00:00:00 bash16788 pts/1    00:00:00 sh16789 pts/1    00:00:00 ps

你可以看到，在shl2中，可以看到bash 1815，这个进程是属于父进程shl1的，也就是说子 shell 进程可以看到父进程里所有的进程，这一特性对docker 容器来说，是不可接受的。 每个容器应该只能看到自己的子进程，仅此而已。

我们继续实验，使用 unshare 命令在新的 pid 命名空间中启动子进程，--fork 参数是为了sh进程继承unshare 进程，而不是继承 sudo 进程（否则它会继承sudo）

补充：unshare用于取消共享的命名空间，或切断命名空间的继承关系

通过sudo lsns 命令来验证 sh 进程是否在新的 PID 命名空间中运行。

allen@localhost:~$ sudo unshare --pid --fork sh 
# ps 
PID   TTY TIME CMD 
26168 pts/1 00:00:00 sudo 
26169 pts/1 00:00:00 unshare  
26170 pts/1 00:00:00 sh 
26171 pts/1 00:00:00 ps
#sudo lsns
NS TYPE NPROCS PID USER COMMAND
4026532203 mnt 1 200 root /lib/systemd/systemd-udevd
4026532204 uts 1 200 root /lib/systemd/systemd-udevd
4026532251 mnt 1 427 systemd-network /lib/systemd/systemd-networkd
4026532252 mnt 1 432 systemd-resolve /lib/systemd/systemd-resolved
4026532253 mnt 2 1245 _chrony /usr/sbin/chronyd -F -1
4026532314 mnt 1 916 root /lib/systemd/systemd-logind
4026532315 uts 1 916 root /lib/systemd/systemd-logind
4026532326 pid 1 26170 root shallen@localhost:~$ sudo lsns
NS TYPE NPROCS PID USER COMMAND 
4026532203 mnt 1 200 root /lib/systemd/systemd-udevd 
4026532204 uts 1 200 root /lib/systemd/systemd-udevd 
4026532251 mnt 1 427 systemd-network /lib/systemd/systemd-networkd 
4026532252 mnt 1 432 systemd-resolve /lib/systemd/systemd-resolved 
4026532253 mnt 2 1245 _chrony /usr/sbin/chronyd -F -1 
4026532314 mnt 1 916 root /lib/systemd/systemd-logind 
4026532315 uts 1 916 root /lib/systemd/systemd-logind 
4026532326 pid 1 26170 root sh

很显然，新的 shell 进程仍然可以看到系统范围内的进程与其namespace，也就是说即使使用unshare隔绝了共享空间，但子shell任然可以看到父shell的内容，为什么呢？

这是由于ps本身的性质所导致的，如果你对这个命令底层比较了解的话，你会发现它读取的是主机/proc 目录中的文件，如果你从子 shell 进程中列出 proc 目录，你会发现它与主机的信息是一模一样的

补充：/proc 目录是一个位于内存中的伪文件系统。该目录下保存的并不是真正的文件和目录，而是一些【运行时】的信息，如 CPU 信息、负载信息、系统内存信息、磁盘 IO 信息等。

allen@localhost:~$ sudo unshare --pid --fork sh

# ls /proc

1 115 128 16190 17 20 25 26286 3 321 4 579 79 87 941 buddyinfo diskstats interrupts kmsg misc schedstat sysrq-trigger vmallocinfo

......

这样就说明，需要为我们的子 shell 进程提供一个单独的根目录，因为 /proc 文件位于根目录中。 就像容器看不到整个主机文件系统一样，我们必须为我们的进程创建一个新根以限制它读取主机的 /proc 文件或任何文件。

这里就需要用到 chroot 这个命令。 chroot 允许更改任何进程的根目录，一旦完成，进程将失去对新根目录之上任何内容的访问权限，因为根目录是任何进程的最顶层目录

命令格式为：sudo chroot NEW_ROOT_DIR RUN_COMMAND

chroot 运行一条命令，并将根设置为新根。 如果未给出 RUN_COMMAND，则默认为 ${SHELL}。

allen@localhost:~$ echo $SHELL

/bin/bash

allen@localhost:~$ mkdir new_root

allen@localhost:~$ sudo chroot new_root

chroot: failed to run command ‘/bin/bash’: No such file or directory

这里报错了，是因为 new_root 目录是空的并且没有 /bin/bash 文件。 新根目录下没有命令和文件。容器可以解决这个问题，当你运行容器时，新进程获取新根目录，docker image中包含新根路径下的内容和执行命令，并会对这个新根目录进行填充

下载 new_root 目录下的 alpine linux，看看我们的新进程是否可以使用它。

$ mkdir alpine & cd alpine

$ curl -o alpine.tar.gz http://dl-cdn.alpinelinux.org/alpine/v3.10/releases/x86_64/alpine-minirootfs-3.10.0-x86_64.tar.gz$ tar -xvf alpine.tar.gz 

我们现在将 alpine 目录作为根目录。

allen@localhost:~$ sudo chroot alpine ls
bin    dev    etc    home   lib    media  mnt    opt    proc   root   run    sbin   srv    sys    tmp    usr    var

新进程现在可以看到由 alpine linux 实例化的根文件系统。 使用这个新的根创建一个 shell ，发出 ps 命令，看到一个空列表。 你可以通过 /proc 目录来验证这一点（也是空的）。 现在我们的新进程有一个独立于主机的 /proc 目录。 现在，新进程可以在单独的 PID 命名空间中使用该目录来写入进程信息。

allen@localhost:~$ sudo chroot alpine sh
/ # ps
PID   USER     TIME  COMMAND
/ #

3. 结合来使用Namespaces 和chroot

现在让我们结合使用 unshare 和 chroot 为这个进程提供一个单独的 /proc 目录。

allen@localhost:~$ sudo unshare --pid --fork chroot alpine sh
/ # ls
bin    dev    etc    home   lib    media  mnt    opt    proc   root   run    sbin   srv    sys    tmp    usr    var
/ # ps
PID   USER     TIME  COMMAND
/ #

结果你仍然看不到任何进程信息。 那是因为您需要将 /proc 目录挂载为 proc 类型的伪文件系统。

mount -t proc /proc /proc

此命令指示将 /proc 目录挂载到 /proc，类型为 proc， 完成后再次发出 ps 命令，你将开始看到进程信息。

/ # mount -t proc /proc /proc
/ # ps
PID   USER     TIME  COMMAND1 root      0:00 sh5 root      0:00 ps

可以看到 PID 已在此 shell 中重置，这说明这一进程确实位于单独的 PID 命名空间中。

4. 结论

我们来进行一下复盘，首先我们了解了cgroups的原理，即对资源进行隔离，它允许隔离一组进程的资源使用，我们将这个概念具体化： 假设一台主机的资源CPU、内存、磁盘 IO、网络分别为100%，现在我们有4个进程，需要均分这些资源，显然每个进程将分配到25%的资源。那这里会产生一个问题，怎么确保进程间不能互相访问资源呢？

于是我们就需要Namespaces 命名空间来隔绝进程间的资源访问， 即 cgroups 限制了资源的使用，Namespaces 则限制了进程可以看到的资源。 通过将进程放在Namespaces 中，你可以限制它可以看到的资源，它对内核资源进行分区，以便一组进程看到一组资源，而另一组进程看到另一组资源。Namespaces无法解决的一个问题是，子进程可以继承父进程的namespace，也就是说，你通过宿主机的docker run命令运行了容器，但这个容器是可以看到父进程即宿主机的进程内容的，这是非常大的安全隐患，于是我们想到使用unshare命令。

Linux unshare 命令可以阻断进程对命名空间的继承关系，但是却无法阻断Linux 中文件的存放关系，ls /proc就是一个很好的例子，这个目录保存了系统【运行时】的状态信息，它是位于根下的，我们使用命令来查询状态，本质上是读取文件目录下的数据信息，这里我用指针的概念来阐述一下，假设有p1,p2都指向rom1,现在从逻辑上将p2执指向rom2,然而rom1和rom2使用的任然是同一块物理内存，所以结果不会改变

于是又引入了 chroot 这个命令。 chroot 允许更改任何进程的根目录，一旦完成，进程将失去对新根目录之上任何内容的访问权限，这样的话，我们就可以为rom2开设一块新的地址，从而在逻辑与实际意义上都切断联系，现在，新进程可以在单独的 PID 命名空间中使用该目录来写入进程信息。

参考文档

https://en.wikipedia.org/wiki/Linux_namespaces

https://blog.devgenius.io/basics-of-container-isolation-5eabdb258409