?? 前言

上一篇文章講了 Docker 的基本架構(gòu)和 Namespace 隔離機(jī)制：【Docker 那些事兒】關(guān)于Namespace隔離機(jī)制的奧秘
?
本篇文章將繼續(xù)承接上一篇，講講 Cgroup 資源控制和容器底層技術(shù)原理

1. Cgroups

?? Cgroups介紹

在日常工作中，可能需要限制某個(gè)或者某些進(jìn)程的資源分配，于是就出現(xiàn)了 Cgroups 這個(gè)概念。

Cgroups 全稱是 Control groups，這是 Linux 內(nèi)核提供的一種可以限制單個(gè)進(jìn)程或者多個(gè)進(jìn)程使用資源并進(jìn)行分組化管理的機(jī)制，最初是由 Google 的工程師提出，后來被整合進(jìn) Linux 內(nèi)核。

Cgroups 中有分配好特定比例的 CPU 時(shí)間、IO 時(shí)間、可用內(nèi)存大小等。已經(jīng)通過 Linux Namespace 創(chuàng)建的容器，Cgroups 將對(duì)其做進(jìn)一步 “限制”。

另外，Cgroups 采用分層結(jié)構(gòu)，每一層分別限制不同的資源，如圖所示??

圖中，限制層 A 限制了 CPU 時(shí)間片，cgrp1 組中的進(jìn)程可以使用 CPU60% 的時(shí)間片，cgrp2 組中的進(jìn)程可以使用 CPU20% 的時(shí)間片。

限制層 B 限制了內(nèi)存的子系統(tǒng)，Cgroups 中的重要概念就是“子系統(tǒng)”，也就是資源控制器。

子系統(tǒng)就是一個(gè)資源的分配器，例如，CPU 子系統(tǒng)是控制 CPU 時(shí)間分配的。首先掛載子系統(tǒng)，然后才有 Cgroups。

例如，先掛載 memory 子系統(tǒng)，然后在 memory 子系統(tǒng)中創(chuàng)建一個(gè) Cgroups 節(jié)點(diǎn)，在這個(gè)節(jié)點(diǎn)中，將需要控制的進(jìn)程寫入，并且將控制的屬性寫入，這就完成了內(nèi)存的資源限制。

在 Cgroups 中，資源的限制與進(jìn)程并不是簡(jiǎn)單的一對(duì)一關(guān)系，而是多對(duì)多的關(guān)系，多個(gè)限制對(duì)應(yīng)多個(gè)進(jìn)程，如圖所示??

在圖中，每一個(gè)進(jìn)程的描述符都與輔助數(shù)據(jù)結(jié)構(gòu) css_set 相關(guān)聯(lián)。一個(gè)進(jìn)程只能關(guān)聯(lián)一個(gè) css_set，而一個(gè) css_set 可以關(guān)聯(lián)多個(gè)進(jìn)程。css_set 又對(duì)應(yīng)多個(gè)資源限制，關(guān)聯(lián)同一 css_set 的進(jìn)程對(duì)應(yīng)同一個(gè) css_set 所關(guān)聯(lián)的資源限制。

Cgroups 的實(shí)現(xiàn)不允許 css_set 同時(shí)關(guān)聯(lián)同一個(gè) Cgroups 層級(jí)下的多個(gè)限制，也就是 css_set 不會(huì)關(guān)聯(lián)同一種資源的多個(gè)限制。這是因?yàn)闉榱吮苊鉀_突，Cgroups 對(duì)同一種資源不允許有多個(gè)限制配置。

一個(gè) css_set 關(guān)聯(lián)多個(gè) Cgroups 資源限制表示將對(duì)當(dāng)前 css_set 下的所有進(jìn)程進(jìn)行多種資源的控制。一個(gè) Cgroups 資源限制關(guān)聯(lián)多個(gè) css_set 表明多個(gè) css_set 下的所有進(jìn)程都受到同一份資源的相同限制。

Cgroups 被 Linux 內(nèi)核支持，有得天獨(dú)厚的性能優(yōu)勢(shì)，發(fā)展勢(shì)頭迅猛。在很多領(lǐng)域可以取代虛擬化技術(shù)分割資源。Cgroups 默認(rèn)有諸多資源組，幾乎可以限制所有服務(wù)器上的資源。

這里還是以 PID Namespace 為例，雖然容器內(nèi)的 1 號(hào)進(jìn)程在隔離機(jī)制的作用下只能看到容器內(nèi)的情況，但是在宿主機(jī)上，它作為第 100 號(hào)進(jìn)程與其他所有進(jìn)程之間依然是平等競(jìng)爭(zhēng)關(guān)系。

這就意味著，雖然第 100 號(hào)進(jìn)程表面上被隔離了起來，但其能夠使用到的資源（CPU、內(nèi)存等），卻是可以隨時(shí)被宿主機(jī)上的其他進(jìn)程占用，這就可能把所有資源耗光。

Cgroups 技術(shù)的出現(xiàn)，完美地解決了這一問題，對(duì)容器進(jìn)行了合理的資源限制。

?? Cgroups的限制能力

下面介紹 Cgroups 的子系統(tǒng)。

• blkio

該子系統(tǒng)為塊設(shè)備設(shè)定輸入/輸出限制，如物理設(shè)備（磁盤、固態(tài)硬盤、USB等）。

• cpu

該子系統(tǒng)使用調(diào)度程序提供對(duì) CPU 的 Cgroups 任務(wù)訪問。

• cpuacct

該子系統(tǒng)自動(dòng)生成 Cgroups 中任務(wù)所使用的 CPU 報(bào)告。

• cpuset

該子系統(tǒng)為 Cgroups 中的任務(wù)分配獨(dú)立 CPU（在多核系統(tǒng)）和內(nèi)存節(jié)點(diǎn)。

• devices

該子系統(tǒng)可允許或者拒絕 Cgroups 中的任務(wù)訪問設(shè)備。

• freezer

該子系統(tǒng)掛起或者恢復(fù) Cgroups 中的任務(wù)。

• memory

該子系統(tǒng)設(shè)定 Cgroups 中任務(wù)的內(nèi)存限制，并自動(dòng)生成由那些任務(wù)使用的內(nèi)存資源報(bào)告。

• net_cls

該子系統(tǒng)使用等級(jí)識(shí)別符標(biāo)記網(wǎng)絡(luò)數(shù)據(jù)包，可允許 Linux 流量控制程序識(shí)別從具體 Cgroups 中生成的數(shù)據(jù)包。

• ns

該子系統(tǒng)提供了一個(gè)將進(jìn)程分組到不同命名空間的方法。

下面重點(diǎn)介紹 Cgroups 與容器關(guān)系最緊密的限制能力。

Linux 中，Cgroups 對(duì)用戶暴露出來的操作接口是文件系統(tǒng)，即 Cgroups 以文件和目錄的方式處于操作系統(tǒng)的 /sys/fs/cgroup 路徑下。

下面通過命令查看 Cgroups 文件路徑，示例代碼如下：

以上示例中，輸出結(jié)果是一系列文件系統(tǒng)目錄。/sys/fs/cgroup 下面有很多類似 cpuset、cpu、memory 等子目錄，也叫子系統(tǒng)。

這些都是這臺(tái)計(jì)算機(jī)當(dāng)前可以被 Cgroups 進(jìn)行限制的資源種類。而在子系統(tǒng)對(duì)應(yīng)的資源種類下，用戶就可以看到該類資源具體的限制方法。

例如，對(duì)子系統(tǒng) cpu 來說，有如下幾個(gè)配置文件：

cfs_period 和 cfs_quota 這兩個(gè)參數(shù)需要組合使用，以限制進(jìn)程在長(zhǎng)度為 cfs_period 的一段時(shí)間內(nèi)，只能被分配到總量為 cfs_quota 的 CPU 時(shí)間。

?? 實(shí)例驗(yàn)證

下面通過一個(gè)示例，來深入理解 Cgroups。

在子系統(tǒng)下面創(chuàng)建一個(gè)目錄，這個(gè)目錄稱為一個(gè) “控制組”，示例代碼如下：

從以上示例中可以看到，操作系統(tǒng)會(huì)在新創(chuàng)建的目錄下自動(dòng)生成該子系統(tǒng)的資源限制文件。

下面在后臺(tái)執(zhí)行一條腳本，將 CPU 占滿，示例代碼如下：

以上示例執(zhí)行了一個(gè)死循環(huán)命令，進(jìn)程把計(jì)算機(jī)的 CPU 占到 100%，在輸出信息中可以看到這個(gè)腳本在后臺(tái)運(yùn)行的進(jìn)程號(hào)為 7780。

下面使用 top 命令查看一下 CPU 的使用情況，示例代碼如下：

從以上示例的輸出結(jié)果中可以看到，CPU 的使用率已經(jīng)達(dá)到 100%。

下面查看 container 目錄下的文件，示例代碼如下：

從以上示例中可以看到，container 控制組里的 CPU quota 還沒有任何限制（-1），CPU period 則是默認(rèn)的 100ms（100000）。

通過修改這些文件的內(nèi)容就可以進(jìn)行資源限制。例如，向 container 組里的 cfs_quota 文件寫入 20ms（20000us），示例代碼如下：

這就意味著在每 100ms 的時(shí)間里，被該控制組限制的進(jìn)程只能使用 20ms 的 CPU 時(shí)間，也就是說這個(gè)進(jìn)程只能使用到 20% 的 CPU 帶寬。

另外，還需要把被限制的進(jìn)程的進(jìn)程號(hào)寫入 container 組里的 tasks 文件，上面的設(shè)置才會(huì)對(duì)該進(jìn)程生效，示例代碼如下：

下面再次使用 top 命令查看，驗(yàn)證效果，示例代碼如下：

從以上示例中可以看到，計(jì)算機(jī)的 CPU 使用率立刻降到了 19.9%。

關(guān)于 Linux Cgroups 的結(jié)構(gòu)，簡(jiǎn)單理解就是一個(gè)子系統(tǒng)目錄與一組資源限制文件的集合。而對(duì)于類似 Docker 的 Linux 容器項(xiàng)目來說，只需要在每個(gè)子系統(tǒng)下面，為每個(gè)容器創(chuàng)建一個(gè)控制組（即創(chuàng)建一個(gè)新目錄），在啟動(dòng)容器進(jìn)程之后，將該進(jìn)程進(jìn)程號(hào)填寫到對(duì)應(yīng)控制組的 tasks 文件中即可。

控制組下面資源文件中的值，則需要用戶執(zhí)行 docker run 命令的參數(shù)指定，示例代碼如下：

啟動(dòng)這個(gè)容器后，查看 Cgroups 文件系統(tǒng)下 CPU 子系統(tǒng)中 “system.slice” 這個(gè)控制組里的資源限制文件，示例代碼如下：

這就意味著這個(gè) Docker 容器只能使用 20% 的 CPU 帶寬。

?? Cgroups的劣勢(shì)

Cgroups 的資源限制能力也有一些不完善的地方，尤其是/proc文件系統(tǒng)的問題。
?
Linux 操作系統(tǒng)中，/proc 目錄存儲(chǔ)的是記錄當(dāng)前內(nèi)核運(yùn)行狀態(tài)的一系列特殊文件，用戶可以通過訪問這些文件，查看系統(tǒng)信息以及當(dāng)前正在運(yùn)行的進(jìn)程信息。如 CPU 使用情況、內(nèi)存占用情況等，這些文件也是 top 命令查看系統(tǒng)信息的主要數(shù)據(jù)來源。
?
但用戶在容器中執(zhí)行 top 命令時(shí)就會(huì)發(fā)現(xiàn)，顯示的信息居然是宿主機(jī)的 CPU 和 內(nèi)存 數(shù)據(jù)，而不是當(dāng)前容器的數(shù)據(jù)。
?
造成這個(gè)結(jié)果的原因是，/proc 文件系統(tǒng)并不知道用戶通過 Cgroups 對(duì)這個(gè)容器進(jìn)行了資源限制，即 /proc 文件系統(tǒng)不了解 Cgroups 限制的存在。
?
這是企業(yè)中容器化應(yīng)用常見的問題，也是容器相較于虛擬機(jī)的劣勢(shì)。

2. Docker 文件系統(tǒng)

?? 容器可讀可寫層的工作原理

Docker 鏡像采用層級(jí)結(jié)構(gòu)，是根據(jù) Dockerfile 文件中的命令一層一層的通過 docker commit 堆疊而成的一個(gè)只讀文件。容器的最上層是有一個(gè)可讀寫層。這個(gè)可讀寫層在容器啟動(dòng)時(shí)，為當(dāng)前容器單獨(dú)掛載。
?
任何容器在運(yùn)行時(shí)，都會(huì)基于當(dāng)前鏡像在其上層掛載一個(gè)可讀寫層，用戶針對(duì)容器的所有操作都在可讀可寫層中完成。一旦容器被刪除，這個(gè)可讀可寫層也將會(huì)隨之刪除。
?
而用戶針對(duì)這個(gè)可讀可寫層的操作，主要基于兩種方式：寫時(shí)復(fù)制與用時(shí)分配。下面對(duì)這兩種方式進(jìn)行詳解。

?? 寫時(shí)復(fù)制

寫時(shí)復(fù)制（CoW，Copy-on-Write）是所有驅(qū)動(dòng)都要用到的技術(shù)。CoW 表示只在需要寫時(shí)才去復(fù)制，針對(duì)已有文件的修改場(chǎng)景。

例如，基于一個(gè)鏡像啟動(dòng)多個(gè)容器，如果為每個(gè)容器都分配一個(gè)與鏡像一樣的文件系統(tǒng)，那么就會(huì)占用大量的磁盤空間，如圖所示??

而 CoW 技術(shù)可以讓所有容器共享鏡像的文件系統(tǒng)，所有數(shù)據(jù)都從鏡像中讀取，如圖所示??

只在要對(duì)文件進(jìn)行寫操作時(shí)，才從鏡像里把要寫的文件復(fù)制到自己的文件系統(tǒng)進(jìn)行修改，這樣就可以有效地提高磁盤的利用率。

?? 用時(shí)分配

用時(shí)分配是先前沒有分配空間，只有要新寫入一個(gè)文件時(shí)才分配空間，這樣可以提高存儲(chǔ)資源的利用率。

例如，啟動(dòng)一個(gè)容器時(shí)，并不為這個(gè)容器預(yù)分配磁盤空間，當(dāng)有新文件寫入時(shí)，才按需分配空間。

?? Docker 存儲(chǔ)驅(qū)動(dòng)

Docker 提供了多種存儲(chǔ)驅(qū)動(dòng)（Storage Driver）來存儲(chǔ)鏡像，常用的幾種 Storage Driver 是 AUFS、OverlayFS、Device mapper、Btrfs、ZFS。

不同的存儲(chǔ)驅(qū)動(dòng)需要不同的宿主機(jī)文件系統(tǒng)，如表所示??

下面通過 docker info 命令查看本機(jī) Docker 使用的 Storage Driver，示例代碼如下：

從以上示例中可以看到，此處使用的 Storage Driver 是 Overlay2，Backing Filesystem 代表的是本機(jī)的文件系統(tǒng)。用戶可以通過 –storage-driver= 參數(shù)來指定要使用的存儲(chǔ)驅(qū)動(dòng)，或者在配置文件 /etc/default/Docker 中通過 DOCKER_OPTS 指定。

下面介紹幾種常見的存儲(chǔ)驅(qū)動(dòng)。

?? AUFS

AUFS（Another Union File System）是一種聯(lián)合文件系統(tǒng)，是文件級(jí)的存儲(chǔ)驅(qū)動(dòng)。AUFS 是一個(gè)能透明覆蓋一個(gè)或多個(gè)現(xiàn)有文件系統(tǒng)的層狀文件系統(tǒng)，把多層合并成文件系統(tǒng)的單層表示。

簡(jiǎn)單來說，AUFS 支持將不同目錄掛載到同一個(gè)虛擬文件系統(tǒng)下，它可以一層一層地疊加修改文件。下面無論有多少層都是只讀的，只有最上層的文件系統(tǒng)是可讀可寫的。

當(dāng)需要修改一個(gè)文件時(shí)，AUFS 會(huì)為該文件創(chuàng)建一個(gè)副本，使用 CoW 將文件從只讀層復(fù)制到可度可寫層進(jìn)行修改，修改結(jié)果也保存在可讀可寫層。

在Docker 中，下面的只讀層就是鏡像，可讀可寫層就是容器。AUFS 存儲(chǔ)驅(qū)動(dòng)結(jié)構(gòu)如圖所示??

?? OverlayFS

OverlayFS 是 Linux 內(nèi)核 3.18 版本開始支持的，它也是一種聯(lián)合文件系統(tǒng)，與 AUFS 不同的是 Overlay 只有兩層：upper 層與 lower 層，分別代表 Docker 的鏡像層與容器層，如圖所示??

當(dāng)用戶需要修改一個(gè)文件時(shí)，OverlayFS 使用 CoW 將文件從只讀的 lower 層復(fù)制到可讀可寫的 upper 層進(jìn)行修改，結(jié)果也保存在 upper 層。

?? Device mapper

Device mapper 是 Linux 內(nèi)核 2.6.9 版本開始支持的，它提供一種從邏輯設(shè)備到物理設(shè)備的映射框架機(jī)制，在該機(jī)制下，用戶可以很方便地根據(jù)自己的需要制定實(shí)現(xiàn)存儲(chǔ)資源的管理策略。AUFS 與 OverlayFS 都是文件級(jí)存儲(chǔ)，而 Device Mapper 是塊級(jí)存儲(chǔ)，所有的操作都是直接對(duì)塊進(jìn)行的。

Device Mapper 會(huì)先在塊設(shè)備上創(chuàng)建一個(gè)資源池，然后在資源池上創(chuàng)建一個(gè)帶有文件系統(tǒng)的基本設(shè)備，所有鏡像都是這個(gè)基本設(shè)備的快照，而容器則是鏡像的快照。所以在容器里看到文件系統(tǒng)是資源池上基本設(shè)備的文件系統(tǒng)的快照，容器并沒有被分配空間，如圖所示??

當(dāng)用戶要寫入一個(gè)新文件時(shí)，Device Mapper 在容器的鏡像內(nèi)為其分配新的塊并寫入數(shù)據(jù)，也就是用時(shí)分配。

當(dāng)用戶要修改已有文件時(shí)，Device Mapper 使用 CoW 為容器快照分配塊空間，將要修改的數(shù)據(jù)復(fù)制到在容器快照中新的塊里，再進(jìn)行修改。

Device mapper 默認(rèn)會(huì)創(chuàng)建一個(gè) 100GB 的文件來包含鏡像和容器。每一個(gè)容器被限制在 10GB 大小的卷內(nèi)，可以自己配置調(diào)整。

Device Mapper 存儲(chǔ)驅(qū)動(dòng)讀寫機(jī)制結(jié)構(gòu)如圖所示??

Docker 容器的存儲(chǔ)驅(qū)動(dòng)各有其特點(diǎn)，下面對(duì)三種存儲(chǔ)驅(qū)動(dòng)進(jìn)行對(duì)比，如表所示??

• AUFS 與 OverlayFS

AUFS 和 OverlayFS 都是聯(lián)合文件系統(tǒng)，但 AUFS 有多層，而 OverlayFS 只有兩層，所以在做寫時(shí)復(fù)制操作時(shí)，如果文件比較大且存在于比較低的層，則 AUFS 可能會(huì)更慢一點(diǎn)。
?
另外，OverlayFS 并入了 Linux 系統(tǒng)核心主線，而 AUFS 沒有。

• OverlayFS 與 Device mapper

OverlayFS 是文件級(jí)存儲(chǔ)，Device Mapper 是塊級(jí)存儲(chǔ)。
?
文件級(jí)存儲(chǔ)不管修改的內(nèi)容大小都會(huì)復(fù)制整個(gè)文件，對(duì)大文件進(jìn)行修改顯示要比小文件消耗更多的時(shí)間，而塊級(jí)存儲(chǔ)無論是大文件還是小文件都只復(fù)制需要修改的塊，并不是復(fù)制整個(gè)文件，如此一來 Device Mapper 速度就要快一些。
?
塊級(jí)存儲(chǔ)直接訪問邏輯磁盤，適合 IO 密集的場(chǎng)景。而對(duì)于程序內(nèi)部復(fù)雜，多并發(fā)但少 IO 的場(chǎng)景， OverlayFS 的性能相對(duì)要強(qiáng)一些。

3. 總結(jié)

本章深層次剖析了容器的底層技術(shù)，包括 Docker 的基本架構(gòu)、Namespace、Cgroups 和 存儲(chǔ)驅(qū)動(dòng) 等。
?
通過這兩篇文章的學(xué)習(xí)可以明白，容器的強(qiáng)大不僅來源于其本身的結(jié)構(gòu)，更重要的是依靠宿主機(jī)的硬件支持。
?
在實(shí)際應(yīng)用 Docker 容器時(shí)，還會(huì)利用相關(guān)的系統(tǒng)配置與資源限制，來對(duì)容器進(jìn)行優(yōu)化。文章來源地址http://www.zghlxwxcb.cn/news/detail-779654.html

到了這里，關(guān)于【Docker 那些事兒】關(guān)于容器底層技術(shù)的奧秘的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！