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

[[329552]]

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

什么是Kata容器?

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

為Kata配置Kubernetes

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

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

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

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

• Kata將只在配置為支持嵌套虛擬化的計算機上運行。
• Kata至少需要一個Westmere處理器架構。

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

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

設計I/O性能測試方案

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

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

該fio_jobfile.fio上述引用的文件內容如下：

[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性能研究探索的參數空間涵蓋了36種方案、客戶機數量和磁盤I/O模式的組合。

結果

磁盤I/O吞吐量

在這些結果中，我們繪制了所有客戶端上的總帶寬，展示了單個客戶端可以實現的向上擴展帶寬以及許多客戶端上實現的向外擴展吞吐量。

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

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

在對延遲敏感的工作負載中，I/O延遲可能占主導地位。I/O操作提交延遲按對數比例繪制，以適應非常廣泛的數據點。

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

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

展望未來

在這種I/O密集型方案中，Kata容器尚未達到傳統容器的性能。

從結果可以明顯看出，在裸機、runC容器和Kata容器之間進行選擇時，需要權衡取舍。盡管runC容器為大多數用例提供了更完善的考量，但它們仍然使主機內核易于受到系統調用接口作為攻擊面的利用。Kata容器提供了硬件支持的隔離，但是目前存在巨大的性能開銷，尤其是對于磁盤I/O綁定操作。

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

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

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