邢德奇 傅康平 李華夏

（中國電子科技集團公司電子科學(xué)研究院 北京市 100041）

容器技術(shù)在類Unix 操作系統(tǒng)內(nèi)核提供的資源隔離特性基礎(chǔ)上，通過將應(yīng)用軟件與其所依賴的運行環(huán)境共同打包，形成可獨立運行且不發(fā)生相互干擾的實體，稱為“容器”。相較于傳統(tǒng)的虛擬化技術(shù)，由于共享了宿主計算機的操作系統(tǒng)內(nèi)核，通過容器技術(shù)實現(xiàn)的虛擬化，在實現(xiàn)了各類資源的共享和隔離的同時，其用于虛擬化本身的資源開銷顯著小于傳統(tǒng)虛擬化方法。因此，容器技術(shù)已經(jīng)廣泛應(yīng)用于復(fù)雜系統(tǒng)的服務(wù)端軟件封裝。結(jié)合以Kubernetes 為代表的容器編排技術(shù)，可實現(xiàn)大規(guī)模業(yè)務(wù)容器的集群化運行治理。

容器技術(shù)是一種是操作系統(tǒng)層虛擬化技術(shù)，代表性的實現(xiàn)方案包括LXC、rkt、Docker 等，其中又以Docker 最為流行。本文也將以Docker 容器技術(shù)為例，分析容器鏡像倉庫的一般架構(gòu)，并針對弱網(wǎng)絡(luò)下的“云邊”協(xié)同場景，提出一種更高效率的容器鏡像倉庫設(shè)計，滿足云邊場景下的容器鏡像倉庫應(yīng)用需求。

1 Docker文件系統(tǒng)和鏡像倉庫

在Docker 容器技術(shù)中，一般將“容器”定義為提供了隔離能力的虛擬化運行時環(huán)境，而將“鏡像”定義為包含容器運行所需環(huán)境配置和文件的容器模版。簡單的說，容器是由特定鏡像產(chǎn)生的運行實例。本節(jié)將簡要分析Docker 組織容器和鏡像文件系統(tǒng)的一般方法和特性，而本文鏡像倉庫的設(shè)計則正是基于Docker 文件系統(tǒng)的這些特性。

說到Docker 的文件系統(tǒng)，就不得不提“聯(lián)合文件系統(tǒng)”（Union FileSystem），它是一種面向Linux、FreeBSD 和NetBSD 的文件系統(tǒng)服務(wù)，允許不同文件系統(tǒng)的文件和目錄（稱為“分枝”）透明覆蓋，合并形成一個完整的、一致的文件系統(tǒng)。在合并結(jié)果中，來自不同分枝的具有相同路徑的目錄內(nèi)容將在新的虛擬文件系統(tǒng)內(nèi)形成一個合并目錄，其內(nèi)容也是各分枝中相應(yīng)內(nèi)容的合并。聯(lián)合文件系統(tǒng)的這一特點可以支持以分層的形式組織文件系統(tǒng)，即上層文件層構(gòu)建在下層文件層基礎(chǔ)上，描述對下層文件層的改動，進而提高文件系統(tǒng)組織和復(fù)用的效率。

Docker 支持的文件系統(tǒng)之一是AUFS（Advanced Multilayered Unification FileSystem），其本身是聯(lián)合文件系統(tǒng)的一種實現(xiàn)。其支持每個成員目錄設(shè)定為只讀、讀寫或?qū)懗鰴?quán)限，并支持以分層的方式進行文件系統(tǒng)組織。

圖1 給出的是AUFS 的一個示例。該文件系統(tǒng)下，每個Docker 鏡像都可被視為一系列只讀的、包含不同內(nèi)容的文件系統(tǒng)層。在根文件系統(tǒng)（root filesystem）的基礎(chǔ)上，各層向上羅列，共同構(gòu)成了鏡像內(nèi)容。其中，Docker 存儲驅(qū)動（Docker storage driver）負責組織上述分層文件系統(tǒng)，并對外提供統(tǒng)一的應(yīng)用視圖。

圖1：AUFS 示意圖

鏡像構(gòu)建過程中，通過特定語法可編寫Dockerfile，指定基礎(chǔ)鏡像，并定義基礎(chǔ)鏡像之上的系列構(gòu)建步驟。此后，通過Docker 命令進行鏡像構(gòu)建。在“只讀”的基礎(chǔ)鏡像之上，按照步驟執(zhí)行命令或?qū)⑽募砑又羚R像，形成一系列新的“文件層”，此類“文件層”可以包含新文件，也可以包含對其下所有“文件層”中文件的修改或刪除，“文件層”層層累加，以棧的形式構(gòu)成最終鏡像的文件系統(tǒng)。

從文件系統(tǒng)構(gòu)成的角度，容器與鏡像的區(qū)別更加明顯。由于容器是鏡像的運行實例，容器的文件系統(tǒng)在鏡像文件層棧的最上層添加了一層可寫層，用來記錄其在對應(yīng)鏡像的文件系統(tǒng)基礎(chǔ)上，對文件所做的增加、刪除和修改。當容器被刪除，該可寫層將同樣被刪除。當容器被提交成為鏡像，該可寫層也將變?yōu)橹蛔x層，成為新鏡像的一部分。

從Docker 文件系統(tǒng)的上述架構(gòu)特點可以分析出，由相同基礎(chǔ)鏡像構(gòu)建出的多個新鏡像，其基礎(chǔ)鏡像部分的文件系統(tǒng)是相同的，由于其具備只讀屬性，因此也是可共用的。這就為容器鏡像的組織提供了一種體積壓縮的可能性，這也正是Docker 文件系統(tǒng)的重要特點之一。

前文提到的Docker 存儲驅(qū)動正是負責管理和組織各只讀文件層和可寫文件層的模塊。圖2 給出了上述特性的一個圖示。

圖2：分層文件系統(tǒng)示意圖

Docker 目前支持若干不同的聯(lián)合文件系統(tǒng)實現(xiàn)，包括OverlayFS、AUFS、btrfs、VFS、ZFD、Device Mapper 等。

實際使用中，Docker 鏡像以分層文件系統(tǒng)的方式存放于鏡像倉庫。特定主機可根據(jù)需要從鏡像倉庫拉取鏡像，保存至本地，供后續(xù)創(chuàng)建容器等使用。

Docker 鏡像倉庫方面，Docker 公司提供了名為Docker Hub 的商用服務(wù)，Docker 使用者可直接從Docker Hub 拉取鏡像。此外，為便于私有云等私有場景下的鏡像訪問，

Docker 提供了名為Docker Registry 的鏡像倉庫解決方案。Docker Registry 默認對接本地POSIX 文件系統(tǒng)，也可支持亞馬遜S3、微軟Azure、阿里云OSS 等一系列云文件系統(tǒng)。

此外，還涌現(xiàn)出了以Harbor 為代表的第三方鏡像倉庫解決方案，其在標準的Docker Registry 基礎(chǔ)上，額外提供權(quán)限管理、安全管理等一系列實用功能。

2 弱網(wǎng)絡(luò)云邊協(xié)同場景下的容器倉庫需求

在以Kubernetes 為代表的容器云場景中，通過Docker Registry 或Harbor 等軟件，可便捷地構(gòu)建中心式的鏡像倉庫，進而通過鏡像倉庫進行鏡像分發(fā)。

隨著物聯(lián)網(wǎng)等技術(shù)的快速發(fā)展，云邊協(xié)同場景（如圖3 所示）的計算需求越來越大，其通過容器技術(shù)在嵌入式等邊緣設(shè)備上進行軟件部署和管理也逐漸稱為主流。一系列面向邊緣計算場景的容器云管理框架也應(yīng)運而生，如KubeEdge、K3s 等。

圖3：云邊協(xié)同示意圖

云邊協(xié)同場景的典型約束主要包含兩方面：

（1）與中心集群充沛的計算能力形成對比，邊緣側(cè)以嵌入式等低功耗、低算力的設(shè)備為主，其計算、存儲能力相對有限。

（2）邊緣節(jié)點與中心節(jié)點、邊緣節(jié)點之間的網(wǎng)絡(luò)資源往往有限。

在野外、海面等網(wǎng)絡(luò)覆蓋不足的場景，或無人機等節(jié)點動態(tài)變化的場景中，各類設(shè)備往往需要以“弱網(wǎng)絡(luò)”的方式相互連接。該類場景的特點是網(wǎng)絡(luò)帶寬有限、網(wǎng)絡(luò)通信質(zhì)量不穩(wěn)定，且網(wǎng)絡(luò)拓撲有可能動態(tài)變化。在以Docker 為軟件封裝方式的弱網(wǎng)絡(luò)云-邊協(xié)同場景，容器鏡像倉庫的建立面臨若干挑戰(zhàn)：

（1）鏡像倉庫必須以分布式的方式部署，當邊緣節(jié)點與中心集群的網(wǎng)絡(luò)連接出現(xiàn)故障時，需要確保邊緣節(jié)點的鏡像仍可不完全依賴于中心節(jié)點而拉取。

（2）需要建立適應(yīng)于較低網(wǎng)絡(luò)質(zhì)量的分布式鏡像倉庫同步機制，確保當網(wǎng)絡(luò)可用時，通過盡可能少的網(wǎng)絡(luò)帶寬資源完成鏡像倉庫的同步，當網(wǎng)絡(luò)不可用時，邊緣節(jié)點又可通過獨立于中心倉庫的方式獲取鏡像。為此，我們設(shè)計如下面向云邊場景的容器鏡像倉庫。

3 一種面向云邊協(xié)同場景的容器鏡像倉庫設(shè)計

基于上述分析，本文針對上一節(jié)中的場景設(shè)計一種面向云邊協(xié)同場景的容器鏡像倉庫設(shè)計，解決上文提到的幾大挑戰(zhàn)。該鏡像倉庫的組成結(jié)構(gòu)圖如圖4 所示。

圖4：云邊協(xié)同鏡像倉庫組成結(jié)構(gòu)

上述鏡像倉庫主要由如下幾個模塊組成：

3.1 標準鏡像倉庫

該模塊實現(xiàn)容器鏡像分層文件系統(tǒng)的本地管理，可直接采用Docker 提供的Registry，也可采用其他第三方Docker鏡像倉庫解決方案。該模塊通過其對外的REST 接口進行倉庫訪問操作，包括獲取鏡像列表、獲取鏡像標簽列表、獲取鏡像組成信息（manifest）、獲取鏡像文件數(shù)據(jù)等。

3.2 分層抽取管理

該模塊構(gòu)建在標準鏡像倉庫之上，對外提供針對倉庫內(nèi)鏡像特定層的操作接口，包括鏡像特定層導(dǎo)出至文件接口和由文件導(dǎo)入特定鏡像層接口。

3.3 元數(shù)據(jù)管理

該模塊管理倉庫內(nèi)所有鏡像的基本信息（包括鏡像名稱、鏡像標簽、更新時間等），以及所有鏡像的分層文件系統(tǒng)組成信息，并對外提供相應(yīng)操作接口（包括元數(shù)據(jù)信息查詢接口、元數(shù)據(jù)信息更新接口、元數(shù)據(jù)信息導(dǎo)入和導(dǎo)出接口等）。

3.4 同步管理

該模塊維護當前倉庫的同步狀態(tài)信息。本文所設(shè)計鏡像倉庫額外設(shè)置了同步管理功能，用戶可分別指定需要在中心集群和各邊緣集群同步的鏡像。一般云邊協(xié)同場景下，中心集群與邊緣集群的功能定位大多不同，因此各處需要部署的軟件也有所區(qū)別。通過同步管理功能，可更明確地管理需要在云邊進行同步的鏡像，避免有限的網(wǎng)絡(luò)資源產(chǎn)生浪費。同步管理對外提供的接口包括鏡像同步策略查詢和設(shè)定接口、鏡像標簽同步策略查詢和設(shè)定端口等。

3.5 文件可靠傳輸

該模塊基于“分層抽取管理”模塊針對所需鏡像特定層產(chǎn)生的文件，完成弱網(wǎng)絡(luò)條件下的文件可靠傳輸，實現(xiàn)鏡像特定層在不同倉庫之間的同步。該模塊提供的服務(wù)包括傳輸校驗、斷點續(xù)傳在內(nèi)的傳輸服務(wù)。

3.6 運維管理

該模塊以BS 的方式提供對鏡像倉庫的管理頁面，提供的功能包括鏡像倉庫信息（如各類統(tǒng)計信息、存儲信息等）查閱、鏡像及元數(shù)據(jù)信息查閱和操作、同步策略管理、用戶及用戶權(quán)限管理等。

在云邊協(xié)同應(yīng)用場景中，上述鏡像倉庫的運行架構(gòu)如圖5 所示。

圖5：鏡像倉庫運行架構(gòu)

上述鏡像倉庫設(shè)計的主要特點有如下幾方面：

針對中心集群與邊緣集群之間網(wǎng)絡(luò)不穩(wěn)定且?guī)捰邢?，而邊緣小集群?nèi)部網(wǎng)絡(luò)質(zhì)量相對較好的特點，在原有中心倉庫的基礎(chǔ)上，設(shè)計了邊緣側(cè)倉庫。這樣，當邊緣集群中某個節(jié)點暫時無法訪問中心集群資源時，可通過邊緣側(cè)的倉庫實現(xiàn)鏡像的同步。

針對中心倉庫與邊緣側(cè)倉庫的鏡像同步問題，在“元數(shù)據(jù)管理”和“同步管理”兩個模塊的基礎(chǔ)之上，確定倉庫間需要同步的文件層，基于需同步文件層生成狀態(tài)標記，并設(shè)計基于狀態(tài)標記的周期性同步機制。如上文所分析，在一般的云邊協(xié)同場景中，不同邊緣集群往往需要部署不同類別的應(yīng)用。因此，不同邊緣側(cè)倉庫所要從中心倉庫同步的內(nèi)容是有所差別的。為了更有效地利用中心集群和邊緣側(cè)集群之間的網(wǎng)絡(luò)帶寬，通過倉庫的“同步管理”模塊在中心倉庫處維護各邊緣側(cè)倉庫所需要同步的鏡像列表，并基于該列表中所有鏡像的最新狀態(tài)，形成基于最后更新時間戳的狀態(tài)標記。當倉庫間所持的狀態(tài)標記相同時，倉庫不需要同步；當倉庫間狀態(tài)標記不同時，觸發(fā)基于分層文件系統(tǒng)的增量式鏡像同步。

在上述同步策略下，由狀態(tài)標記觸發(fā)同步行為，而同步內(nèi)容則在分層文件系統(tǒng)基礎(chǔ)上，基于“分層抽取管理”模塊產(chǎn)生增量式鏡像同步文件，避免重復(fù)傳輸兩側(cè)已有的鏡像文件層。同時，通過“文件可靠傳輸”模塊實現(xiàn)弱網(wǎng)絡(luò)上的斷點續(xù)傳，進一步降低文件傳輸過程中的帶寬浪費。

4 鏡像倉庫同步算法

綜合上述鏡像倉庫分布策略和同步算法設(shè)計，本節(jié)對本文所設(shè)計的面向云邊協(xié)同的容器鏡像倉庫的應(yīng)用場景分析如下：

4.1 中心倉庫存在新增鏡像時

（1）新增鏡像時，“標準鏡像倉庫”處將保存新增鏡像的相關(guān)基本信息和各類鏡像文件，“元數(shù)據(jù)管理”模塊通過標準鏡像倉庫的相關(guān)接口，獲取新增鏡像的基礎(chǔ)數(shù)據(jù)；

（2）通過“運維管理”模塊，用戶可為新增鏡像補充元數(shù)據(jù)信息，并設(shè)定起在邊緣倉庫的同步策略（包括“不同步”、“全部同步”和“只同步特定標簽”）；

（3）當“同步管理”模塊監(jiān)測到滿足特定同步策略的新增鏡像時，基于“元數(shù)據(jù)管理”的接口獲取新增鏡像的元數(shù)據(jù)信息，信息壓縮后導(dǎo)出成為二進制數(shù)據(jù)流，交由“文件可靠傳輸”模塊傳遞至待同步的邊緣倉庫處；

（4）邊緣倉庫處的“文件可靠傳輸”模塊接收到中心倉庫傳遞的文件后，解壓縮并傳遞至邊緣倉庫處的“同步管理”模塊，邊緣處同步管理模塊對比新鏡像文件層組成和本地鏡像文件層，確定需要同步的文件層清單，并將清單壓縮后導(dǎo)出為二進制數(shù)據(jù)流，交由“文件可靠傳輸”模塊回傳中心倉庫；

（5）中心倉庫的“同步管理”接收到同步需求后，通過“分層抽取管理”模塊，將需要同步的文件層及其元數(shù)據(jù)信息導(dǎo)出為壓縮的二進制文件，交由“文件可靠傳輸”，傳遞至邊緣側(cè)；

（6）邊緣側(cè)的“同步管理”收到“文件可靠傳輸”傳遞的文件后，通過“分層抽取管理”完成文件的導(dǎo)入，進而完成新增鏡像在中心倉庫和邊緣倉庫間的同步。

4.2 中心倉庫既有鏡像出現(xiàn)更新時：

（1）鏡像更新時，“標準鏡像倉庫”處將更新新增鏡像的相關(guān)基本信息和各類鏡像文件，“元數(shù)據(jù)管理”模塊通過標準鏡像倉庫的相關(guān)接口，更新鏡像基礎(chǔ)數(shù)據(jù)；

（2）當“同步管理”模塊監(jiān)測到滿足特定同步策略的鏡像出現(xiàn)更新時，基于“元數(shù)據(jù)管理”的接口獲取更新鏡像的元數(shù)據(jù)信息，信息壓縮后導(dǎo)出成為二進制數(shù)據(jù)流，交由“文件可靠傳輸”模塊傳遞至待同步的邊緣倉庫處；

（3）邊緣倉庫處的“文件可靠傳輸”模塊接收到中心倉庫傳遞的文件后，解壓縮并傳遞至邊緣倉庫處的“同步管理”模塊，邊緣處同步管理模塊對比新鏡像文件層組成和本地鏡像文件層，確定需要同步的文件層清單，并將清單壓縮后導(dǎo)出為二進制數(shù)據(jù)流，交由“文件可靠傳輸”模塊回傳中心倉庫；

（4）中心倉庫的“同步管理”接收到同步需求后，通過“分層抽取管理”模塊，將需要同步的文件層及其元數(shù)據(jù)信息導(dǎo)出為壓縮的二進制文件，交由“文件可靠傳輸”，傳遞至邊緣側(cè)；

（5）邊緣側(cè)的“同步管理”收到“文件可靠傳輸”傳遞的文件后，通過“分層抽取管理”完成文件的導(dǎo)入，刪除更新前的舊鏡像，進而完成更新鏡像在中心倉庫和邊緣倉庫間的同步。

4.3 中心倉庫刪除特定鏡像時

（1）鏡像刪除時，“標準鏡像倉庫”處將刪除鏡像的相關(guān)基本信息和各類鏡像文件，“元數(shù)據(jù)管理”模塊將鏡像元數(shù)據(jù)標記為“待刪除”狀態(tài)；

（2）當“同步管理”模塊監(jiān)測到滿足特定同步策略的鏡像出現(xiàn)刪除時，基于“元數(shù)據(jù)管理”的接口獲取被刪除鏡像的元數(shù)據(jù)信息，信息壓縮后導(dǎo)出成為二進制數(shù)據(jù)流，交由“文件可靠傳輸”模塊傳遞至待同步的邊緣倉庫處；

（3）邊緣倉庫處的“文件可靠傳輸”模塊接收到中心倉庫傳遞的文件后，解壓縮并傳遞至邊緣倉庫處的“同步管理”模塊，完成待刪除鏡像在邊緣倉庫處的刪除，并產(chǎn)生“刪除完成響應(yīng)”發(fā)送至中心倉庫；

（4）中心倉庫的“同步管理”接收到來自所有待刪除邊緣倉庫返回的“刪除完成響應(yīng)”后，通知“元數(shù)據(jù)管理”模塊，刪除鏡像元數(shù)據(jù)，至此完成鏡像的刪除。

5 總結(jié)

本文設(shè)計了一種面向弱網(wǎng)絡(luò)下“云邊”協(xié)同場景的容器鏡像倉庫架構(gòu)，并針對性設(shè)計了同步算法。基于該設(shè)計，可在弱網(wǎng)絡(luò)下實現(xiàn)云-邊之間的倉庫可靠同步，提升倉庫同步成功率、降低同步的網(wǎng)絡(luò)要求。該方法可應(yīng)用于各類網(wǎng)絡(luò)覆蓋不足或網(wǎng)絡(luò)質(zhì)量不佳的云邊協(xié)同場景，是對現(xiàn)有容器鏡像倉庫的功能完善。