系列文章目錄
【云原生-深入理解Kubernetes-1】容器的本質(zhì)是進(jìn)程
【云原生-深入理解Kubernetes-2】容器 Linux Cgroups 限制
?? 關(guān)于作者
大家好，我是秋意零。
?? CSDN作者主頁
- ?? 博客主頁
?? 簡介
- ?? 普通本科生在讀
- 在校期間參與眾多計算機(jī)相關(guān)比賽，如：?? “省賽”、“國賽”，斬獲多項(xiàng)獎項(xiàng)榮譽(yù)證書
- ?? 各個平臺，秋意零 賬號創(chuàng)作者
- ?? 云社區(qū) 創(chuàng)建者
點(diǎn)贊、收藏+關(guān)注下次不迷路！
歡迎加入云社區(qū)
一、回顧
上一章我們了解了 Linux Cgroups 限制，容器是如何使用這個 Linux Cgroups 來達(dá)到限制這個容器進(jìn)程的。
二、容器進(jìn)程的文件系統(tǒng)是什么樣子的？
容器中 Namespace 的作用時 “隔離”，讓容器進(jìn)程只能看到自己這片小空間；Linux Cgroups 的作用時 “限制”，它給這片小空間修筑了一圈的圍墻。這樣進(jìn)程就被放在了一個與世隔絕的房間里。這時候我們有了房間，房間有了墻，那我們房間的地基是什么呢？
- 說白了就是，容器進(jìn)程的文件系統(tǒng)是什么樣子的？
1、可能你立刻就能想到，這一定是一個關(guān)于
Mount Namespace的問題：容器里的應(yīng)用進(jìn)程，理應(yīng)看到一份完全獨(dú)立的文件系統(tǒng)。這樣，它就可以在自己的容器目錄（比如 /tmp）下進(jìn)行操作，而完全不會受宿主機(jī)以及其他容器的影響。
2、即使開啟了Mount Namespace，容器進(jìn)程看到的文件系統(tǒng)也跟宿主機(jī)完全一樣。
- Mount Namespace 修改的，是容器進(jìn)程對文件系統(tǒng)“掛載點(diǎn)”的認(rèn)知。
- 所以只有“掛載”這個操作之后，就是執(zhí)行
mount 命令之后，進(jìn)程的視圖才能被修改。在掛載之前，新創(chuàng)建的容器會直接繼承宿主機(jī)的各個掛載點(diǎn)。
Mount Namespace 跟其他 Namespace 的使用略有不同的地方：它對容器進(jìn)程視圖的改變，一定是伴隨著掛載操作（mount）才能生效。
rootfs
為了使容器有一個自己獨(dú)立的文件系統(tǒng)，我們可以在容器進(jìn)程啟動之前重新掛載它的根目錄 “/”，由于 Mount Namespace 存在，這個掛載對宿主機(jī)是不可見的，容器進(jìn)程可以在這個文件系統(tǒng)中隨心所欲。
Linux 系統(tǒng)中，可以使用有一個名為
chroot 命令來完成上訴的操作。chroot 命令是 “change root directory” 的縮寫，chroot 是一個系統(tǒng)調(diào)用，可以更改一個進(jìn)程所能看到的根目錄。
chroot 命令語法：
chroot [OPTION] NEWROOT [COMMAND [ARG]...]
如果沒有給出任何命令，默認(rèn)：/bin/sh -i）。
這個掛載在容器根目錄上、用來為容器進(jìn)程提供文件系統(tǒng)，就是所謂的“容器鏡像”。它還有一個更為專業(yè)的名字，叫作：rootfs（根文件系統(tǒng)）。
一個最常見的 rootfs，或者說容器鏡像，會包括如下目錄和文件，比如 /bin，/etc，/proc 等，而你進(jìn)入容器之后執(zhí)行的
/bin/bash，就是/bin目錄下的可執(zhí)行文件，與宿主機(jī)的/bin/bash完全不同。
$ ls /
bin boot dev etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var
現(xiàn)在來看，容器最核心的原理就是為 “待” 創(chuàng)建的容器進(jìn)程，執(zhí)行下列三個步驟：
- 1.啟用 Linux Namespace；
- 2.設(shè)置 Cgroups ；
- 3.切換進(jìn)程的根目錄（chroot）；
這樣，一個完整的容器就誕生了。
一致性
rootfs 只是一個操作系統(tǒng)所包含的文件、配置和目錄，并不包括操作系統(tǒng)內(nèi)核。在 Linux 操作系統(tǒng)中，這兩部分（操作系統(tǒng)、文件目錄）是分開存放的，操作系統(tǒng)只有在開機(jī)啟動時才會加載指定版本的內(nèi)核鏡像。這也說明了 rootfs 只有操作系統(tǒng)的 “身體”，沒有操作系統(tǒng)的 “靈魂”。
rootfs 文件系統(tǒng)有一個重要特性：一致性
由于 rootfs 里打包的不只是應(yīng)用，而是整個操作系統(tǒng)的文件和目錄，也就意味著，應(yīng)用以及它運(yùn)行所需要的所有依賴，都被封裝在了一起。
解決應(yīng)用依賴關(guān)系
對于一個應(yīng)用來說，操作系統(tǒng)本身才是它運(yùn)行所需要的最完整的“依賴庫”。
有了容器鏡像 （rootfs）“打包操作系統(tǒng)的身體” 的能力，這個最基礎(chǔ)的依賴環(huán)境也變成了應(yīng)用沙盒的一部分，這也賦予了容器所謂的一致性： 無論是在本地、云端或者還是任何一個地方的機(jī)器上，用戶只要解壓打包好的容器鏡像，那么這個應(yīng)用運(yùn)行所需要的完整的執(zhí)行環(huán)境就被重現(xiàn)出來了。
這種深入到操作系統(tǒng)級別的運(yùn)行環(huán)境一致性，打通了應(yīng)用在本地開發(fā)和遠(yuǎn)端執(zhí)行環(huán)境之間難以逾越的鴻溝。
解決復(fù)用性
這時出現(xiàn)了一個棘手的問題： 難道每次開發(fā)一個應(yīng)用，或升級現(xiàn)有的應(yīng)用，都要重復(fù)制作一次 rootfs 嗎？
比如，我現(xiàn)在用 Centos 操作系統(tǒng)的 ISO 做了一個 rootfs，然后又在里面安裝了 Java 環(huán)境，用來部署我的 Java 應(yīng)用。那么，我的另一個同事在發(fā)布他的 Java 應(yīng)用時，希望能夠直接使用我安裝過 Java 環(huán)境的 rootfs，而不是重復(fù)這個流程。
-
一種比較直觀的解決辦法是，我在制作 rootfs 的時候，每做一步“有意義”的操作，就保存一個 rootfs 出來， 這樣其他同事就可以按需求去用他需要的 rootfs 了。
-
但是，這個解決辦法并不具備推廣性。原因在于，一旦你的同事們修改了這個 rootfs，新舊兩個 rootfs 之間就沒有任何關(guān)系了。這樣做的結(jié)果就是極度的碎片化。
-
那么，既然這些修改都基于一個舊的 rootfs，我們能不能以增量的方式去做這些修改呢？ 答案當(dāng)然是肯定的。這樣做的好處是，所有人都只需要維護(hù)相對于 base rootfs （基礎(chǔ) rootfs）修改的增量內(nèi)容， 而不是每次修改都制造一個“fork”（分支）。
三、OverlayFS 聯(lián)合文件系統(tǒng)
Docker 鏡像，引入了層（layer）的概念。用戶制作鏡像的每一步操作，都會生成一個層，也就是一個增量 rootfs。這個操作使用的是：聯(lián)合文件系統(tǒng)（OverlayFS ），也叫 overlay2。
OverlayFS 是一個現(xiàn)代聯(lián)合文件系統(tǒng)。將 Linux 內(nèi)核驅(qū)動程序稱為 OverlayFS，將 Docker 存儲驅(qū)動程序稱為 overlay2。
OverlayFS 最主要的功能是將多個不同位置的目錄聯(lián)合掛載（union mount）到同一個目錄下。
比如，我現(xiàn)在有兩個目錄 A 和 B，A 目錄下的文件 a、b、c ，B 目錄下的文件 c、d、e：
$ tree A A ├── a ├── b └── c $ tree B B ├── c ├── d └── e
- 然后，我使用聯(lián)合掛載的方式，將這兩個目錄掛載到一個公共的目錄 C 上
- 這時，我再查看目錄 C 的內(nèi)容，就能看到目錄 A 和 B 下的文件被合并到了一起?？梢钥吹?，C 目錄里，有 a、b、c、d、e 五個文件，并且 c 文件只要一份，這就是合并的含義。如果你在 C 目錄對 a、b、c、d、e 文件修改，這個修改會對應(yīng)到 A、B 目錄當(dāng)中生效。
$ tree C C ├── a ├── b └── c ├── d └── e
先決條件
OverlayFS 是推薦的存儲驅(qū)動程序，滿足以下先決條件，則支持：
- 4.0 或更高版本的 Linux 內(nèi)核，或使用 3.10.0-514 或更高版本內(nèi)核的 RHEL 或 CentOS。
- 該 overlay2 驅(qū)動程序在后備文件系統(tǒng)上受支持 xfs，但僅在 d_type=true 啟用的情況下。用于 xfs_info 驗(yàn)證該 ftype 選項(xiàng)是否設(shè)置為 1。要正確格式化 xfs 文件系統(tǒng)，請使用標(biāo)志 -n ftype=1.
- 更改存儲驅(qū)動程序會使本地系統(tǒng)上的現(xiàn)有容器和圖像無法訪問。
docker save在更改存儲驅(qū)動程序之前保存鏡像。
docker info 查看存儲驅(qū)動信息：
$ docker info
...
...
Storage Driver: overlay2
Backing Filesystem: xfs
Supports d_type: true
Using metacopy: false
Native Overlay Diff: true
userxattr: false
...
...
Docker 使用 overlary2 存儲驅(qū)動程序，會自動創(chuàng)建 lowerdir、upperdir、merged 和 workdir覆蓋掛載結(jié)構(gòu)體。
OverlayFS 在單個 Linux 主機(jī)上將兩個目錄分層，并將它們呈現(xiàn)為單個目錄，這些目錄稱為層（layer），兩個目錄統(tǒng)一為一個目錄的過程稱為聯(lián)合掛載（詳細(xì)過程看上面 兩個目錄 A 和 B 的例子）。
- OverlayFS 將下層目錄稱為：lowerdir
- OverlayFS 將上層目錄稱為：upperdir
- 統(tǒng)一視圖通過其 merged 目錄展現(xiàn)出來（上層和下層目錄的聯(lián)合掛載內(nèi)容展現(xiàn)）
overlay2 驅(qū)動程序如何工作
結(jié)構(gòu)圖
下圖顯示了 Docker 鏡像和 Docker 容器是如何分層的：
- lowerdir 是鏡像層
- upperdir 是容器層
如果鏡像有多層，lowerdir 則使用多個目錄。統(tǒng)一視圖通過名為 merged 的目錄公開，該目錄實(shí)際上是容器安裝位置。該圖顯示了 Docker 如何構(gòu)造映射到 OverlayFS 構(gòu)造。
- 在鏡像層和容器層包含相同文件的情況下，容器層掩蓋了鏡像層中相同文件的存在。
- 為了創(chuàng)建容器，overlay2 驅(qū)動程序?qū)⒋礴R像頂層的目錄與容器的新目錄組合在一起。鏡像的圖層位于 lowerdirs 疊加層中并且是只讀的。容器的新目錄是 upperdir 并且是可寫的。
探索含義-磁盤上的鏡像層和容器層
鏡像層
使用 docker pull nginx 命令拉取下載鏡像后，可以看到 nginx 鏡像有 6 層 Docker 映像，對應(yīng)到磁盤上是在 /var/lib/docker/overlay2 目錄下。
注意：
/var/lib/docker/目錄是 Docker 的根目錄，由 Docker 管理，不要操作其中的文件和目錄。
$ docker pull nginx
Using default tag: latest
latest: Pulling from library/nginx
9e3ea8720c6d: Pull complete
bf36b6466679: Pull complete
15a97cf85bb8: Pull complete
9c2d6be5a61d: Pull complete
6b7e4a5c7c7a: Pull complete
8db4caa19df8: Pull complete
Digest: sha256:480868e8c8c797794257e2abd88d0f9a8809b2fe956cbfbc05dcc0bca1f7cd43
Status: Downloaded newer image for nginx:latest
docker.io/library/nginx:latest
可以使用 docker image inspect 命令查看鏡像的分層以及結(jié)構(gòu)體
可以看到 overlay2 目錄下自動創(chuàng)建了 6 個目錄。鏡像層 ID 與目錄 ID 不對應(yīng)。
目錄 l （小寫的 L），包含作為符號鏈接的縮短層標(biāo)識符。這些標(biāo)識符用于避免達(dá)到命令參數(shù)的字符長度限制（比如 mount）
鏡像層最底層包含一個名為 diff 的目錄，包含該鏡像層（lowerdir）的內(nèi)容；以及一個名為 link 的文件，其中包含該 image 層（layer）縮短標(biāo)識符的名稱。
[root@test_2 overlay2]# cd /var/lib/docker/overlay2/
[root@test_2 overlay2]# ls 228b2f89b5e4316b9b613fc6233551a96e64f51e827972caf86acb82338c7fdb/
committed diff link
[root@test_2 overlay2]# ls 228b2f89b5e4316b9b613fc6233551a96e64f51e827972caf86acb82338c7fdb/diff/
bin boot dev etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var
[root@test_2 overlay2]# cat 228b2f89b5e4316b9b613fc6233551a96e64f51e827972caf86acb82338c7fdb/link
2L2KGYQSG5H43HK6LRJOT7TU4J
鏡像層第二低層和每個更高層包含一個名為 lower 的文件（里面記錄了鏡像層每層的縮短標(biāo)識符的名稱）；一個名為 diff 的目錄（其中包含其內(nèi)容）；還包含一個 merged 目錄（其中包含其父層和自身的統(tǒng)一內(nèi)容）；以及一個 work 目錄 （OverlayFS 內(nèi)部使用的目錄）；最后一個 link 文件，其中包含該 image 層（layer）縮短標(biāo)識符的名稱。
$ ls /var/lib/docker/overlay2/5605b29d1d7269f11acb3653a8032299b58ca7d111e43dd215fab660851b114c/
committed diff link lower work
$ ll /var/lib/docker/overlay2/5605b29d1d7269f11acb3653a8032299b58ca7d111e43dd215fab660851b114c/diff
total 0
drwxr-xr-x 2 root root 41 May 4 03:51 docker-entrypoint.d
# 記錄了鏡像層每層的縮短標(biāo)識符的名稱
$ cat /var/lib/docker/overlay2/5605b29d1d7269f11acb3653a8032299b58ca7d111e43dd215fab660851b114c/lower
l/NR7U3COVTPVL3XSBKQ77AYXAMR:l/656UDNBIOMRQG4UU6VGTOPQVMT:l/BJ6JTE7P4WDJROD7M6R56HDZ7G:l/DIKKGXFOP6YWKBZL5SRAQLG3SR:l/2L2KGYQSG5H43HK6LRJOT7TU4J
# 驗(yàn)證 lower 文件內(nèi)容
$ ll /var/lib/docker/overlay2/l/
total 0
lrwxrwxrwx 1 root root 72 May 23 14:44 2L2KGYQSG5H43HK6LRJOT7TU4J -> ../228b2f89b5e4316b9b613fc6233551a96e64f51e827972caf86acb82338c7fdb/diff
lrwxrwxrwx 1 root root 72 May 23 14:44 656UDNBIOMRQG4UU6VGTOPQVMT -> ../7d85f043da224ace0401e97516cf9b8c63cfac6e9804d5f47b3d0f2fda2e9c11/diff
lrwxrwxrwx 1 root root 72 May 23 14:44 BJ6JTE7P4WDJROD7M6R56HDZ7G -> ../2fd591e59cfa565d2377d074224fb823f09917015b9ce3f46d1285f958dfb7fe/diff
lrwxrwxrwx 1 root root 72 May 23 14:44 DIKKGXFOP6YWKBZL5SRAQLG3SR -> ../b1c6e8fcd75408f47820cab5e2bac117275d23deae5723489a4a6549fced8d45/diff
lrwxrwxrwx 1 root root 72 May 23 14:44 MFPTI6FPG5SCBEN4Q7NFQLO2YO -> ../5605b29d1d7269f11acb3653a8032299b58ca7d111e43dd215fab660851b114c/diff
lrwxrwxrwx 1 root root 72 May 23 14:44 NR7U3COVTPVL3XSBKQ77AYXAMR -> ../eedf9b88406b4323a634400b593c74be86c9e774ea7df8191c9f395a59f00c3d/diff
容器層
容器層也存在于 Docker 主機(jī)文件系統(tǒng)的磁盤上，位于 /var/lib/docker/overlay/
[root@test_2 ~]# docker run -idt --name nginx nginx
3345e0df177c94d0f16dfb82918d139937c1e2e3acfc8f1514844f77752cf74d
[root@test_2 ~]#
[root@test_2 ~]# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
3345e0df177c nginx "/docker-entrypoint.…" 13 seconds ago Up 12 seconds 80/tcp nginx
使用 docker container inspect 命令查看容器層：
可以看到 container 的鏡像層（LowerDir）和 image 的鏡像層（LowerDir）下面 5 層（layer）一致的，說明這是基于我們拉取下載下來的 nginx 鏡像創(chuàng)建的容器。
查看運(yùn)行容器的目錄：
- diff 目錄：包含容器層（UpperDir）內(nèi)容
- link 文件： 其中包含該 image 層（layer）縮短標(biāo)識符的名稱。
- lower 文件： 記錄了鏡像層和容器層每層的縮短標(biāo)識符的名稱
- merged 目錄： lowerdir 和 upperdir 目錄的聯(lián)合掛載體現(xiàn)，它包含來自正在運(yùn)行的容器內(nèi)的文件系統(tǒng)的視圖。
- work 目錄： 容器工作目錄
$ ll /var/lib/docker/overlay2/b8925e85fdaa4abff5cfd7f988e2fa08da349b8b983b864b0686b19c0e825d09/
total 8
drwxr-xr-x 5 root root 39 May 23 16:49 diff
-rw-r--r-- 1 root root 26 May 23 16:49 link
-rw-r--r-- 1 root root 202 May 23 16:49 lower
drwxr-xr-x 1 root root 39 May 23 16:49 merged
drwx------ 3 root root 18 May 23 16:49 work
$ ls /var/lib/docker/overlay2/b8925e85fdaa4abff5cfd7f988e2fa08da349b8b983b864b0686b19c0e825d09/diff/
etc run var
$ cat /var/lib/docker/overlay2/b8925e85fdaa4abff5cfd7f988e2fa08da349b8b983b864b0686b19c0e825d09/link
WOTO7SJMAF42QFMCPIARE7RE46
$ cat /var/lib/docker/overlay2/b8925e85fdaa4abff5cfd7f988e2fa08da349b8b983b864b0686b19c0e825d09/lower
l/ZFU53D2JEDP4EM5HRKMZ6TID3R:l/MFPTI6FPG5SCBEN4Q7NFQLO2YO:l/NR7U3COVTPVL3XSBKQ77AYXAMR:l/656UDNBIOMRQG4UU6VGTOPQVMT:l/BJ6JTE7P4WDJROD7M6R56HDZ7G:l/DIKKGXFOP6YWKBZL5SRAQLG3SR:l/2L2KGYQSG5H43HK6LRJOT7TU4J
$ ls /var/lib/docker/overlay2/b8925e85fdaa4abff5cfd7f988e2fa08da349b8b983b864b0686b19c0e825d09/merged
bin boot dev docker-entrypoint.d docker-entrypoint.sh etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var
$ ll /var/lib/docker/overlay2/b8925e85fdaa4abff5cfd7f988e2fa08da349b8b983b864b0686b19c0e825d09/work/
total 0
d--------- 2 root root 6 May 24 10:42 work
使用 mount 命令 ，查看將存儲驅(qū)動程序與 Docker 一起使用時存在的掛載 overlay（容器運(yùn)行時才會看到掛載 merged 目錄）。括號開頭內(nèi)容： rw ，表示掛載是可讀寫的。
可以看到 overlay 聯(lián)合掛載的目錄是 :
/var/lib/docker/overlay2/b8925e85fdaa4abff5cfd7f988e2fa08da349b8b983b864b0686b19c0e825d09/merged，說明了這就是容器的根文件系統(tǒng)（rootfs），并且這是由 lowerdir 、upperdir、workdir 三個目錄聯(lián)合掛載起來的，同時這里 mount 使用了每層的縮短標(biāo)識符的名稱，避免達(dá)到命令參數(shù)的字符長度限制。
四、overlay2 容器讀寫如何工作
還是把上面的結(jié)構(gòu)圖拿過來
只讀層
通過上面的講述，大概也已經(jīng)了解了，只讀層是我們鏡像層（lowerdir）。
讀取文件
考慮三種情況，其中文件在鏡像層和容器層同時存在使用覆蓋進(jìn)行讀取訪問。
- 文件在容器層中不存在： 如果容器打開一個文件進(jìn)行讀取訪問，而這個文件在容器中（upperdir）不存在，則從鏡像中（lowerdir）讀取。這會產(chǎn)生非常小的性能開銷。
- 文件存在容器層中： 如果容器打開一個文件進(jìn)行讀取訪問，而這個文件在容器中（upperdir）存在，那么就直接讀取，不在鏡像中（lowerdir）讀取。
- 文件同時存在于鏡像層和容器層： 如果容器打開一個文件進(jìn)行讀取訪問，而這個文件同時在鏡像層和容器層存在，容器層 ( upperdir) 中的文件掩蓋鏡像層 (lowerdir) 中同名的文件，則讀取容器層中的版本。
可讀寫層
可讀寫層是我們?nèi)萜鲗樱╱pperdir）。
修改文件和目錄
-
1.第一次寫入文件： 容器第一次寫入文件時，容器中 (upperdir) 不存在該文件。驅(qū)動程序 overlay2 執(zhí)行 copy_up 操作將文件從鏡像層 ( lowerdir) 復(fù)制到容器層 ( upperdir)。
OverlayFS 工作在文件級別而不是塊級別。這意味著所有 OverlayFS copy_up 操作都會復(fù)制整個文件，即使文件非常大并且只修改了一小部分。這會對容器寫入性能產(chǎn)生顯著影響。- copy_up 操作僅在第一次寫入給定文件時發(fā)生。對同一文件的后續(xù)寫入將針對已復(fù)制到容器的文件副本進(jìn)行操作。
- OverlayFS 適用于多層。這意味著在具有多層的圖像中搜索文件時，性能可能會受到影響。
-
2.刪除文件和目錄：
- 容器中刪除文件: 刪除鏡像層中的文件，會在容器中 (upperdir) 創(chuàng)建一個 whiteout 文件，鏡像層（lowerdir ）中的文件版本沒有被刪除（因?yàn)槭?lowerdir 只讀的）。但是 whiteout 文件阻止鏡像層對容器層可用。
- 容器中刪除目錄： 會在容器中 ( upperdir ) 創(chuàng)建一個不透明的目錄。這與 whiteout 文件的工作方式相同，并有效地防止目錄被訪問，即使它仍然存在于鏡像中 ( lowerdir)。這樣一看在容器中目錄就被刪除了。
PS：whiteout 文件是什么？
- 比如我要刪除只讀層中（lowerdir 鏡像層）的文件，那么這個刪除操作實(shí)際上是在可讀寫層創(chuàng)建了一個名叫.wh.foo 的文件。這樣，當(dāng)這兩個層被聯(lián)合掛載之后，foo 文件就會被.wh.foo 文件“遮擋”起來，“消失”了。這個功能，就是“ro+wh”的掛載方式，即只讀 +whiteout 的含義。可以形象地把 whiteout 翻譯為：“白障”。
- 3.重命名目錄： 調(diào)用 rename(2) 操作重命名目錄，僅在源路徑和目標(biāo)路徑都在頂層時才允許調(diào)用。否則，返回 EXDEV 錯誤（“不允許跨設(shè)備鏈接”）。您的應(yīng)用程序需要設(shè)計為處理EXDEV 并回退到“復(fù)制和取消鏈接”策略。
總結(jié)
這里，介紹了 Linux 容器進(jìn)程文件系統(tǒng)的實(shí)現(xiàn)方式，而這種機(jī)制，正是我們經(jīng)常提到的容器鏡像，也叫作：rootfs。它只是一個操作系統(tǒng)的所有文件和目錄，并不包含內(nèi)核，所以對比虛擬機(jī)的鏡像要小的多。
通過結(jié)合使用 Mount Namespace 和 rootfs，容器就能夠?yàn)檫M(jìn)程構(gòu)建出一個完善的文件系統(tǒng)隔離環(huán)境。這需要依賴 chroot 和 pivot_root 切換進(jìn)程根目錄的能力。
在 rootfs 根文件系統(tǒng)的基礎(chǔ)上，Docker 使用了一個 overlay2 聯(lián)合文件掛載。并提出了容器鏡像中“層”（layer）的概念。
? 最后
?? 我是秋意零，歡迎大家一鍵三連、加入云社區(qū)
?? 我們下期再見(⊙o⊙)?。?！文章來源：http://www.zghlxwxcb.cn/news/detail-494162.html
參考
參考《深入剖析Kubernetes》作者 張磊
https://docs.docker.com/storage/storagedriver/overlayfs-driver/文章來源地址http://www.zghlxwxcb.cn/news/detail-494162.html
到了這里，關(guān)于【探索 Kubernetes|容器基礎(chǔ)進(jìn)階篇 系列 3】容器進(jìn)程的文件系統(tǒng)的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
