如何分析Kata容器的I/O性能

這篇文章給大家介紹如何分析Kata容器的I/O性能，內(nèi)容非常詳細(xì)，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

下面的所有分析是基于Kata容器1.6.2版本，我們將探討這個主題，以了解在I/O綁定性能和安全性都是關(guān)鍵需求的環(huán)境中使用此技術(shù)的利弊。

什么是Kata容器?

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

為Kata配置Kubernetes

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

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

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

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

• Kata將只在配置為支持嵌套虛擬化的計算機(jī)上運行。

• Kata至少需要一個Westmere處理器架構(gòu)。

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

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

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

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

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é)果中，我們繪制了所有客戶端上的總帶寬，展示了單個客戶端可以實現(xiàn)的向上擴(kuò)展帶寬以及許多客戶端上實現(xiàn)的向外擴(kuò)展吞吐量。

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

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

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

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

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

展望未來

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

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

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

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

關(guān)于如何分析Kata容器的I/O性能就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。