系列文章目錄

【云原生-深入理解Kubernetes-1】容器的本質(zhì)是進(jìn)程
【云原生-深入理解Kubernetes-2】容器 Linux Cgroups 限制

?? 關(guān)于作者

大家好，我是秋意零。

?? CSDN作者主頁(yè)

• ?? 博客主頁(yè)

?? 簡(jiǎn)介

• ?? 普通本科生在讀
• 在校期間參與眾多計(jì)算機(jī)相關(guān)比賽，如：?? “省賽”、“國(guó)賽”，斬獲多項(xiàng)獎(jiǎng)項(xiàng)榮譽(yù)證書(shū)
• ?? 各個(gè)平臺(tái)，秋意零 賬號(hào)創(chuàng)作者
• ?? 云社區(qū) 創(chuàng)建者

點(diǎn)贊、收藏+關(guān)注下次不迷路！

歡迎加入云社區(qū)

一、回顧

上一章我們了解了 Linux Cgroups 限制，容器是如何使用這個(gè) Linux Cgroups 來(lái)達(dá)到限制這個(gè)容器進(jìn)程的。

二、容器進(jìn)程的文件系統(tǒng)是什么樣子的？

容器中 Namespace 的作用時(shí) “隔離”，讓容器進(jìn)程只能看到自己這片小空間；Linux Cgroups 的作用時(shí) “限制”，它給這片小空間修筑了一圈的圍墻。這樣進(jìn)程就被放在了一個(gè)與世隔絕的房間里。這時(shí)候我們有了房間，房間有了墻，那我們房間的地基是什么呢？

• 說(shuō)白了就是，容器進(jìn)程的文件系統(tǒng)是什么樣子的？

1、可能你立刻就能想到，這一定是一個(gè)關(guān)于 Mount Namespace 的問(wèn)題：容器里的應(yīng)用進(jìn)程，理應(yīng)看到一份完全獨(dú)立的文件系統(tǒng)。這樣，它就可以在自己的容器目錄（比如 /tmp）下進(jìn)行操作，而完全不會(huì)受宿主機(jī)以及其他容器的影響。
2、即使開(kāi)啟了 Mount Namespace ，容器進(jìn)程看到的文件系統(tǒng)也跟宿主機(jī)完全一樣。

• Mount Namespace 修改的，是容器進(jìn)程對(duì)文件系統(tǒng)“掛載點(diǎn)”的認(rèn)知。
• 所以只有“掛載”這個(gè)操作之后，就是執(zhí)行 mount 命令之后，進(jìn)程的視圖才能被修改。在掛載之前，新創(chuàng)建的容器會(huì)直接繼承宿主機(jī)的各個(gè)掛載點(diǎn)。

Mount Namespace 跟其他 Namespace 的使用略有不同的地方：它對(duì)容器進(jìn)程視圖的改變，一定是伴隨著掛載操作（mount）才能生效。

rootfs

為了使容器有一個(gè)自己獨(dú)立的文件系統(tǒng)，我們可以在容器進(jìn)程啟動(dòng)之前重新掛載它的根目錄 “/”，由于 Mount Namespace 存在，這個(gè)掛載對(duì)宿主機(jī)是不可見(jiàn)的，容器進(jìn)程可以在這個(gè)文件系統(tǒng)中隨心所欲。

Linux 系統(tǒng)中，可以使用有一個(gè)名為 chroot 命令來(lái)完成上訴的操作。chroot 命令是 “change root directory” 的縮寫(xiě)，chroot 是一個(gè)系統(tǒng)調(diào)用，可以更改一個(gè)進(jìn)程所能看到的根目錄。

chroot 命令語(yǔ)法：

chroot [OPTION] NEWROOT [COMMAND [ARG]...]
如果沒(méi)有給出任何命令，默認(rèn)：/bin/sh -i）。

這個(gè)掛載在容器根目錄上、用來(lái)為容器進(jìn)程提供文件系統(tǒng)，就是所謂的“容器鏡像”。它還有一個(gè)更為專業(yè)的名字，叫作：rootfs（根文件系統(tǒng)）。

一個(gè)最常見(jiàn)的 rootfs，或者說(shuō)容器鏡像，會(huì)包括如下目錄和文件，比如 /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)在來(lái)看，容器最核心的原理就是為 “待” 創(chuàng)建的容器進(jìn)程，執(zhí)行下列三個(gè)步驟：

• 1.啟用 Linux Namespace；
• 2.設(shè)置 Cgroups ；
• 3.切換進(jìn)程的根目錄（chroot）；

這樣，一個(gè)完整的容器就誕生了。

一致性

rootfs 只是一個(gè)操作系統(tǒng)所包含的文件、配置和目錄，并不包括操作系統(tǒng)內(nèi)核。在 Linux 操作系統(tǒng)中，這兩部分（操作系統(tǒng)、文件目錄）是分開(kāi)存放的，操作系統(tǒng)只有在開(kāi)機(jī)啟動(dòng)時(shí)才會(huì)加載指定版本的內(nèi)核鏡像。這也說(shuō)明了 rootfs 只有操作系統(tǒng)的 “身體”，沒(méi)有操作系統(tǒng)的 “靈魂”。

rootfs 文件系統(tǒng)有一個(gè)重要特性：一致性

由于 rootfs 里打包的不只是應(yīng)用，而是整個(gè)操作系統(tǒng)的文件和目錄，也就意味著，應(yīng)用以及它運(yùn)行所需要的所有依賴，都被封裝在了一起。

解決應(yīng)用依賴關(guān)系

對(duì)于一個(gè)應(yīng)用來(lái)說(shuō)，操作系統(tǒng)本身才是它運(yùn)行所需要的最完整的“依賴庫(kù)”。
有了容器鏡像 （rootfs）“打包操作系統(tǒng)的身體” 的能力，這個(gè)最基礎(chǔ)的依賴環(huán)境也變成了應(yīng)用沙盒的一部分，這也賦予了容器所謂的一致性： 無(wú)論是在本地、云端或者還是任何一個(gè)地方的機(jī)器上，用戶只要解壓打包好的容器鏡像，那么這個(gè)應(yīng)用運(yùn)行所需要的完整的執(zhí)行環(huán)境就被重現(xiàn)出來(lái)了。

這種深入到操作系統(tǒng)級(jí)別的運(yùn)行環(huán)境一致性，打通了應(yīng)用在本地開(kāi)發(fā)和遠(yuǎn)端執(zhí)行環(huán)境之間難以逾越的鴻溝。

解決復(fù)用性

這時(shí)出現(xiàn)了一個(gè)棘手的問(wèn)題： 難道每次開(kāi)發(fā)一個(gè)應(yīng)用，或升級(jí)現(xiàn)有的應(yīng)用，都要重復(fù)制作一次 rootfs 嗎？

比如，我現(xiàn)在用 Centos 操作系統(tǒng)的 ISO 做了一個(gè) rootfs，然后又在里面安裝了 Java 環(huán)境，用來(lái)部署我的 Java 應(yīng)用。那么，我的另一個(gè)同事在發(fā)布他的 Java 應(yīng)用時(shí)，希望能夠直接使用我安裝過(guò) Java 環(huán)境的 rootfs，而不是重復(fù)這個(gè)流程。

• 一種比較直觀的解決辦法是，我在制作 rootfs 的時(shí)候，每做一步“有意義”的操作，就保存一個(gè) rootfs 出來(lái)， 這樣其他同事就可以按需求去用他需要的 rootfs 了。

• 但是，這個(gè)解決辦法并不具備推廣性。原因在于，一旦你的同事們修改了這個(gè) rootfs，新舊兩個(gè) rootfs 之間就沒(méi)有任何關(guān)系了。這樣做的結(jié)果就是極度的碎片化。

• 那么，既然這些修改都基于一個(gè)舊的 rootfs，我們能不能以增量的方式去做這些修改呢？ 答案當(dāng)然是肯定的。這樣做的好處是，所有人都只需要維護(hù)相對(duì)于 base rootfs （基礎(chǔ) rootfs）修改的增量?jī)?nèi)容， 而不是每次修改都制造一個(gè)“fork”（分支）。

三、OverlayFS 聯(lián)合文件系統(tǒng)

Docker 鏡像，引入了層（layer）的概念。用戶制作鏡像的每一步操作，都會(huì)生成一個(gè)層，也就是一個(gè)增量 rootfs。這個(gè)操作使用的是：聯(lián)合文件系統(tǒng)（OverlayFS ），也叫 overlay2。

OverlayFS 是一個(gè)現(xiàn)代聯(lián)合文件系統(tǒng)。將 Linux 內(nèi)核驅(qū)動(dòng)程序稱為 OverlayFS，將 Docker 存儲(chǔ)驅(qū)動(dòng)程序稱為 overlay2。

OverlayFS 最主要的功能是將多個(gè)不同位置的目錄聯(lián)合掛載（union mount）到同一個(gè)目錄下。

比如，我現(xiàn)在有兩個(gè)目錄 A 和 B，A 目錄下的文件 a、b、c ，B 目錄下的文件 c、d、e：

$ tree A
A
├── a
├── b
└── c
$ tree B
B
├── c
├── d
└── e

• 然后，我使用聯(lián)合掛載的方式，將這兩個(gè)目錄掛載到一個(gè)公共的目錄 C 上
• 這時(shí)，我再查看目錄 C 的內(nèi)容，就能看到目錄 A 和 B 下的文件被合并到了一起?？梢钥吹?，C 目錄里，有 a、b、c、d、e 五個(gè)文件，并且 c 文件只要一份，這就是合并的含義。如果你在 C 目錄對(duì) a、b、c、d、e 文件修改，這個(gè)修改會(huì)對(duì)應(yīng)到 A、B 目錄當(dāng)中生效。

$ tree C
C
├── a
├── b
└── c
├── d
└── e

先決條件

OverlayFS 是推薦的存儲(chǔ)驅(qū)動(dòng)程序，滿足以下先決條件，則支持：

• 4.0 或更高版本的 Linux 內(nèi)核，或使用 3.10.0-514 或更高版本內(nèi)核的 RHEL 或 CentOS。
• 該 overlay2 驅(qū)動(dòng)程序在后備文件系統(tǒng)上受支持 xfs，但僅在 d_type=true 啟用的情況下。用于 xfs_info 驗(yàn)證該 ftype 選項(xiàng)是否設(shè)置為 1。要正確格式化 xfs 文件系統(tǒng)，請(qǐng)使用標(biāo)志 -n ftype=1.
• 更改存儲(chǔ)驅(qū)動(dòng)程序會(huì)使本地系統(tǒng)上的現(xiàn)有容器和圖像無(wú)法訪問(wèn)。docker save 在更改存儲(chǔ)驅(qū)動(dòng)程序之前保存鏡像。

docker info 查看存儲(chǔ)驅(qū)動(dòng)信息：

$ docker info
...
...
Storage Driver: overlay2
  Backing Filesystem: xfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
...
...

Docker 使用 overlary2 存儲(chǔ)驅(qū)動(dòng)程序，會(huì)自動(dòng)創(chuàng)建 lowerdir、upperdir、merged 和 workdir覆蓋掛載結(jié)構(gòu)體。

OverlayFS 在單個(gè) Linux 主機(jī)上將兩個(gè)目錄分層，并將它們呈現(xiàn)為單個(gè)目錄，這些目錄稱為層（layer），兩個(gè)目錄統(tǒng)一為一個(gè)目錄的過(guò)程稱為聯(lián)合掛載（詳細(xì)過(guò)程看上面 兩個(gè)目錄 A 和 B 的例子）。

• OverlayFS 將下層目錄稱為：lowerdir
• OverlayFS 將上層目錄稱為：upperdir
• 統(tǒng)一視圖通過(guò)其 merged 目錄展現(xiàn)出來(lái)（上層和下層目錄的聯(lián)合掛載內(nèi)容展現(xiàn)）

overlay2 驅(qū)動(dòng)程序如何工作

結(jié)構(gòu)圖

下圖顯示了 Docker 鏡像和 Docker 容器是如何分層的：

• lowerdir 是鏡像層
• upperdir 是容器層

如果鏡像有多層，lowerdir 則使用多個(gè)目錄。統(tǒng)一視圖通過(guò)名為 merged 的目錄公開(kāi)，該目錄實(shí)際上是容器安裝位置。該圖顯示了 Docker 如何構(gòu)造映射到 OverlayFS 構(gòu)造。

• 在鏡像層和容器層包含相同文件的情況下，容器層掩蓋了鏡像層中相同文件的存在。
• 為了創(chuàng)建容器，overlay2 驅(qū)動(dòng)程序?qū)⒋礴R像頂層的目錄與容器的新目錄組合在一起。鏡像的圖層位于 lowerdirs 疊加層中并且是只讀的。容器的新目錄是 upperdir 并且是可寫(xiě)的。

探索含義-磁盤(pán)上的鏡像層和容器層

鏡像層

使用 docker pull nginx 命令拉取下載鏡像后，可以看到 nginx 鏡像有 6 層 Docker 映像，對(duì)應(yīng)到磁盤(pán)上是在 /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 目錄下自動(dòng)創(chuàng)建了 6 個(gè)目錄。鏡像層 ID 與目錄 ID 不對(duì)應(yīng)。

目錄 l （小寫(xiě)的 L），包含作為符號(hào)鏈接的縮短層標(biāo)識(shí)符。這些標(biāo)識(shí)符用于避免達(dá)到命令參數(shù)的字符長(zhǎng)度限制（比如 mount）

鏡像層最底層包含一個(gè)名為 diff 的目錄，包含該鏡像層（lowerdir）的內(nèi)容；以及一個(gè)名為 link 的文件，其中包含該 image 層（layer）縮短標(biāo)識(shí)符的名稱。

[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

鏡像層第二低層和每個(gè)更高層包含一個(gè)名為 lower 的文件（里面記錄了鏡像層每層的縮短標(biāo)識(shí)符的名稱）；一個(gè)名為 diff 的目錄（其中包含其內(nèi)容）；還包含一個(gè) merged 目錄（其中包含其父層和自身的統(tǒng)一內(nèi)容）；以及一個(gè) work 目錄 （OverlayFS 內(nèi)部使用的目錄）；最后一個(gè) link 文件，其中包含該 image 層（layer）縮短標(biāo)識(shí)符的名稱。

$ 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)識(shí)符的名稱
 $ 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)的磁盤(pán)上，位于 /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）一致的，說(shuō)明這是基于我們拉取下載下來(lái)的 nginx 鏡像創(chuàng)建的容器。

查看運(yùn)行容器的目錄：

• diff 目錄：包含容器層（UpperDir）內(nèi)容
• link 文件： 其中包含該 image 層（layer）縮短標(biāo)識(shí)符的名稱。
• lower 文件： 記錄了鏡像層和容器層每層的縮短標(biāo)識(shí)符的名稱
• merged 目錄： lowerdir 和 upperdir 目錄的聯(lián)合掛載體現(xiàn)，它包含來(lái)自正在運(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 命令 ，查看將存儲(chǔ)驅(qū)動(dòng)程序與 Docker 一起使用時(shí)存在的掛載 overlay（容器運(yùn)行時(shí)才會(huì)看到掛載 merged 目錄）。括號(hào)開(kāi)頭內(nèi)容： rw ，表示掛載是可讀寫(xiě)的。

可以看到 overlay 聯(lián)合掛載的目錄是 : /var/lib/docker/overlay2/b8925e85fdaa4abff5cfd7f988e2fa08da349b8b983b864b0686b19c0e825d09/merged ，說(shuō)明了這就是容器的根文件系統(tǒng)（rootfs），并且這是由 lowerdir 、upperdir、workdir 三個(gè)目錄聯(lián)合掛載起來(lái)的，同時(shí)這里 mount 使用了每層的縮短標(biāo)識(shí)符的名稱，避免達(dá)到命令參數(shù)的字符長(zhǎng)度限制。

四、overlay2 容器讀寫(xiě)如何工作

還是把上面的結(jié)構(gòu)圖拿過(guò)來(lái)

只讀層

通過(guò)上面的講述，大概也已經(jīng)了解了，只讀層是我們鏡像層（lowerdir）。

讀取文件

考慮三種情況，其中文件在鏡像層和容器層同時(shí)存在使用覆蓋進(jìn)行讀取訪問(wèn)。

• 文件在容器層中不存在： 如果容器打開(kāi)一個(gè)文件進(jìn)行讀取訪問(wèn)，而這個(gè)文件在容器中（upperdir）不存在，則從鏡像中（lowerdir）讀取。這會(huì)產(chǎn)生非常小的性能開(kāi)銷。
• 文件存在容器層中： 如果容器打開(kāi)一個(gè)文件進(jìn)行讀取訪問(wèn)，而這個(gè)文件在容器中（upperdir）存在，那么就直接讀取，不在鏡像中（lowerdir）讀取。
• 文件同時(shí)存在于鏡像層和容器層： 如果容器打開(kāi)一個(gè)文件進(jìn)行讀取訪問(wèn)，而這個(gè)文件同時(shí)在鏡像層和容器層存在，容器層 ( upperdir) 中的文件掩蓋鏡像層 (lowerdir) 中同名的文件，則讀取容器層中的版本。

可讀寫(xiě)層

可讀寫(xiě)層是我們?nèi)萜鲗樱╱pperdir）。

修改文件和目錄

• 1.第一次寫(xiě)入文件： 容器第一次寫(xiě)入文件時(shí)，容器中 (upperdir) 不存在該文件。驅(qū)動(dòng)程序 overlay2 執(zhí)行 copy_up 操作將文件從鏡像層 ( lowerdir) 復(fù)制到容器層 ( upperdir)。
  
  OverlayFS 工作在文件級(jí)別而不是塊級(jí)別。這意味著所有 OverlayFS copy_up 操作都會(huì)復(fù)制整個(gè)文件，即使文件非常大并且只修改了一小部分。這會(huì)對(duì)容器寫(xiě)入性能產(chǎn)生顯著影響。
  • copy_up 操作僅在第一次寫(xiě)入給定文件時(shí)發(fā)生。對(duì)同一文件的后續(xù)寫(xiě)入將針對(duì)已復(fù)制到容器的文件副本進(jìn)行操作。
  • OverlayFS 適用于多層。這意味著在具有多層的圖像中搜索文件時(shí)，性能可能會(huì)受到影響。
• 2.刪除文件和目錄：
  • 容器中刪除文件: 刪除鏡像層中的文件，會(huì)在容器中 (upperdir) 創(chuàng)建一個(gè) whiteout 文件，鏡像層（lowerdir ）中的文件版本沒(méi)有被刪除（因?yàn)槭?lowerdir 只讀的）。但是 whiteout 文件阻止鏡像層對(duì)容器層可用。
  • 容器中刪除目錄： 會(huì)在容器中 ( upperdir ) 創(chuàng)建一個(gè)不透明的目錄。這與 whiteout 文件的工作方式相同，并有效地防止目錄被訪問(wèn)，即使它仍然存在于鏡像中 ( lowerdir)。這樣一看在容器中目錄就被刪除了。

PS：whiteout 文件是什么？

• 比如我要?jiǎng)h除只讀層中（lowerdir 鏡像層）的文件，那么這個(gè)刪除操作實(shí)際上是在可讀寫(xiě)層創(chuàng)建了一個(gè)名叫.wh.foo 的文件。這樣，當(dāng)這兩個(gè)層被聯(lián)合掛載之后，foo 文件就會(huì)被.wh.foo 文件“遮擋”起來(lái)，“消失”了。這個(gè)功能，就是“ro+wh”的掛載方式，即只讀 +whiteout 的含義?？梢孕蜗蟮匕?whiteout 翻譯為：“白障”。

• 3.重命名目錄： 調(diào)用 rename(2) 操作重命名目錄，僅在源路徑和目標(biāo)路徑都在頂層時(shí)才允許調(diào)用。否則，返回 EXDEV 錯(cuò)誤（“不允許跨設(shè)備鏈接”）。您的應(yīng)用程序需要設(shè)計(jì)為處理EXDEV 并回退到“復(fù)制和取消鏈接”策略。

總結(jié)

這里，介紹了 Linux 容器進(jìn)程文件系統(tǒng)的實(shí)現(xiàn)方式，而這種機(jī)制，正是我們經(jīng)常提到的容器鏡像，也叫作：rootfs。它只是一個(gè)操作系統(tǒng)的所有文件和目錄，并不包含內(nèi)核，所以對(duì)比虛擬機(jī)的鏡像要小的多。

通過(guò)結(jié)合使用 Mount Namespace 和 rootfs，容器就能夠?yàn)檫M(jìn)程構(gòu)建出一個(gè)完善的文件系統(tǒng)隔離環(huán)境。這需要依賴 chroot 和 pivot_root 切換進(jìn)程根目錄的能力。

在 rootfs 根文件系統(tǒng)的基礎(chǔ)上，Docker 使用了一個(gè) overlay2 聯(lián)合文件掛載。并提出了容器鏡像中“層”（layer）的概念。

? 最后

?? 我是秋意零，歡迎大家一鍵三連、加入云社區(qū)

?? 我們下期再見(jiàn)(⊙o⊙)?。。?mark hidden color="red">文章來(lái)源：http://www.zghlxwxcb.cn/news/detail-461130.html

參考

參考《深入剖析Kubernetes》作者 張磊
https://docs.docker.com/storage/storagedriver/overlayfs-driver/文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-461130.html

到了這里，關(guān)于【云原生-深入理解 Kubernetes 系列 3】深入理解容器進(jìn)程的文件系統(tǒng)的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！