透過這篇文章你可以瞭解到 Docker 容器的核心實現原理，包括 Namespace、Cgroups、Rootfs 等三個核心功能。
如果你對雲原生技術充滿好奇，想要深入瞭解更多相關的文章和資訊，歡迎關注微信公眾號。
搜尋公眾號【探索雲原生】即可訂閱
後續文章會演示如何從零實現一個簡易的 Docker，這裡先簡單瞭解下 Docker 的核心原理。
首先我們思考一個問題：容器與程式有何不同？
程式：就是程式執行起來後的計算機執行環境的總和。
即：計算機記憶體中的資料、暫存器裡的值、堆疊中的指令、被開啟的檔案，以及各種裝置的狀態資訊的一個集合。
容器：核心就是透過約束和修改程式的動態表現，從而為其創造出一個“邊界”。
對於 Docker 等大多數 Linux 容器來說，Cgroups 技術是用來製造約束的主要手段，而 Namespace 技術則是用來修改程式檢視的主要方法。
1. 基於 Namespace 的檢視隔離
當我們透過 docker run -it 啟動並進入一個容器之後，會發現不論是程式、網路還是檔案系統，好像都被隔離了,就像這樣：
[root@docker cpu]# docker run -it busybox
/ #
/ # ps
PID USER TIME COMMAND
1 root 0:00 sh
7 root 0:00 ps
/ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
120: eth0@if121: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue
link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0
valid_lft forever preferred_lft forever
/ # ls
bin dev etc home lib lib64 proc root sys tmp usr var
- ps 命令看不到宿主機上的程式
- ip 命令也只能看到容器內部的網路卡
- ls 命令看到的檔案好像也和宿主機不一樣
這就是 Docker 核心之一，藉助 Linux Namespace 技術實現了檢視隔離。
看起來容器和宿主機隔離開了
在 Linux 下可以根據隔離的屬性不同分為不同的 Namespace ：
- 1）PID Namespace
- 2）Mount Namespace
- 3）UTS Namespace
- 4）IPC Namespace
- 5）Network Namespace
- 6）User Namespace
透過不同型別的 Namespace 就可以實現不同資源的隔離，比如前面透過 ip a 只能看到容器中的網路卡資訊，就是透過 Network Namespace進行了隔離。
不過 Linux Namespace 技術實際上修改了應用程式看待整個計算機“檢視”，即它的“視線”被作業系統做了限制，只能“看到”某些指定的內容。
我們只需要進入到對應 namespace 就可以突破這個隔離了,演示一下：
首先啟動一個 busybox，然後使用 ip a 檢視網路卡資訊
[root@docker ~]# docker run --rm -it busybox /bin/sh
/ #
/ # ip a show eth0
116: eth0@if117: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue
link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0
valid_lft forever preferred_lft forever
容器中 ip 為 172.17.0.2
然後在新終端中透過 nsenter 進入到該容器 network namespace 試試:
首先透過 docker inspect 命令找到容器對應的 PID
[root@docker ~]# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
75e821d24261 busybox "/bin/sh" 32 seconds ago Up 31 seconds great_heisenberg
[root@docker ~]# docker inspect -f '{{.State.Pid}}' 75e821d24261
3533
然後使用 nsenter --net 命令進入該 PID 對應程式的 network namespace
[root@docker ~]# nsenter --target 3533 --net
[root@docker ~]# ip a show eth0
116: eth0@if117: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0
valid_lft forever preferred_lft forever
可以看到，此時我們執行 ip a 拿到的資訊和在容器中執行是完全一致的。
說明 Docker 確實是使用 namespace 進行隔離的。
這裡順便提一下 Namespace 存在的問題，Namespace 最大的問題就是隔離得不徹底。
- 首先，既然容器只是執行在宿主機上的一種特殊的程式，那麼多個容器之間使用的就還是同一個宿主機的作業系統核心。
所以，也出現了像 Firecracker、gVisor、Kata 之類的沙箱容器，不使用共享核心來提升安全性。
- 其次，在 Linux 核心中，有很多資源和物件是不能被 Namespace 化的，最典型的例子就是：時間。
容器中修改了時間，實際修改的是宿主機的時間，會導致所有容器時間都被修改，因為是共享的。
2. 基於 Cgroups 的資源限制
docker run 啟動容器時可以透過增加 --cpus 或者 --memory flag 來指定 cpu、記憶體限制。
就像這樣：透過 --cpus=0.5 限制只能使用 0.5 個核心，然後執行一個 while 死迴圈，並檢視 cpu 佔用情況。
[root@docker ~]# docker run -d --cpus 0.5 busybox sh -c "while true; do :; done"
d281fb2dc96cff371e9607197502c6ea3e04f4d0f3fd2ad38991c2321271736b
檢視 CPU 佔用情況
[root@docker ~]# top
top - 15:38:20 up 286 days, 4:02, 3 users, load average: 0.72, 0.46, 0.36
Tasks: 96 total, 2 running, 48 sleeping, 0 stopped, 0 zombie
%Cpu(s): 52.0 us, 0.0 sy, 0.0 ni, 47.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.3 st
KiB Mem : 1006956 total, 157876 free, 201008 used, 648072 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 538972 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3763 root 20 0 4392 400 336 R 50.0 0.0 0:49.43 sh
3790 root 20 0 162112 4416 3724 R 0.3 0.4 0:00.01 top
1 root 20 0 43884 4280 2552 S 0.0 0.4 1:56.18 systemd
可以看到，因為限制了 cpu 為 0.5，因此只佔用了 0.5 核心，也就是 top 命令中看到的 50。
這就是 Docker 另一個核心功能，基於 Linux Cgroups 技術實現的資源限制。
Linux Cgroups 就是 Linux 核心中用來為程式設定資源限制的一個重要功能。
Linux Cgroups 的全稱是 Linux Control Group。
它最主要的作用，就是限制一個程式組能夠使用的資源上限，包括 CPU、記憶體、磁碟、網路頻寬等等。
在 Linux 中，Cgroups 給使用者暴露出來的操作介面是檔案系統，即它以檔案和目錄的方式組織在作業系統的 /sys/fs/cgroup 路徑下，可以使用
mount -t cgroup 命令進行檢視，大概長這樣：
[root@docker ~]# mount -t cgroup
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)
cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
可以看到，在/sys/fs/cgroup 下面有很多諸如 cpuset、cpu、 memory 這樣的子目錄，也叫子系統。
即：這臺機器當前可以被 Cgroups 進行限制的資源種類。
比如，對 CPU 子系統來說，我們就可以看到如下幾個配置檔案：
[root@docker ~]# ls /sys/fs/cgroup/cpu
cgroup.clone_children cgroup.sane_behavior cpuacct.stat cpuacct.usage_all cpuacct.usage_percpu_sys cpuacct.usage_sys cpu.cfs_period_us cpu.rt_period_us cpu.shares docker release_agent tasks
cgroup.procs cpuacct.usage cpuacct.usage_percpu cpuacct.usage_percpu_user cpuacct.usage_user cpu.cfs_quota_us cpu.rt_runtime_us cpu.stat notify_on_release system.slice user.slice
這些配置檔案定義瞭如何對 CPU 進行限制，以及需要對哪些程式進行限制。
那麼配置檔案又如何使用呢？下面我們來演示一下具體使用。
例子：限制 CPU 使用
你需要在對應的子系統下面建立一個目錄，比如，我們現在進入 /sys/fs/cgroup/cpu 目錄下建立一個名為 container 的目錄：
[root@docker ~]# cd /sys/fs/cgroup/cpu
[root@docker cpu]# mkdir container
這個目錄就是一個“控制組”。
你會發現，作業系統會在你新建立的 container 目錄下，自動生成該子系統對應的資源限制檔案。
[root@docker cpu]# ls container
cgroup.clone_children cpuacct.stat cpuacct.usage_all cpuacct.usage_percpu_sys cpuacct.usage_sys cpu.cfs_period_us cpu.rt_period_us cpu.shares notify_on_release
cgroup.procs cpuacct.usage cpuacct.usage_percpu cpuacct.usage_percpu_user cpuacct.usage_user cpu.cfs_quota_us cpu.rt_runtime_us cpu.stat tasks
接下來我們就透過修改配置檔案對 CPU 進行限制，這裡就用前面建立的 container 這個“控制組”。
主要透過以下三個檔案來實現
- cpu.cfs_quota_us：每個控制週期內，程式可以使用的 cpu 時間，預設為 -1，即不做限制。
- cpu.cfs_period_us：控制週期，預設為 100 ms
- tasks：記錄被限制程式的 PID 列表
cgroups 會限制所有在 tasks 中的程式，在 cpu.cfs_period_us 週期內，最多隻能使用 cpu.cfs_quota_us 的 cpu 資源。
比如，100ms 能限制只能使用 20ms，即最多佔用 0.2 核心
首先，我們在後臺執行這樣一條指令碼:
[root@docker cpu]# while : ; do : ; done &
[1] 3892
顯然，它執行了一個死迴圈，可以把計算機的 CPU 吃到 100%。根據它的輸出，我們可以看到這個指令碼在後臺執行的程式號（PID）是 3892。
執行 Top 檢視一下 CPU 佔用，可以看到這個 3892 程式佔用了差不多 100% 的 CPU，把一個核心佔滿了。
[root@docker cpu]# top
top - 16:07:06 up 286 days, 4:31, 3 users, load average: 0.59, 0.50, 0.50
Tasks: 97 total, 2 running, 48 sleeping, 0 stopped, 0 zombie
%Cpu(s):100.0 us, 0.0 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 1006956 total, 166520 free, 190840 used, 649596 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 549216 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3892 root 20 0 115684 532 0 R 92.0 0.1 0:48.64 bash
此時，我們就可以透過配置 cgroups 來實現對該程式的 CPU 使用情況進行限制。
預設情況下 container 控制組裡的 CPU quota 還沒有任何限制（即：-1），CPU period 則是預設的 100 ms（100000 us），因此上述程式可以佔用整個 CPU。
[root@docker cpu]# cat /sys/fs/cgroup/cpu/container/cpu.cfs_quota_us
-1
[root@docker cpu]# cat /sys/fs/cgroup/cpu/container/cpu.cfs_period_us
100000
接下來，我們可以透過修改這配置檔案來設定 CPU 限制。比如，向 container 組裡的 cfs_quota 檔案寫入 20 ms（20000 us）來做限制。
[root@docker cpu]# echo 20000 > /sys/fs/cgroup/cpu/container/cpu.cfs_quota_us
[root@docker cpu]# cat /sys/fs/cgroup/cpu/container/cpu.cfs_quota_us
20000
最後則是將程式 PID 寫入 tasks 檔案裡，是配置生效。
[root@docker cpu]# echo 3892 > /sys/fs/cgroup/cpu/container/tasks
[root@docker cpu]# cat /sys/fs/cgroup/cpu/container/tasks
3892
然後檢視是否生效：
[root@docker cpu]# top
top - 16:13:56 up 286 days, 4:38, 3 users, load average: 0.20, 0.61, 0.59
Tasks: 94 total, 2 running, 48 sleeping, 0 stopped, 0 zombie
%Cpu(s): 21.6 us, 0.0 sy, 0.0 ni, 78.1 id, 0.0 wa, 0.0 hi, 0.0 si, 0.3 st
KiB Mem : 1006956 total, 166552 free, 190808 used, 649596 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 549248 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3892 root 20 0 115684 532 0 R 19.9 0.1 5:56.94 bash
可以看到，果然 3892 CPU 被限制到了 20%。
除 CPU 子系統外，Cgroups 的每一個子系統都有其獨有的資源限制能力，比如：
- blkio，為塊裝置設定I/O 限制，一般用於磁碟等裝置；
- cpuset，為程式分配單獨的 CPU 核和對應的記憶體節點；
- memory，為程式設定記憶體使用的限制。
Linux Cgroups 的設計還是比較易用的，簡單粗暴地理解呢，它就是一個子系統目錄加上一組資源限制檔案的組合。
而對於 Docker 等 Linux 容器專案來說，它們只需要在每個子系統下面，為每個容器建立一個控制組（即建立一個新目錄），然後在啟動容器程式之後，把這個程式的 PID 填寫到對應控制組的 tasks 檔案中就可以了。
而至於在這些控制組下面的資原始檔裡填上什麼值，就靠使用者執行 docker run 時的引數指定了，比如這樣一條命令：
docker run -it --cpu-period=100000 --cpu-quota=20000 ubuntu /bin/bash
在啟動這個容器後，我們可以透過檢視 Cgroups 檔案系統下，CPU 子系統中，“docker”這個控制組裡的資源限制檔案的內容來確認：
$ cat /sys/fs/cgroup/cpu/docker/5d5c9f67d/cpu.cfs_period_us
100000
$ cat /sys/fs/cgroup/cpu/docker/5d5c9f67d/cpu.cfs_quota_us
20000
3. 容器映象的秘密
這部分主要解釋以下三個問題
- 1）為什麼在容器中修改了檔案宿主機不受影響？
- 2）容器中的檔案系統是哪兒來的？
- 3）docker 映象又是怎麼實現的？
這也是 Docker 的第三個核心功能：容器映象（rootfs），將執行環境打包成映象，從而避免環境問題導致應用無法執行。
1. 檔案系統
容器中的檔案系統是什麼樣子的?
因為容器中的檔案系統經過 Mount Namespace 隔離，所以應該是獨立的。
其中 Mount Namespace 修改的，是容器程式對檔案系統“掛載點”的認知。只有在“掛載”這個操作發生之後，程式的檢視才會被改變。而在此之前，新建立的容器會直接繼承宿主機的各個掛載點。
不難想到，我們可以在容器程式啟動之前重新掛載它的整個根目錄“/”。而由於 Mount Namespace 的存在，這個掛載對宿主機不可見，所以容器程式就可以在裡面隨便折騰了。
Linux 中 chroot 命令（change root file system）就能很方便的完成上述工作。
而 Mount Namespace 正是基於對 chroot 的不斷改良才被發明出來的，它也是 Linux 作業系統裡的第一個 Namespace。
至此，第一個問題 為什麼在容器中修改了檔案宿主機不受影響？有答案了，因為使用 Mount Namespace 隔離了。
2. rootfs
上文提到 Mount Namespace 會修改容器程式對檔案系統掛載點的認知，而這個掛載在容器根目錄上、用來為容器程式提供隔離後執行環境的檔案系統，就是所謂的“容器映象”。它還有一個更為專業的名字，叫作：rootfs（根檔案系統）。
rootfs 只是一個作業系統所包含的檔案、配置和目錄，並不包括作業系統核心。在 Linux 作業系統中，這兩部分是分開存放的，作業系統只有在開機啟動時才會載入指定版本的核心映象。
所以說，rootfs 只包括了作業系統的“軀殼”，並沒有包括作業系統的“靈魂”。實際上，同一臺機器上的所有容器，都共享宿主機作業系統的核心。
這也是容器相比於虛擬機器的主要缺陷之一：畢竟後者不僅有模擬出來的硬體機器充當沙盒，而且每個沙盒裡還執行著一個完整的 Guest OS 給應用隨便折騰。
不過，正是由於 rootfs 的存在，容器才有了一個被反覆宣傳至今的重要特性：一致性。由於 rootfs 裡打包的不只是應用，而是整個作業系統的檔案和目錄，也就意味著，應用以及它執行所需要的所有依賴，都被封裝在了一起。
第二個問題：容器中的檔案系統是哪兒來的？實際上是我們構建映象的時候打包進去的，然後容器啟動時掛載到了根目錄下。
3. 映象層（Layer）
Docker 在映象的設計中，引入了層（layer）的概念。也就是說，使用者製作映象的每一步操作，都會生成一個層，也就是一個增量 rootfs。
透過引入層（layer）的概念，實現了 rootfs 的複用。不必每次都重新建立一個 rootfs，而是基於某一層進行修改即可。
Docker 映象層用到了一種叫做聯合檔案系統（Union File System）的能力。Union File System 也叫 UnionFS，最主要的功能是將多個不同位置的目錄聯合掛載（union mount）到同一個目錄下。
例如將目錄 A 和目錄 B 掛載到目錄 C 下面，這樣目錄 C 下就包含目錄 A 和目錄 B 的所有檔案。
由於看不到目錄 A 和 目標 B 的存在，因此就好像 C 目錄就包含這麼多檔案一樣
Docker 映象分為多個層，然後使用 UFS 將這多個層掛載到一個目錄下面，這樣這個目錄就包含了完整的檔案了。
UnionFS 在不同系統有各自的實現，所以 Docker 的不同發行版使用的也不一樣，可以透過 docker info 檢視。常見有 aufs（ubuntu 常用）、overlay2（centos 常用）
就像下圖這樣：union mount 在最上層，提供了統一的檢視，使用者看起來好像整個系統只有一層一樣，實際上下面包含了很多層。
映象只包含了靜態檔案，但是容器會產生實時資料，所以容器的 rootfs 在映象的基礎上增加了可讀寫層和 Init 層。
即容器 rootfs 包括：只讀層（映象rootfs）+ init 層（容器啟動時初始化修改的部分資料） + 可讀寫層（容器中產生的實時資料）。
只讀層（映象rootfs）
它是這個容器的 rootfs 最下面的幾層，即映象中的所有層的總和，它們的掛載方式都是隻讀的（ro+wh，即 readonly+whiteout）
可讀寫層（容器中產生的實時資料）
它是這個容器的 rootfs 最上面的一層，它的掛載方式為：rw，即 read write。在沒有寫入檔案之前，這個目錄是空的。
而一旦在容器裡做了寫操作，你修改產生的內容就會以增量的方式出現在這個層中，刪除操作實現比較特殊（類似於標記刪除）。
AUFS 的 whiteout 的實現是透過在上層的可寫的目錄下建立對應的 whiteout 隱藏檔案來實現的。
為了實現刪除操作，aufs（UnionFS 的一種實現） 會在可讀寫層建立一個 whiteout 檔案，把只讀層裡的檔案“遮擋”起來。
比如，你要刪除只讀層裡一個名叫 foo 的檔案，那麼這個刪除操作實際上是在可讀寫層建立了一個名叫.wh.foo 的檔案。這樣，當這兩個層被聯合掛載之後，foo 檔案就會被.wh.foo 檔案“遮擋”起來，“消失”了。
init 層（容器啟動時初始化修改的部分資料）
它是一個以“-init”結尾的層，夾在只讀層和讀寫層之間，Init 層是 Docker 專案單獨生成的一個內部層，專門用來存放 /etc/hosts、/etc/resolv.conf 等資訊。
為什麼需要 init 層？
比如 hostname 這樣的資料，原本是屬於映象層的一部分，要修改的話只能在可讀寫層進行修改，但是又不想在 docker commit 的時候把這些資訊提交上去，所以使用 init 層來儲存這些修改。
可以理解為提交程式碼的時候一般也不會把各種配置資訊一起提交上去。
docker commit 只會提交 只讀層和可讀寫層。
最後一個問題：docker 映象又是怎麼實現的？透過引入 layer 概念進行分層，藉助 聯合檔案系統（Union File System）進行疊加，最終構成了完整的映象。
這裡只是映象的主要內容，具體怎麼把這些內容打包成 image 格式就是 OCI 規範了
4. 小結
至此，我們大致清楚了 Docker 容器的實現主要使用瞭如下 3 個功能：
- 1）Linux Namespace 的隔離能力
- 2）Linux Cgroups 的限制能力
- 3）基於 rootfs 的檔案系統
如果你對雲原生技術充滿好奇，想要深入瞭解更多相關的文章和資訊，歡迎關注微信公眾號。
搜尋公眾號【探索雲原生】即可訂閱
5. 參考
https://draveness.me/docker/
https://en.wikipedia.org/wiki/Linux_namespaces
https://0xax.gitbooks.io/linux-insides/content/Cgroups/linux-cgroups-1.html
https://coolshell.cn/articles/17061.html
深入剖析Kubernetes