［牛思杰 潘碧瑩 龐濤］

1 引言

容器技術(shù)是一種輕量級(jí)、可移植、自包含的軟件打包技術(shù)，使應(yīng)用程序可以在幾乎任何地方以相同的方式運(yùn)行，現(xiàn)階段已經(jīng)發(fā)展成為應(yīng)用分發(fā)和交付的標(biāo)準(zhǔn)技術(shù)。

隨著移動(dòng)通信技術(shù)發(fā)展到5G 時(shí)代，容器技術(shù)助力云邊計(jì)算一體化，實(shí)現(xiàn)了云端和邊緣端的業(yè)務(wù)靈活編排，任務(wù)靈活調(diào)度，資源按需分配，但終端的發(fā)展還是垂直煙囪式、碎片化的現(xiàn)狀，終端和邊云不能按需進(jìn)行任務(wù)的動(dòng)態(tài)分配和資源的靈活共享，并且很難實(shí)現(xiàn)不同終端之間的資源共享。受限于終端相對(duì)緊缺的硬件資源以及各種終端之間硬件架構(gòu)的差異，目前云端以及邊緣端上廣泛應(yīng)用的容器技術(shù)棧無(wú)法很好地運(yùn)行在各種類型的終端上。因此，終端側(cè)亟需一次技術(shù)革新，借鑒云端容器技術(shù)，研發(fā)可通用在各種異構(gòu)終端上的輕量化容器技術(shù)，推動(dòng)終端的虛擬化改造，以滿足云網(wǎng)融合的戰(zhàn)略機(jī)遇下端邊云網(wǎng)一體化的發(fā)展需求。

本文將通過(guò)研究對(duì)比目前業(yè)界的主流容器技術(shù)，結(jié)合終端容器的特點(diǎn)和需求，總結(jié)終端輕量化容器技術(shù)的發(fā)展方向。文中第2 節(jié)將介紹本次研究評(píng)測(cè)的背景，包括容器技術(shù)的發(fā)展現(xiàn)狀、目前業(yè)界4 種主流容器引擎即Docker、Containerd、iSulad 和balenaEngine 的技術(shù)特點(diǎn)，以及相關(guān)文獻(xiàn)中工作的梳理與借鑒。第3 節(jié)中將介紹本次測(cè)試的測(cè)試指標(biāo)、工具和測(cè)試環(huán)境。第4 節(jié)中將展示本次測(cè)試的測(cè)試結(jié)果，并針對(duì)結(jié)果數(shù)據(jù)進(jìn)行研究評(píng)測(cè)。第5 節(jié)中將給出本次測(cè)試的測(cè)試結(jié)論。第6 節(jié)中進(jìn)行總結(jié)并展望未來(lái)終端輕量化容器技術(shù)的發(fā)展方向。

2 背景

2.1 容器技術(shù)研究

容器技術(shù)的概念可以追溯到1979 年的Unix Chroot，Chroot 為每個(gè)進(jìn)程提供一套隔離化磁盤空間，進(jìn)而虛擬化進(jìn)程文件目錄，不能夠防止進(jìn)程惡意訪問(wèn)系統(tǒng)。2000 年提出Freebsd Jail技術(shù)，包含有進(jìn)程沙箱機(jī)制以對(duì)文件系統(tǒng)、用戶及網(wǎng)絡(luò)等資源進(jìn)行隔離，實(shí)現(xiàn)了操作系統(tǒng)級(jí)別的虛擬化，然而這種簡(jiǎn)單性的隔離影響Jails 中應(yīng)用訪問(wèn)系統(tǒng)資源的靈活性[1]。2004 年出現(xiàn)了專為X86 和SPARC 系統(tǒng)設(shè)計(jì)的虛擬化技術(shù)Solaris Zone，該技術(shù)真正的引入了容器資源管理的概念。Solaris 容器是系統(tǒng)資源控制和通過(guò) "區(qū)域" 提供邊界隔離的組合，Solaris Zone 技術(shù)讓?xiě)?yīng)用在隔離的Zone 中運(yùn)行，并實(shí)現(xiàn)有效的資源管理，每一個(gè)Zone 擁有自己的文件系統(tǒng)，進(jìn)程空間，防火墻，網(wǎng)絡(luò)配置等[2]。2008 年提出的LXC（Linux Containers）通過(guò)Namespaces和Cgroups 實(shí)現(xiàn)容器的隔離和資源控制，將容器支持集成到主流Linux 內(nèi)核，允許使用單個(gè)Linux 內(nèi)核在宿主機(jī)上運(yùn)行多個(gè)獨(dú)立的系統(tǒng)[3]。隨著容器技術(shù)的發(fā)展，在原版Linux 內(nèi)核上運(yùn)行容器已經(jīng)成為行業(yè)共識(shí)，容器技術(shù)因其特有的優(yōu)勢(shì)也在不同領(lǐng)域和設(shè)備中廣泛應(yīng)用，如云平臺(tái)的Docker 和Containerd、嵌入式設(shè)備的Belena、資源受限端側(cè)設(shè)備的isulad，也在虛擬化技術(shù)中發(fā)揮著關(guān)鍵作用。

容器位于物理服務(wù)器及其主機(jī)操作系統(tǒng)之上，將應(yīng)用所需的軟件和依賴項(xiàng)目打包成標(biāo)準(zhǔn)化單元，以用于開(kāi)發(fā)、交付和部署。容器具有如下特點(diǎn)：

隔離性：容器底層運(yùn)用Namespaces 和Cgroups 技術(shù)實(shí)現(xiàn)容器進(jìn)程對(duì)外界的隔離，即在單一主機(jī)上安全的運(yùn)行多個(gè)應(yīng)用，其中的每個(gè)應(yīng)用都有自己的隔離環(huán)境。

高效性：容器對(duì)操作系統(tǒng)進(jìn)行抽象，每個(gè)容器只包括應(yīng)用程序與必要的依賴資源，共享操作系統(tǒng)內(nèi)核，因此占用空間小，能夠快速啟動(dòng)和遷移。

可移植：容器消除了開(kāi)發(fā)、測(cè)試、生產(chǎn)環(huán)境的不一致性，容器應(yīng)用可以被移植到其它宿主機(jī)器中，為開(kāi)發(fā)和運(yùn)維提供標(biāo)準(zhǔn)化的解決方案。

2.1.1 Docker

Docker 是一個(gè)開(kāi)源的應(yīng)用容器引擎，基于Go 語(yǔ)言開(kāi)發(fā)并遵循了Apache2.0 協(xié)議開(kāi)源。Docker 可以讓開(kāi)發(fā)者將應(yīng)用和依賴包打包到一個(gè)輕量級(jí)、可移植的容器中，發(fā)布到任何流行的Linux 服務(wù)器[4]。

Docker 首次發(fā)布時(shí)由兩個(gè)核心組件構(gòu)成：Docker daemon 和LXC（Linux Container）。Docker daemon 是單一的二進(jìn)制文件，包含諸如Docker 客戶端、Docker API、容器運(yùn)行時(shí)、鏡像構(gòu)建等；LXC 提供了對(duì)諸如命名空間（Namespaces）和控制組（Cgroups）等基礎(chǔ)工具的操作能力[5,6]。Docker daemon、LXC 和操作系統(tǒng)之間的交互關(guān)系如圖1 所示。

圖1 Docker 調(diào)用鏈?zhǔn)疽鈭D

隨著時(shí)間的推移，Docker 公司也在不斷完善Docker 的功能。Docker 公司開(kāi)發(fā)了與平臺(tái)無(wú)關(guān)的工具Libcontainer，將容器引擎的底層實(shí)現(xiàn)抽象化到Libcontainer 接口，只要實(shí)現(xiàn)了Libcontainer 定義的一組接口，Docker 就可以運(yùn)行，進(jìn)而實(shí)現(xiàn)基于不同內(nèi)核為Docker 上層提供必要的容器交互的功能。在Docker 0.9 版本中，Libcontainer 取代LXC成為Docker 默認(rèn)的執(zhí)行驅(qū)動(dòng)。2015 年，Docker 公司將Libcontainer 捐給一個(gè)完全中立的基金會(huì)管理，并改名為runC。功能完備的Docker daemon 使得Docker 難于變更、運(yùn)行越來(lái)越慢，不利于Docker 生態(tài)的發(fā)展，因此Docker公司開(kāi)始著手模塊化Docker daemon 進(jìn)程，拆解出其中的功能特性，重構(gòu)為小而專的工具來(lái)實(shí)現(xiàn)這些功能。

2.1.2 Containerd

2016 年，Docker 把負(fù)責(zé)容器生命周期的模塊拆分出來(lái)捐贈(zèng)給CNCF 社區(qū)，這便是Containerd 的前身，后社區(qū)為其添加了鏡像管理模塊和CRI 模塊，使得Containerd具備支持kubelet 創(chuàng)建Pod 所需的全部功能。2019 年2 月Containerd 從CNCF 社區(qū)畢業(yè)，進(jìn)入生產(chǎn)環(huán)境作為容器運(yùn)行時(shí)使用。Containerd 項(xiàng)目源自Docker，在集成Docker 特性的基礎(chǔ)上，也進(jìn)行了功能優(yōu)化，通過(guò)將image、filesystem、runtime 解耦合，實(shí)現(xiàn)插件式的拓展和重用。Containerd 支持OCI 和CRI 規(guī)范，可以與低級(jí)運(yùn)行時(shí)（runC）和容器編排工具（如Kubernetes）交互，不需Docker-shim 的參與，簡(jiǎn)化了管理容器生命周期的調(diào)用鏈，便于Kubernetes 項(xiàng)目的維護(hù)工作[7]。

目前，Containerd 已經(jīng)成為了一個(gè)工業(yè)級(jí)容器技術(shù)了，采用標(biāo)準(zhǔn)的C/S 架構(gòu)，服務(wù)端通過(guò)GRPC 協(xié)議提供穩(wěn)定的 API，客戶端通過(guò)調(diào)用服務(wù)端的API 進(jìn)行高級(jí)的操作。開(kāi)發(fā)人員或者終端用戶可以在宿主機(jī)中管理完整的容器生命周期，包括容器鏡像的傳輸和存儲(chǔ)、容器的執(zhí)行和管理、存儲(chǔ)和網(wǎng)絡(luò)等。在容器技術(shù)逐步標(biāo)準(zhǔn)化后，Containerd 在相關(guān)的技術(shù)棧中將占據(jù)非常重要的地位，Containerd 提供的核心服務(wù)將成為底層管理容器的標(biāo)準(zhǔn)。屆時(shí)，更上層的容器化應(yīng)用平臺(tái)將直接使用Containerd 提供的基礎(chǔ)服務(wù)。在開(kāi)源社區(qū)方面，Containerd 一直保持很活躍的狀態(tài)，這個(gè)項(xiàng)目的成熟離不開(kāi)社區(qū)廣大contributors 的貢獻(xiàn)。

2.1.3 iSulad

iSula是華為開(kāi)源的一種云原生輕量級(jí)容器解決方案，可通過(guò)統(tǒng)一、靈活的架構(gòu)滿足ICT 領(lǐng)域端、邊、云場(chǎng)景的多種需求[8]。iSulad 是iSula 技術(shù)鏈中的通用容器引擎，它提供統(tǒng)一的架構(gòu)設(shè)計(jì)來(lái)滿足CT 和IT 領(lǐng)域的不同需求。相比Golang 編寫(xiě)的Docker，iSulad 基于C/C++編寫(xiě)，具有輕、靈、巧、快的特點(diǎn)，不受硬件規(guī)格和架構(gòu)的限制，底噪開(kāi)銷更小，可應(yīng)用領(lǐng)域更為廣泛。iSulad 作為輕量化的容器底座，可以為多種場(chǎng)景提供靈活、穩(wěn)定、安全的底層支撐。

架構(gòu)設(shè)計(jì)上，除了啟動(dòng)容器部分需要通過(guò)fork/exec的方式，其他部分均使用調(diào)用函數(shù)庫(kù)的方式加快執(zhí)行速度；通過(guò)將鏡像和rootfs 部分獨(dú)立為服務(wù)，以及優(yōu)化鏡像模塊元數(shù)據(jù)的隔離性，實(shí)現(xiàn)了不同鏡像和rootfs 之間的操作完全隔離。

由于iSulad 資源占用較低，對(duì)容器引擎占用資源限制要求比較高的場(chǎng)景，如CT、嵌入式、邊緣側(cè)等，可以使用iSulad 容器引擎。iSulad 支持北向CRI 標(biāo)準(zhǔn)接口，可應(yīng)用于對(duì)接Kubernetes 實(shí)現(xiàn)容器的編排管理。此外，iSulad 除了支持運(yùn)行普通容器，還支持運(yùn)行系統(tǒng)容器、安全容器滿足用戶不同應(yīng)用場(chǎng)景下的需求。

2.1.4 balenaEngine

balenaEngine 是Balena.io 公司推出的一款與Docker兼容的用于嵌入式設(shè)備上的容器引擎，專門針對(duì)嵌入式和IoT 用例而構(gòu)建，并且與Docker 容器兼容[9]。balenaEngine 基于Docker 的Moby Project，支持容器增量，二進(jìn)制文件更小，更保守地使用RAM 和存儲(chǔ)，并專注于容器抽取的原子性和持久性。

與Docker 相比，balenaEngine 具備以下特點(diǎn)：①支持容器鏡像的增量拉取，節(jié)省10x～70x 的下載帶寬。②容器鏡像可以中斷后重新拉取。這意味著，當(dāng)嵌入式設(shè)備掉電再重新上電時(shí)，容器鏡像可以繼續(xù)拉取。③容器執(zhí)行文件體積是Docker 執(zhí)行文件體積的2/7 左右。④改進(jìn)了鏡像拉取使用頁(yè)面緩存的機(jī)制，避免在低內(nèi)存的嵌入式設(shè)備下出現(xiàn)頁(yè)面緩存抖動(dòng)。⑤去除了Docker 幾個(gè)不適用于嵌入式場(chǎng)景下的功能，例如Docker Swarm，插件支持，云端日志系統(tǒng)，overlay 網(wǎng)絡(luò)驅(qū)動(dòng)等。⑥只支持Linux 系統(tǒng)。

2.2 相關(guān)文獻(xiàn)

關(guān)于終端容器技術(shù)研究與評(píng)測(cè)的文獻(xiàn)很少，大多數(shù)相關(guān)的研究只對(duì)容器在基于X86 架構(gòu)的服務(wù)器上運(yùn)行時(shí)的各項(xiàng)性能指標(biāo)進(jìn)行了部分的研究對(duì)比。

通過(guò)前期的調(diào)查研究，文獻(xiàn)[10]中對(duì)比了Containerd和crio 在，runC 和gvisor 的底層runtime 下，10/20*run 命令下，CPU、MEM、Disk I/O 的性能對(duì)比。文獻(xiàn)[11]中測(cè)試了不同容器引擎在串行和并行情況下創(chuàng)建、啟動(dòng)、停止、刪除等容器生命周期操作下的耗時(shí)。[12]中使用cAdvisor和mpstat 測(cè)試容器運(yùn)行產(chǎn)生的CPU 負(fù)載，使用docker stats 測(cè)試容器中運(yùn)行線程請(qǐng)求的CPU 資源，使用iostat 工具監(jiān)測(cè)系統(tǒng)磁盤I/O。[13]中介紹了在docker 與KVM 中運(yùn)行程序的性能對(duì)比，對(duì)比的主要性能指標(biāo)為系統(tǒng)boot 時(shí)間和其中進(jìn)行CPU 運(yùn)算的速度，在兩項(xiàng)指標(biāo)中docker 均明顯優(yōu)于KVM。[14]中針對(duì)CPU、內(nèi)存、磁盤I/O、請(qǐng)求負(fù)載、處理速度等方面對(duì)docker 和虛擬機(jī)進(jìn)行了性能對(duì)比，測(cè)試中使用了Sysbench，Phoronix，和apache benchmarking 等測(cè)試工具。[15]對(duì)資源相對(duì)受限的移動(dòng)邊緣計(jì)算環(huán)境下進(jìn)行了研究，發(fā)現(xiàn)無(wú)論容器化進(jìn)程的CPU 周期消耗如何，Docker 進(jìn)程的CPU 使用是恒定的。文獻(xiàn)[16]中提出針對(duì)CPU 和I/O 密集型任務(wù)負(fù)載對(duì)Docker 進(jìn)行了基準(zhǔn)測(cè)試，結(jié)果顯示了當(dāng)容器生命周期結(jié)束時(shí)，Docker 引擎的資源開(kāi)銷從10%減少至5%。[17]中的試驗(yàn)將Docker 與Flockport容器（基于LXC 的一款開(kāi)源容器）進(jìn)行了比較，結(jié)果顯示，對(duì)于這兩種容器實(shí)現(xiàn)，I/O 和系統(tǒng)調(diào)用是造成性能開(kāi)銷的主要原因，Docker 的內(nèi)存性能略優(yōu)于Flockport。[18][19]中多個(gè)測(cè)試維度對(duì)比了虛擬化技術(shù)和容器技術(shù)的系統(tǒng)資源開(kāi)銷。

3 測(cè)試標(biāo)準(zhǔn)

3.1 測(cè)試指標(biāo)與工具

綜合考慮相關(guān)文獻(xiàn)中的測(cè)試方案以及終端設(shè)備的相關(guān)硬件指標(biāo)，本次測(cè)試的測(cè)試指標(biāo)項(xiàng)包括。

磁盤空間占用：對(duì)于很多的終端設(shè)備來(lái)說(shuō)，磁盤空間都是很緊缺的資源，不同于云端以及邊緣端服務(wù)器動(dòng)輒數(shù)以TB 的磁盤陣列，有些終端（例如攝像頭）上的磁盤空間只有數(shù)十MB，這意味著體積過(guò)大的容器引擎在終端上是行不通的。本次測(cè)試中使用ls 查看容器引擎二進(jìn)制文件的尺寸大小。

內(nèi)存占用：內(nèi)存占用指的是此進(jìn)程所開(kāi)銷的內(nèi)存，內(nèi)存占用過(guò)大，會(huì)影響機(jī)器的整體性能。終端設(shè)備通常內(nèi)存配置較低，所以要求容器引擎的內(nèi)存占用要盡量減少。本次測(cè)試中使用free 命令查看容器引擎服務(wù)的系統(tǒng)內(nèi)存占用情況。

容器生命周期操作耗時(shí)：容器的生命周期操作是指容器的創(chuàng)建、啟動(dòng)、運(yùn)行、停止和刪除等操作，其中運(yùn)行操作可視為創(chuàng)建和啟動(dòng)兩個(gè)操作順序執(zhí)行。容器生命周期各項(xiàng)操作的耗時(shí)是衡量容器引擎性能的重要指標(biāo)，尤其在容器的批量操作時(shí)，細(xì)微的差距會(huì)被倍數(shù)的放大。本項(xiàng)測(cè)試的前置條件是使用docker 官方的busybox 鏡像且鏡像已提前拉取到本地，測(cè)試中使用shall 編寫(xiě)腳本進(jìn)行容器各項(xiàng)操作耗時(shí)的測(cè)試，并對(duì)單獨(dú)執(zhí)行一次操作以及并行執(zhí)行十次操作兩種情況進(jìn)行分別測(cè)試。

CPU 使用率：CPU 使用率是系統(tǒng)性能監(jiān)測(cè)中最重要的性能指標(biāo)之一。它是確定應(yīng)用程序處理速度的主要分析值，而處理速度是網(wǎng)絡(luò)和服務(wù)器運(yùn)行狀況的關(guān)鍵性能指標(biāo)。終端設(shè)備通常CPU 算力配置較低，對(duì)容器引擎的CPU 使用有一定限制。本項(xiàng)測(cè)試的前置條件是使用docker 官方的busybox 鏡像且鏡像已提前拉取到本地，測(cè)試中使用sar工具查看容器生命周期操作中CPU 的實(shí)時(shí)使用率，并對(duì)單獨(dú)執(zhí)行一次操作以及并行執(zhí)行十次操作兩種情況進(jìn)行分別測(cè)試。sar 是 sysstat 工具包的組成部分，可以收集并報(bào)告操作系統(tǒng)中廣泛的系統(tǒng)活動(dòng)，包括CPU 使用率、上下文切換和中斷速率、頁(yè)換入和頁(yè)換出速率、共享內(nèi)存使用情況、緩沖區(qū)使用情況以及網(wǎng)絡(luò)使用情況。

磁盤I/O 占用磁盤的輸入輸出。輸入指的是對(duì)磁盤寫(xiě)入數(shù)據(jù)，輸出指的是從磁盤讀出數(shù)據(jù)。磁盤I/O 負(fù)載過(guò)高會(huì)造成數(shù)據(jù)阻塞，導(dǎo)致系統(tǒng)響應(yīng)速度變慢。本項(xiàng)測(cè)試的前置條件是使用docker 官方的busybox 鏡像且鏡像已提前拉取到本地，測(cè)試中使用sar 工具查看容器生命周期操作中磁盤I/O 占用情況，并對(duì)單獨(dú)執(zhí)行一次操作以及并行執(zhí)行十次操作兩種情況進(jìn)行分別測(cè)試。

3.2 測(cè)試環(huán)境

本次測(cè)試的硬件環(huán)境基于樹(shù)莓派4B0，如圖2 所示。

圖2 樹(shù)莓派4B 嵌入式開(kāi)發(fā)板樣式圖

主要配置情況如下。

處理器：Broadcom BCM2711 ARM V8 Cortex-A72 64 位1.5 GHZ 4 核處理器

內(nèi)存：4G DDR4 內(nèi)存

硬盤：16G 硬盤

本次測(cè)試的軟件環(huán)境如下：

操作系統(tǒng)：CentOS 7.3.10

容器軟件版本：Docker 20.10.6，Containerd 1.4.4，iSulad 2.0.0，Balena-engine v17.12.0

4 測(cè)試結(jié)果

4.1 磁盤空間占用

4 種容器引擎的體積占用磁盤空間情況如圖3 所示，其中灰色的柱體表示各容器引擎軟件包總體大小，由于四種容器引擎均采用CS 架構(gòu)設(shè)計(jì)，所以軟件包均包括服務(wù)器端和客戶端兩個(gè)二進(jìn)制文件，除此之外，軟件包中還包含一些功能組件。

圖3 磁盤空間占用對(duì)比圖

從對(duì)比可以看出，使用C 語(yǔ)言編寫(xiě)的iSulad 在服務(wù)器端以及客戶端體積上優(yōu)勢(shì)明顯，而Docker 作為目前在云端和邊緣端最廣泛運(yùn)用的容器引擎，體積遠(yuǎn)高于其他3種容器引擎。值得一提的是，balenaEngine 的服務(wù)器端和客戶端以及其他組件集成到了同一個(gè)二進(jìn)制文件中，故其軟件包的體積即為服務(wù)器端的體積。Containerd 的軟件包總體大小為100 M 左右，對(duì)于目前的手機(jī)終端來(lái)說(shuō)尚可接受，但是對(duì)于諸如攝像頭等一些資源受限的終端來(lái)說(shuō)還是過(guò)于龐大。

4.2 內(nèi)存占用

4 種容器引擎啟動(dòng)后進(jìn)程的內(nèi)存占用情況如圖4 所示，Docker 進(jìn)程的內(nèi)存占用超過(guò)120 M，對(duì)于很多中低配置的終端設(shè)備來(lái)說(shuō)是沉重的負(fù)擔(dān)，這意味著無(wú)法保留足夠多的內(nèi)存來(lái)保證容器內(nèi)業(yè)務(wù)應(yīng)用的運(yùn)行。Containerd、iSulad 和balenaEngine 進(jìn)程的內(nèi)存占用情況相對(duì)較低，相對(duì)Docker 都減少了一半以上，分布在40～60 M 之間，其中Containerd 內(nèi)存占用最少，為43.07 MB。以一個(gè)普通智能攝像頭的的配置為例，內(nèi)存的配置為128 M，上述3種容器引擎的內(nèi)存占用情況是在相對(duì)可以接受的范圍之內(nèi)的。

圖4 進(jìn)程內(nèi)存占用對(duì)比圖

4.3 容器生命周期操作耗時(shí)

4 種容器引擎生命周期各項(xiàng)操作耗時(shí)情況如圖5、6所示，結(jié)果顯示，不管是在單次還是并行10 次執(zhí)行生命周期操作情況下，4 種容器引擎的性能優(yōu)劣順序是基本一致的。Docker 作為4 種容器引擎中體積最大、占用內(nèi)存最多的一種，它的各項(xiàng)生命周期操作耗時(shí)也是最多的，單次運(yùn)行容器耗時(shí)達(dá)到了1 201 ms，而該項(xiàng)最優(yōu)的Containerd耗時(shí)僅為303 ms。從測(cè)試結(jié)果中可以看出，Containerd和iSulad 的整體表現(xiàn)明顯優(yōu)于Docker 和balenaEngine，Containerd 在運(yùn)行容器操作上最具優(yōu)勢(shì)，而iSulad 停止、刪除容器操作上略勝一籌。從整體而言，并行10 次的執(zhí)行耗時(shí)會(huì)比單次耗時(shí)的10 倍少30%～50%。

圖5 單次生命周期操作耗時(shí)對(duì)比圖

圖6 并發(fā)10 次生命周期操作耗時(shí)對(duì)比圖

4.4 CPU 使用率

4 種容器引擎生命周期各項(xiàng)操作的CPU 使用情況如圖7、圖8 所示。在單次執(zhí)行情況下，4 種容器引擎在容器的創(chuàng)建和運(yùn)行兩種操作的耗時(shí)差距很大，Containerd 和iSulad 的表現(xiàn)明顯優(yōu)于Docker 和balenaEngine。而在容器的停止和停止方面，iSulad 和balenaEngine 具有一定優(yōu)勢(shì)。而在并發(fā)10 次執(zhí)行情況下，Docker 和balenaEngine 基本CPU 滿載，在測(cè)試的硬件環(huán)境下達(dá)到性能瓶頸，相比之下iSulad 的表現(xiàn)最好。

圖7 單次生命周期操作CPU 使用對(duì)比圖

圖8 并發(fā)10 次生命周期操作CPU 使用對(duì)比圖

4.5 磁盤I/O

4 種容器引擎生命周期各項(xiàng)操作的磁盤I/O 占用情況如圖9、圖10 所示。從執(zhí)行情況來(lái)看，在單次執(zhí)行情況下，除Docker 外，其他3 種容器引擎均低于20%，在并發(fā)10 次執(zhí)行的情況下，balenaEngine 各項(xiàng)操作的磁盤I/O占用飆升，成為了4 種容器引擎中最占用資源的一種，而Containerd 和iSulad 的表現(xiàn)基本和單次執(zhí)行的結(jié)果呈現(xiàn)倍數(shù)關(guān)系。值得注意的是，4 種容器引擎在容器的停止操作時(shí)的磁盤I/O 占用均趨近于[20]，說(shuō)明該過(guò)程中不涉及磁盤數(shù)據(jù)的讀寫(xiě)。

圖9 單次生命周期操作磁盤I/O 占用對(duì)比圖

圖10 并發(fā)10 次生命周期操作磁盤I/O 占用對(duì)比圖

5 測(cè)試結(jié)論

對(duì)于終端上的容器引擎來(lái)說(shuō)，磁盤空間占用以及進(jìn)程的內(nèi)存占用首先需要考慮的，這決定了容器引擎是否可以成功運(yùn)行。從磁盤空間占用比較來(lái)看，基于C 語(yǔ)言編寫(xiě)的isulad 最為輕量，其他依次為balena-engine、Containerd和Docker，前三者相對(duì)較為輕量，在尺寸上基本滿足在終端設(shè)備上運(yùn)行的需求。從運(yùn)行占用內(nèi)存方面比較，Containerd 整體來(lái)說(shuō)占用內(nèi)存最少，40 MB 左右的內(nèi)存占用可以保留足夠多的內(nèi)存來(lái)保證容器內(nèi)業(yè)務(wù)應(yīng)用的運(yùn)行，對(duì)于終端設(shè)備來(lái)說(shuō)是在可以接受的范圍之內(nèi)的。從容器生命周期耗時(shí)比較來(lái)看，Containerd 和isulad 整體優(yōu)于其他兩種種容器引擎，但在容器啟動(dòng)時(shí)間上Containerd 更具優(yōu)勢(shì)；從容器生命周期的CPU 使用率和磁盤I/O 占用方面比較，isulad 和Containerd 相對(duì)來(lái)說(shuō)更符合容器輕量化的要求。整體來(lái)說(shuō)除了Docker 外，其他3 種容器引擎方案均在一定程度上滿足了終端對(duì)于容器引擎輕量化的需求。

6 總結(jié)與展望

隨著容器技術(shù)的發(fā)展，Docker 容器引擎的地位受到眾多后起之秀的挑戰(zhàn)，不久前，Kubernetes 官方發(fā)布公告宣布自v1.20 起放棄對(duì)Docker 的支持，屆時(shí)用戶將收到Docker 棄用警告，并需要改用其他容器運(yùn)行時(shí)。而得到CNCF 官方推薦并作為內(nèi)置模塊集成進(jìn)Kubernetes 的Containerd 將在容器引擎領(lǐng)域得到良好的發(fā)展。在特定的應(yīng)用場(chǎng)景下，Docker 等主流容器引擎顯得力不從心，因此一些針對(duì)某種用例進(jìn)行過(guò)專門優(yōu)化的容器引擎技術(shù)紛紛入場(chǎng)。本文以終端作為容器的硬件載體，以可用于終端的輕量化容器引擎為出發(fā)點(diǎn)，對(duì)目前業(yè)界的4 種主流容器引擎進(jìn)行研究評(píng)測(cè)。

Docker 作為廣泛應(yīng)用于云端的成熟容器解決方案來(lái)說(shuō)，對(duì)于終端并不適用。業(yè)界有通過(guò)嘗試裁剪Docker 以實(shí)現(xiàn)容器的輕量化方案，對(duì)Docker 進(jìn)行輕量化改造，對(duì)其裁剪和精簡(jiǎn)化、去除不需要的功能、優(yōu)化組件結(jié)構(gòu)等，甚至還對(duì)Go 語(yǔ)言環(huán)境的編譯進(jìn)行了優(yōu)化。但是，由于Docker 本身體積比較大，且由于要運(yùn)行在端側(cè)的嵌入式設(shè)備上，這種裁剪和壓榨資源的做法所能取得的效果很有限。

iSulad 作為華為OpenEuler 開(kāi)源系統(tǒng)上的全量的容器軟件棧其中的輕量化容器引擎，目前還處于項(xiàng)目的起步階段，雖然在對(duì)比測(cè)試中的各項(xiàng)性能指標(biāo)相對(duì)其他容器引擎有一定優(yōu)勢(shì)，但目前和業(yè)界的相關(guān)合作并不是很多，還沒(méi)有得到充分的應(yīng)用和驗(yàn)證。

balenaEngine 雖然比Docker 輕量很多，但在實(shí)際架構(gòu)設(shè)計(jì)上依然延續(xù)Docker 的思路，從本次測(cè)試的結(jié)果也可以看出，在很多測(cè)試指標(biāo)上都與Docker 較為接近，目前看來(lái)其在容器引擎這條賽道上很難脫穎而出。

Containerd 在容器引擎的測(cè)試對(duì)比中表現(xiàn)比較優(yōu)秀，并且作為CNCF 官方推薦，在開(kāi)源社區(qū)獲得了廣泛的關(guān)注，其在整個(gè)容器生態(tài)鏈中的影響力也在不斷提高。另外，Containerd 系統(tǒng)架構(gòu)的插件機(jī)制決定了它可以很靈活地裁剪體積和拓展功能，對(duì)于其在各式各樣終端設(shè)備上的應(yīng)用增添了可行性。

5G 的全面普及，推進(jìn)了“萬(wàn)物互聯(lián)”時(shí)代的到來(lái)，在這個(gè)智能終端之間保持隨時(shí)隨地的連接互通的泛連接時(shí)代，終端形態(tài)也逐漸的擴(kuò)展和變化，泛智能終端設(shè)備必將從單設(shè)備、多設(shè)備逐漸走向跨平臺(tái)、分布式。在這樣的趨勢(shì)下，終端容器技術(shù)將向著，輕量化、異構(gòu)化、模塊化的方向發(fā)展，助力端邊云網(wǎng)一體化合力構(gòu)建的全場(chǎng)景生態(tài)和服務(wù)。