［林園致 楊新章 何震葦 嚴(yán)麗云 黃丹池］

1 引言

容器技術(shù)作為一種輕量級(jí)的資源提供技術(shù)因其輕量、彈性伸縮、快速部署、可移植等優(yōu)勢(shì)，大大推動(dòng)和簡(jiǎn)化了軟件的開(kāi)發(fā)、部署和運(yùn)營(yíng)，受到各大互聯(lián)網(wǎng)企業(yè)廣泛青睞與應(yīng)用。然而，隨著容器技術(shù)的發(fā)展與普及，人們?cè)谑褂眠^(guò)程中發(fā)現(xiàn)傳統(tǒng)容器技術(shù)Docker所帶來(lái)安全問(wèn)題不容忽視。相對(duì)于當(dāng)前成熟的虛擬機(jī)（VM）技術(shù)，Docker的安全隔離徹底性遠(yuǎn)遠(yuǎn)不如VM。

針對(duì)傳統(tǒng)容器技術(shù)Docker的隔離不徹底而帶來(lái)的安全性挑戰(zhàn)，以及借鑒Docker容器技術(shù)中鏡像管理的思想，于是有人提出了融合虛擬化技術(shù)的容器思想，帶來(lái)了如Kata、gVisor等提升容器安全性的容器技術(shù)演進(jìn)方案。目標(biāo)是讓用戶充分享受容器技術(shù)帶來(lái)的輕量級(jí)快速部署能力的同時(shí)，擁有如虛擬機(jī)技術(shù)般的隔離徹底性，提供一種安全容器。區(qū)別于傳統(tǒng)容器Docker，我們稱這類新型安全加固的容器技術(shù)演進(jìn)方案為Hyper容器。

本文主要梳理與分析了業(yè)界主流的Hyper容器技術(shù)方案，并對(duì)明星項(xiàng)目Kata容器技術(shù)展開(kāi)了技術(shù)分析，針對(duì)運(yùn)營(yíng)商基于SDN及NFV技術(shù)全面云化的需求，初步探討了Kata容器在電信行業(yè)的發(fā)展前景，助力加速電信云化進(jìn)程。

2 主流Hyper容器技術(shù)對(duì)比

目前業(yè)界主流的Hyper容器技術(shù)的理念都是在引入獨(dú)立內(nèi)核增加安全性的前提下兼容現(xiàn)有的容器標(biāo)準(zhǔn)，基于獨(dú)立內(nèi)核的技術(shù)方案主要分為3種：微虛機(jī)容器、模擬內(nèi)核容器、庫(kù)系統(tǒng)容器。微虛機(jī)容器是基于經(jīng)過(guò)定制化裁剪的微型虛機(jī)承載容器進(jìn)程實(shí)現(xiàn)容器間內(nèi)核級(jí)隔離，模擬內(nèi)核容器是基于用戶態(tài)內(nèi)核攔截并實(shí)現(xiàn)容器進(jìn)程的系統(tǒng)調(diào)用從而避免容器直接訪問(wèn)宿主機(jī)內(nèi)核從而增加安全性，庫(kù)系統(tǒng)容器是基于Unikernel/LibraryOS方案減少容器進(jìn)程對(duì)宿主機(jī)的攻擊面，它們之間的架構(gòu)對(duì)比如圖1所示。

圖1 三種Hyper容器技術(shù)方案對(duì)比

2.1 微虛機(jī)容器技術(shù)方案

微虛機(jī)容器技術(shù)方案主要特點(diǎn)在于創(chuàng)建的容器不在主機(jī)內(nèi)核上運(yùn)行，而是為每個(gè)容器創(chuàng)建輕量虛擬機(jī)，每個(gè)容器獨(dú)占私有的虛擬內(nèi)核（如圖2所示），在輕量級(jí)虛機(jī)上運(yùn)行容器鏡像，使不同用戶、不同應(yīng)用之間都均有獨(dú)占的虛擬機(jī)來(lái)隔離容器，不會(huì)共享宿主機(jī)的同一操作內(nèi)核，從而提升不同用戶、應(yīng)用間的安全隔離性。這種容器相對(duì)于傳統(tǒng)虛擬機(jī)開(kāi)銷更小，啟動(dòng)更快；相對(duì)于傳統(tǒng)Docker容器更加安全。其中，Kata容器是基于微虛機(jī)容器方案的熱門(mén)項(xiàng)目。

圖2 微虛機(jī)容器架構(gòu)

2.2 模擬內(nèi)核容器技術(shù)方案

模擬內(nèi)核容器技術(shù)方案實(shí)現(xiàn)容器安全隔離的原理是通過(guò)實(shí)現(xiàn)一個(gè)模擬內(nèi)核，截獲應(yīng)用程序發(fā)出的系統(tǒng)調(diào)用，由模擬內(nèi)核間接實(shí)現(xiàn)大多數(shù)的系統(tǒng)調(diào)用，使應(yīng)用程序不能直接訪問(wèn)宿主機(jī)內(nèi)核及系統(tǒng)資源，提升隔離性。并通過(guò)使用Linux Seccomp機(jī)制對(duì)模擬系統(tǒng)對(duì)宿主機(jī)的系統(tǒng)調(diào)用進(jìn)行過(guò)濾，提升安全性。

其中g(shù)Visor項(xiàng)目是基于模擬內(nèi)核方案的典型代表。gVisor是Google發(fā)布的一款新型的沙箱容器運(yùn)行時(shí)，號(hào)稱能夠?yàn)槿萜魈峁└踩母綦x，同時(shí)比VM更輕量，避免了由于搭建傳統(tǒng)的Hypervisor而帶來(lái)的額外內(nèi)存開(kāi)銷。總體而言，gVisor遵循OCI標(biāo)準(zhǔn)，可以和Docker很好的集成，但和Kubernetes的集成還處于實(shí)驗(yàn)階段。

就目前發(fā)展來(lái)看，在兼容性上，gVisor的模擬內(nèi)核Sentry目前實(shí)現(xiàn)了Linux Kernel（4.16版本）約2/3的系統(tǒng)調(diào)用，因此當(dāng)部分應(yīng)用需要調(diào)用那些未被實(shí)現(xiàn)的系統(tǒng)調(diào)用時(shí)，就不能無(wú)縫地運(yùn)行在gVisor中，對(duì)應(yīng)用程序的兼容性比較差。在性能方面，Sentry對(duì)Host內(nèi)核的依賴，與劫持應(yīng)用系統(tǒng)調(diào)用的低效是gVisor存在性能缺陷的主要原因；在網(wǎng)絡(luò)性能上，gVisor的網(wǎng)絡(luò)速率并且明顯低于runC；在IO性能上，gVisor的平均時(shí)延也明顯比runC要大十幾倍。

綜上所述，模擬內(nèi)核容器技術(shù)方案往往是通過(guò)犧牲性能換來(lái)進(jìn)程級(jí)的安全隔離，同時(shí)其進(jìn)程虛擬化方案又比傳統(tǒng)VM要輕量化。對(duì)系統(tǒng)調(diào)用繁重的或?qū)π阅苡休^高要求的應(yīng)用則無(wú)法應(yīng)用在gVisor上面。

2.3 庫(kù)系統(tǒng)容器技術(shù)方案

針對(duì)提升容器隔離性的問(wèn)題，利用現(xiàn)有項(xiàng)目Unikernel的特點(diǎn)：hypercall范圍非常小、可以模擬系統(tǒng)調(diào)用，提出了Unikernel進(jìn)程化的想法，即把應(yīng)用程序Unikernel化并以進(jìn)程的形式在特定的虛擬機(jī)系統(tǒng)中運(yùn)行，形成了庫(kù)系統(tǒng)容器技術(shù)方案。

其中由IBM提出的Nabla項(xiàng)目是基于庫(kù)系統(tǒng)容器技術(shù)方案的代表項(xiàng)目。Nabla容器利用Unikernel技術(shù)，基于開(kāi)源Solo5項(xiàng)目開(kāi)發(fā)了面向Unikernel的Nabla Tender來(lái)代替通用的VMM，Nabla Tender會(huì)攔截Unikernel發(fā)送的Hypercall，并翻譯為少量的系統(tǒng)調(diào)用，對(duì)比傳統(tǒng)Docker容器與內(nèi)核交互需要用到的300多個(gè)系統(tǒng)調(diào)用，Nabla宣稱能減少到僅使用7個(gè)，其他所有調(diào)用均被Linux seccomp機(jī)制阻止，從而減少系統(tǒng)調(diào)用顯著提高安全性。Unikernel和Nabla Tender以用戶態(tài)進(jìn)程的形式在宿主機(jī)上運(yùn)行。

在兼容性方面，Nabla提供了符合OCI運(yùn)行時(shí)標(biāo)準(zhǔn)的Nabla運(yùn)行時(shí)runnc，支持與Docker和Kubernetes集成，但由于Unikernel和傳統(tǒng)容器的文件系統(tǒng)之間存在差異，Nabla沒(méi)有遵循OCI的鏡像標(biāo)準(zhǔn)，因此無(wú)法兼容傳統(tǒng)的Docker鏡像，為此Nabla還提供了一個(gè)鏡像構(gòu)建器，用于創(chuàng)建能夠使用runnc運(yùn)行的Unikernel鏡像。目前這個(gè)項(xiàng)目目前仍在早期試驗(yàn)階段，且社區(qū)討論熱度較低，但I(xiàn)BM研究院在項(xiàng)目成立之初所提出的Horizontal Attack Profile（HAP）方法為度量容器安全性以及提升容器安全性提供了一種新的思路。

2.4 主流容器技術(shù)演進(jìn)方案技術(shù)對(duì)比

微虛機(jī)容器方案有機(jī)的把虛機(jī)技術(shù)與容器技術(shù)融合到一起，在較少的性能損耗下為容器提供虛機(jī)級(jí)的安全隔離；模擬內(nèi)核容器方案通過(guò)模擬內(nèi)核實(shí)現(xiàn)應(yīng)用大多數(shù)的系統(tǒng)調(diào)用從而減少應(yīng)用對(duì)主機(jī)內(nèi)核的直接調(diào)用，利用Sentry作為緩沖隔離帶減少攻擊風(fēng)險(xiǎn)；庫(kù)系統(tǒng)容器方案則利用Unikernel進(jìn)程化減少應(yīng)用的系統(tǒng)調(diào)用降低攻擊面從而提高安全性。這些方案各有優(yōu)劣，表1中展示了三者在各方面的對(duì)比：

表1 微虛機(jī)容器、模擬內(nèi)核容器、庫(kù)系統(tǒng)容器三種Hyper容器技術(shù)綜合性對(duì)比

就三者目前發(fā)展情況來(lái)看，綜合平臺(tái)兼容性、應(yīng)用程序兼容性、安全性、易用性、性能等各方面，微虛機(jī)容器方案是三者中開(kāi)源項(xiàng)目最多、適用場(chǎng)景最廣的安全容器方案，而Kata容器是微虛機(jī)容器方案中的明星項(xiàng)目，項(xiàng)目發(fā)展前景開(kāi)闊，社區(qū)對(duì)項(xiàng)目未來(lái)的演進(jìn)方向也比較明確，是十分具有研究?jī)r(jià)值的Hyper容器方案。

Kata容器是Intel在2015年啟動(dòng)了它們以虛擬機(jī)為基礎(chǔ)的容器技術(shù)，Clear Container，后續(xù)加入了Hyper RunV從而形成了Kata項(xiàng)目。在功能上，Kata容器的微虛機(jī)容器方案使用戶同時(shí)擁有虛擬機(jī)的安全和容器技術(shù)的敏捷和易管理性，具有強(qiáng)隔離、輕量級(jí)以及快速啟動(dòng)能力。

在兼容性方面，Kata容器既支持容器OCI接口，單虛擬機(jī)單容器模式；也支持Kubernetes CRI接口，單虛擬機(jī)多容器模式；還支持標(biāo)準(zhǔn)鏡像格式。同時(shí)，利用OpenStack Keystone的多租戶和Neutron網(wǎng)絡(luò)隔離能力，能帶給容器生態(tài)更好的多租戶隔離及更好的安全性。

在影響力上，Kata項(xiàng)目由OpenStack基金會(huì)（OSF）托管，創(chuàng)始會(huì)員公司包括Intel、Google、國(guó)內(nèi)的EasyStack、華為等。設(shè)計(jì)初衷強(qiáng)調(diào)了能夠無(wú)縫、便捷的與OpenStack和Kubernetes集成的能力，支撐OpenStack、Kubernetes和Container實(shí)現(xiàn)更好的融合。在公有云服務(wù)領(lǐng)域，如華為CCI、百度AI云及容器服務(wù)，以及互聯(lián)網(wǎng)金融領(lǐng)域如阿里螞蟻金服均有商用案例。

3 Kata容器技術(shù)分析

下面我們針對(duì)Kata容器技術(shù)來(lái)進(jìn)行比較詳細(xì)的分析。

3.1 Kata核心組件分析

最初提出的Kata容器項(xiàng)目v1版本由5個(gè)核心組件Shim、Runtime、Proxy、Agent組成，在v1.6版本后對(duì)核心組件做了改造，簡(jiǎn)化組件并整合成kata shim v2，由最初的單容器對(duì)應(yīng)單個(gè)shim方案簡(jiǎn)化為單Pod實(shí)例對(duì)應(yīng)單個(gè)shim。圖3展示了Kata容器項(xiàng)目各組件間的關(guān)系：

圖3 Kata容器架構(gòu)中各組件間的關(guān)系

（1）Runtime

組件Runtime是Kata Containers運(yùn)行時(shí)，負(fù)責(zé)處理OCI runtime的所有命令并啟動(dòng)kata-shim實(shí)例。它大量利用virtcontainers軟件包，該軟件包提供了一套通用，與運(yùn)行時(shí)規(guī)范無(wú)關(guān)，硬件虛擬化的容器庫(kù)，負(fù)責(zé)創(chuàng)建在Linux主機(jī)上運(yùn)行的硬件虛擬化Linux容器。該運(yùn)行時(shí)與OCI兼容，CRI-O以及Containerd兼容，從而使其可以分別與Docker和Kubernetes無(wú)縫地工作。安裝kata runtime時(shí)可在路徑/usr/share/defaults/kata-containers/configuration.toml配置文件中定義hypervisor路徑、guest kernel以及mini-OS映像。

（2）Agent

Agent是運(yùn)行在微虛機(jī)中的一個(gè)運(yùn)行時(shí)代理組件，負(fù)責(zé)虛機(jī)內(nèi)的容器及容器內(nèi)部進(jìn)程的生命周期管理，替運(yùn)行在宿主機(jī)上的runtime實(shí)際管理運(yùn)行在虛機(jī)上的容器環(huán)境。Agent的最小執(zhí)行單元是sandbox，一個(gè)sandbox對(duì)應(yīng)一系列的命名空間（NS，UTS，IPC，PID）。Kata容器支持一個(gè)虛機(jī)內(nèi)運(yùn)行多個(gè)容器，由agent管理一個(gè)虛機(jī)內(nèi)的多個(gè)容器及內(nèi)部進(jìn)程。Agent重用了許多runC代碼，利用libcontainer管理容器生命周期，并通過(guò)gRPC協(xié)議實(shí)現(xiàn)與其他Kata組件的通信。

（3）Proxy

組件Proxy負(fù)責(zé)Kata容器代理服務(wù)，代理agent與shim、runtime之間的通信，負(fù)責(zé)路由shim到對(duì)應(yīng)的agent。默認(rèn)由virtio-serial技術(shù)實(shí)現(xiàn)通信，kernel版本v4.8以上支持vsock技術(shù)，virtio-serial技術(shù)需要proxy以多路分流的方式對(duì)多個(gè)容器進(jìn)程通信，而利用Vsock技術(shù)通信時(shí)則不需要多路分流。

（4）Shim

組件shim在主機(jī)環(huán)境中運(yùn)行，替實(shí)際運(yùn)行在虛機(jī)里的容器處理std I / O及信號(hào)。shim可以將上層Containerd-shim發(fā)來(lái)的數(shù)據(jù)流（如stdin）經(jīng)由proxy轉(zhuǎn)交給agent執(zhí)行，也可以將agent經(jīng)由proxy發(fā)過(guò)來(lái)的數(shù)據(jù)流（stdout/stderr）及信號(hào)傳給上層Containerd-shim。它主要負(fù)責(zé)在虛機(jī)外部監(jiān)控以及終止容器。

由圖3可以看出，shim V1架構(gòu)存在一定問(wèn)題，本質(zhì)主要是由于Containerd在構(gòu)建容器過(guò)程中Containerdshim與單個(gè)容器必須一對(duì)一綁定的問(wèn)題，這在Kubernetes中單個(gè)Pod承載多容器場(chǎng)景中顯得十分的冗余且占用資源。因此Kata在v1.6版本后定制了shim V2，替換掉原來(lái)的Containerd-shim，不但做到支持一個(gè)shim對(duì)應(yīng)一個(gè)pod內(nèi)的多個(gè)容器，而且不再需要為Containerd-shim實(shí)現(xiàn)兼容runC的CL。使shim V1版本中單個(gè)shim管理單個(gè)容器的生命周期升級(jí)為shimV2版本中單個(gè)shim管理一個(gè)Pod的生命周期，更符合Kubernetes中以Pod為最小執(zhí)行單位的理念。

3.2 Kata增強(qiáng)特性分析

如上所述，Kata容器是基于微虛機(jī)容器技術(shù)方案增強(qiáng)容器安全性，對(duì)比同樣基于微虛機(jī)容器技術(shù)方案中別的開(kāi)源項(xiàng)目，Kata容器優(yōu)勢(shì)在于其對(duì)Hypervisor、內(nèi)核/鏡像和加速虛機(jī)與宿主機(jī)間的通信上做的優(yōu)化，使其能提供媲美Docker的輕和快的用戶體驗(yàn)。

在Hypervisor方面，Kata容器除了默認(rèn)使用主流的QEMU/KVM外還支持多種Hypervisor。并對(duì)通用QEMU/KVM進(jìn)行了裁剪優(yōu)化，定制qemu-lite版本大大縮減了虛機(jī)啟動(dòng)時(shí)長(zhǎng)以及內(nèi)存占用率。

在虛機(jī)內(nèi)核及虛機(jī)鏡像方面，Kata容器為微虛機(jī)定制了僅提供容器工作負(fù)載所需服務(wù)的最小化內(nèi)核，以及僅包含systemd和Kata-agent兩個(gè)啟動(dòng)容器必須的服務(wù)的高度優(yōu)化的最小操作系統(tǒng)鏡像。進(jìn)一步優(yōu)化內(nèi)核啟動(dòng)時(shí)間以及最小化內(nèi)存占用空間。

在加速虛機(jī)與宿主機(jī)間的通信方面，通過(guò)PCI Passthrough技術(shù)使虛機(jī)能直接訪問(wèn)宿主機(jī)PCI網(wǎng)卡，獲得接近本地的網(wǎng)絡(luò)性能；通過(guò)SR-IOV技術(shù)使宿主機(jī)上的PCIe設(shè)備在虛機(jī)看來(lái)像是多個(gè)單獨(dú)的虛擬PCIe設(shè)備；實(shí)現(xiàn)Virtio接口，允許虛機(jī)訪問(wèn)簡(jiǎn)化過(guò)的塊設(shè)備，網(wǎng)絡(luò)適配器及console接口等“虛擬”設(shè)備。為提升虛機(jī)性能以接近物理機(jī)做了高度優(yōu)化。

3.3 Kata容器業(yè)界應(yīng)用情況

Kata容器項(xiàng)目自開(kāi)源以來(lái)，就廣受社區(qū)用戶關(guān)注，并吸引了不少大廠尋求合作甚至貢獻(xiàn)代碼，共同推進(jìn)Kata項(xiàng)目與上游社區(qū)及下層基礎(chǔ)設(shè)施實(shí)現(xiàn)更好的融合。

在公有云服務(wù)領(lǐng)域，阿里云容器服務(wù)在社區(qū)Kata容器基礎(chǔ)上，定制優(yōu)化部分組件增強(qiáng)了安全容器的性能及穩(wěn)定性，并結(jié)合自有容器產(chǎn)品提供安全容器的監(jiān)控告警功能，對(duì)外提供安全沙箱服務(wù)。

華為作為Kata容器項(xiàng)目的初創(chuàng)成員之一，擁有Kata項(xiàng)目架構(gòu)委員會(huì)五席位之一和三位maintainer，代碼貢獻(xiàn)量穩(wěn)居全球排名前四，華為云將Kata容器集成到自研iSula容器平臺(tái)，并推出華為云容器實(shí)例CCI對(duì)外服務(wù)，正是得益于Kata容器，使之前一直困擾用戶的容器安全問(wèn)題迎刃而解。

百度智能云在容器實(shí)例BCI產(chǎn)品中將Kata容器與自有存儲(chǔ)和網(wǎng)絡(luò)無(wú)縫集成，并在基于Kata容器開(kāi)發(fā)的產(chǎn)品中融合多種開(kāi)源技術(shù)。基于Kata Containers，百度智能云能在多個(gè)云計(jì)算場(chǎng)景下提供超高的性能，并保障數(shù)據(jù)的安全性和算法的機(jī)密性。

隨著Kata項(xiàng)目創(chuàng)始人趙鵬、王旭加入螞蟻金服，Kata容器也嘗試著應(yīng)用到更多的業(yè)務(wù)領(lǐng)域中。在互聯(lián)網(wǎng)金融領(lǐng)域，Kata容器的安全性特征貼合金融行業(yè)的高安全標(biāo)準(zhǔn)需求，創(chuàng)始人王旭也致力于將Kata等安全容器技術(shù)落地到金融級(jí)云原生的場(chǎng)景下，推動(dòng)金融服務(wù)往云原生方向發(fā)展。螞蟻金服和阿里云與開(kāi)源社區(qū)的緊密合作，為社區(qū)提供更多安全容器及云服務(wù)在不同領(lǐng)域的最佳實(shí)踐，并持續(xù)將各項(xiàng)通用性技術(shù)改進(jìn)和優(yōu)化貢獻(xiàn)給Kata社區(qū)。

4 小結(jié)與展望

Kata容器技術(shù)目前仍處于發(fā)展初期，且近年來(lái)熱度持續(xù)升高，運(yùn)營(yíng)商介入并開(kāi)展相關(guān)研發(fā)應(yīng)用工作恰逢其時(shí)，其輕量級(jí)高度隔離的虛機(jī)容器方案將有助于解決當(dāng)前云計(jì)算發(fā)展過(guò)程中的諸多難題。未來(lái)在NFV容器化場(chǎng)景下滿足多廠家多租戶場(chǎng)景及電信級(jí)安全需求；邊緣云場(chǎng)景下為分散的異構(gòu)資源容器化成提供標(biāo)準(zhǔn)服務(wù)能力的安全容器，并保障邊緣服務(wù)和數(shù)據(jù)的安全需求，Kata容器技術(shù)特點(diǎn)能有效的對(duì)其提供技術(shù)支持。為了滿足這些場(chǎng)景需求，運(yùn)營(yíng)商仍需投入對(duì)Kata容器技術(shù)的技術(shù)驗(yàn)證及性能驗(yàn)證，并在Kata容器技術(shù)研究基礎(chǔ)上探索其集成DPDK、GPU等硬件加速技術(shù)的方案，實(shí)現(xiàn)安全容器的電信級(jí)高帶寬低時(shí)延需求。運(yùn)營(yíng)商需在安全容器方面積極探索，提升自身的研發(fā)能力與整體運(yùn)維水平，不斷跟進(jìn)Kata等安全容器項(xiàng)目的演進(jìn)并探討運(yùn)營(yíng)商網(wǎng)絡(luò)引入安全容器的可能性及利弊，推進(jìn)云網(wǎng)融合和網(wǎng)絡(luò)重構(gòu)工作的開(kāi)展。