本文的所有分析是基于Kata容器1.6.2版本。

[[329552]]

在參加了2019年倫敦OpenInfra Days的Kata容器研討會(huì)之后，我們對(duì)它們的啟動(dòng)時(shí)間印象比較深刻，與Kubernetes集群中的普通runC容器相比僅稍慢一些。我們自然而然的對(duì)它們的磁盤I/O綁定性能以及它們是否也符性能要求感到好奇。在本文中，我們將探討這個(gè)主題，以了解在I/O綁定性能和安全性都是關(guān)鍵需求的環(huán)境中使用此技術(shù)的利弊。

什么是Kata容器?

Kata容器是輕量級(jí)vm，旨在與Docker和Kubernetes等容器編排軟件無(wú)縫集成。設(shè)想的一個(gè)用例是運(yùn)行不受信任的工作負(fù)載，利用不與主機(jī)共享操作系統(tǒng)內(nèi)核所獲得的額外隔離。然而，在最近一次對(duì)虛擬機(jī)和容器的調(diào)查中，使用宿主機(jī)內(nèi)核導(dǎo)致額外安全性這一毫無(wú)疑問(wèn)的假設(shè)受到了挑戰(zhàn)。Kata源于Intel Clear Containers和Hyper runV技術(shù)。gVisor的目標(biāo)是通過(guò)過(guò)濾和重定向系統(tǒng)調(diào)用到單獨(dú)的用戶空間內(nèi)核來(lái)解決類似的問(wèn)題。因此，gVisor會(huì)受到運(yùn)行時(shí)性能損失。關(guān)于gVisor的進(jìn)一步討論超出了本博客的范圍。

為Kata配置Kubernetes

Kata容器符合OCI，這意味著支持外部運(yùn)行時(shí)類的容器運(yùn)行時(shí)接口(CRI)可以使用Kata來(lái)運(yùn)行工作負(fù)載。這些CRI的例子目前包括CRI-O和containerd，它們都默認(rèn)使用runC，但這可以替換為kata qemu運(yùn)行。從Kubernetes 1.14+開始，RuntimeClass特性標(biāo)志已升級(jí)到beta，因此默認(rèn)啟用。因此，設(shè)置相對(duì)簡(jiǎn)單。

目前Kata支持qemu和firecracker hypervisor后端，但對(duì)后者的支持被認(rèn)為是初步的，特別是缺乏主機(jī)到客戶的文件共享。這讓我們將kata qemu作為當(dāng)前的選項(xiàng)，其中virtio-9p提供了基本的共享文件系統(tǒng)功能，這對(duì)分析至關(guān)重要(測(cè)試路徑是安裝在主機(jī)上的網(wǎng)絡(luò)文件系統(tǒng))。

沒有這些先決條件，Kata啟動(dòng)將無(wú)聲地失敗(我們很難學(xué)到了這一點(diǎn))。

這個(gè)示例要點(diǎn)展示了如何在Minikube集群中將runC替換為Kata運(yùn)行時(shí)。注意，在編寫本文時(shí)，Kata容器有額外的主機(jī)要求：

• Kata將只在配置為支持嵌套虛擬化的計(jì)算機(jī)上運(yùn)行。
• Kata至少需要一個(gè)Westmere處理器架構(gòu)。

如果沒有這些先決條件，Kata的將悄無(wú)聲息地失敗(我們是從多次實(shí)踐中得到的)。

為了進(jìn)行此分析，部署了一個(gè)裸機(jī)Kubernetes集群，使用OpenStack Heat通過(guò)我們的appliances playbooks配置機(jī)器，并使用Kubespray將它們配置為Kubernetes集群。Kubespray支持除Docker之外的其他容器運(yùn)行時(shí)規(guī)范，例如CRI-O和 containerd，這是支持Kata運(yùn)行時(shí)所必需的。

設(shè)計(jì)I/O性能測(cè)試方案

為了對(duì)Kata容器的I/O性能進(jìn)行基準(zhǔn)測(cè)試，我們?cè)诼銠C(jī)和runC容器的情況下提出了等效的場(chǎng)景來(lái)進(jìn)行比較。在所有情況下，我們都使用fio(3.1版)作為I/O基準(zhǔn)測(cè)試工具，調(diào)用方式如下，其中$SCRATCH_DIR是安裝在主機(jī)上的BeeGFS(本節(jié)稍后將詳細(xì)介紹)網(wǎng)絡(luò)存儲(chǔ)的路徑：

fio fio_jobfile.fio --fallocate=none --runtime=30 --directory=$SCRATCH_DIR --output-format=json+ --blocksize=65536 --output=65536.json 

該fio_jobfile.fio上述引用的文件內(nèi)容如下：

[global] 
; Parameters common to all test environments 
; Ensure that jobs run for a specified time limit, not I/O quantity 
time_based=1 
; To model application load at greater scale, each test client will maintain 
; a number of concurrent I/Os. 
ioengine=libaio 
iodepth=8 
; Note: these two settings are mutually exclusive 
; (and may not apply for Windows test clients) 
direct=1 
buffered=0 
; Set a number of workers on this client 
thread=0 
numjobs=4 
group_reporting=1 
; Each file for each job thread is this size 
filesize=32g 
size=32g 
filename_format=$jobnum.dat 
[fio-job] 
; FIO_RW is read, write, randread or randwrite 
rw=${FIO_RW} 

為I/O性能研究探索的參數(shù)空間涵蓋了36種方案、客戶機(jī)數(shù)量和磁盤I/O模式的組合。

結(jié)果

磁盤I/O吞吐量

在這些結(jié)果中，我們繪制了所有客戶端上的總帶寬，展示了單個(gè)客戶端可以實(shí)現(xiàn)的向上擴(kuò)展帶寬以及許多客戶端上實(shí)現(xiàn)的向外擴(kuò)展吞吐量。

裸機(jī)，runC和Kata之間的磁盤I/O帶寬比較。在所有情況下，使用runC容器實(shí)現(xiàn)的帶寬都略低于裸機(jī)。但是，Kata容器的性能通常要差得多，當(dāng)有64個(gè)客戶端時(shí)，其獲得的裸機(jī)讀取帶寬大約為15%，隨機(jī)寫入帶寬的比例要小得多。唯一的例外是使用64個(gè)客戶端的順序?qū)懭肭闆r，其中Kata容器的性能好于裸機(jī)方案約25%。

提交延遲累積分布函數(shù)(CDF)

在對(duì)延遲敏感的工作負(fù)載中，I/O延遲可能占主導(dǎo)地位。I/O操作提交延遲按對(duì)數(shù)比例繪制，以適應(yīng)非常廣泛的數(shù)據(jù)點(diǎn)。

分別針對(duì)1、8和64個(gè)客戶端的裸機(jī)，runC和Kata容器環(huán)境之間的提交延遲CDF的比較。與將它們作為runC容器運(yùn)行相比，在裸機(jī)中運(yùn)行fio作業(yè)之間存在微小差異。但是，將裸機(jī)與Kata容器進(jìn)行比較，在所有情況下的開銷都非常大。

該表總結(jié)了與之前顯示的數(shù)字相對(duì)應(yīng)的50%和99%的提交延遲(以μs為單位)。*

展望未來(lái)

在這種I/O密集型方案中，Kata容器尚未達(dá)到傳統(tǒng)容器的性能。

從結(jié)果可以明顯看出，在裸機(jī)、runC容器和Kata容器之間進(jìn)行選擇時(shí)，需要權(quán)衡取舍。盡管runC容器為大多數(shù)用例提供了更完善的考量，但它們?nèi)匀皇怪鳈C(jī)內(nèi)核易于受到系統(tǒng)調(diào)用接口作為攻擊面的利用。Kata容器提供了硬件支持的隔離，但是目前存在巨大的性能開銷，尤其是對(duì)于磁盤I/O綁定操作。

Kata的發(fā)展路線圖和發(fā)展速度擁有堅(jiān)實(shí)的基礎(chǔ)以及樂(lè)觀的前景。Kata團(tuán)隊(duì)已經(jīng)意識(shí)到使用virtio-9p作為存儲(chǔ)驅(qū)動(dòng)程序在主機(jī)和來(lái)賓VM之間共享路徑的性能缺陷。

Kata版本1.7(將于2019年5月15日發(fā)布)預(yù)計(jì)將附帶virtio fs的實(shí)驗(yàn)支持，該版本有望改善I/O性能問(wèn)題。初步結(jié)果令人鼓舞，其他已發(fā)布的基準(zhǔn)測(cè)試報(bào)告顯示，virtio fs驅(qū)動(dòng)程序的磁盤I/O帶寬比virtio-9p提高了2到8倍。當(dāng)新功能可用時(shí)，我們將重復(fù)我們的測(cè)試以及分析。

原文： https://www.stackhpc.com/kata-io-1.html