共計 3547 個字符，預計需要花費 9 分鐘才能閱讀完成。
這篇文章給大家介紹如何分析 Kata 容器的 I / O 性能，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。
下面的所有分析是基于 Kata 容器 1.6.2 版本，我們將探討這個主題，以了解在 I / O 綁定性能和安全性都是關鍵需求的環(huán)境中使用此技術的利弊。
什么是 Kata 容器?
Kata 容器是輕量級 vm，旨在與 Docker 和 Kubernetes 等容器編排軟件無縫集成。設想的一個用例是運行不受信任的工作負載，利用不與主機共享操作系統(tǒng)內核所獲得的額外隔離。然而，在最近一次對虛擬機和容器的調查中，使用宿主機內核導致額外安全性這一毫無疑問的假設受到了挑戰(zhàn)。Kata 源于 Intel Clear Containers 和 Hyper runV 技術。gVisor 的目標是通過過濾和重定向系統(tǒng)調用到單獨的用戶空間內核來解決類似的問題。因此，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 提供了基本的共享文件系統(tǒng)功能，這對分析至關重要(測試路徑是安裝在主機上的網絡文件系統(tǒng))。
沒有這些先決條件，Kata 啟動將無聲地失敗(我們很難學到了這一點)。
這個示例要點展示了如何在 Minikube 集群中將 runC 替換為 Kata 運行時。注意，在編寫本文時，Kata 容器有額外的主機要求：
Kata 將只在配置為支持嵌套虛擬化的計算機上運行。
Kata 至少需要一個 Westmere 處理器架構。
如果沒有這些先決條件，Kata 的將悄無聲息地失敗(我們是從多次實踐中得到的)。
為了進行此分析，部署了一個裸機 Kubernetes 集群，使用 OpenStack Heat 通過我們的 appliances playbooks 配置機器，并使用 Kubespray 將它們配置為 Kubernetes 集群。Kubespray 支持除 Docker 之外的其他容器運行時規(guī)范，例如 CRI- O 和 containerd，這是支持 Kata 運行時所必需的。
設計 I / O 性能測試方案
為了對 Kata 容器的 I / O 性能進行基準測試，我們在裸機和 runC 容器的情況下提出了等效的場景來進行比較。在所有情況下，我們都使用 fio(3.1 版)作為 I / O 基準測試工具，調用方式如下，其中 $SCRATCH_DIR 是安裝在主機上的 BeeGFS(本節(jié)稍后將詳細介紹)網絡存儲的路徑：
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}Scenario 客戶端數(shù)量磁盤 I / O 模式裸機 1 順序讀取 runC 容器 8 隨機讀取 Kata 容器 64 順序寫 隨機寫
為 I / O 性能研究探索的參數(shù)空間涵蓋了 36 種方案、客戶機數(shù)量和磁盤 I / O 模式的組合。
結果
磁盤 I / O 吞吐量
在這些結果中，我們繪制了所有客戶端上的總帶寬，展示了單個客戶端可以實現(xiàn)的向上擴展帶寬以及許多客戶端上實現(xiàn)的向外擴展吞吐量。
裸機，runC 和 Kata 之間的磁盤 I / O 帶寬比較。在所有情況下，使用 runC 容器實現(xiàn)的帶寬都略低于裸機。但是，Kata 容器的性能通常要差得多，當有 64 個客戶端時，其獲得的裸機讀取帶寬大約為 15%，隨機寫入帶寬的比例要小得多。唯一的例外是使用 64 個客戶端的順序寫入情況，其中 Kata 容器的性能好于裸機方案約 25%。
提交延遲累積分布函數(shù)(CDF)
在對延遲敏感的工作負載中，I/ O 延遲可能占主導地位。I/ O 操作提交延遲按對數(shù)比例繪制，以適應非常廣泛的數(shù)據(jù)點。
分別針對 1、8 和 64 個客戶端的裸機，runC 和 Kata 容器環(huán)境之間的提交延遲 CDF 的比較。與將它們作為 runC 容器運行相比，在裸機中運行 fio 作業(yè)之間存在微小差異。但是，將裸機與 Kata 容器進行比較，在所有情況下的開銷都非常大。
Number of clients 1 8 64 ModeScenario50%99%50%99%50%99%sequential readbare15812670241633781453247095runC20072506239139071506246022 Kata41124620126484646486409563806 random readbare9702342258033051493543884runC11552277250638561537842229 Kata547265861351731080109805314277 sequential writebare101117282592150233730258834runC101119902547148924308233832 Kata394848824102616014821190742 random writebare1269202336981161619722159285runC1286195739281179619374151756 Kata43585275456614254178055915343845
該表總結了與之前顯示的數(shù)字相對應的 50% 和 99% 的提交延遲(以 s 為單位)。*
展望未來
在這種 I / O 密集型方案中，Kata 容器尚未達到傳統(tǒng)容器的性能。
從結果可以明顯看出，在裸機、runC 容器和 Kata 容器之間進行選擇時，需要權衡取舍。盡管 runC 容器為大多數(shù)用例提供了更完善的考量，但它們仍然使主機內核易于受到系統(tǒng)調用接口作為攻擊面的利用。Kata 容器提供了硬件支持的隔離，但是目前存在巨大的性能開銷，尤其是對于磁盤 I / O 綁定操作。
Kata 的發(fā)展路線圖和發(fā)展速度擁有堅實的基礎以及樂觀的前景。Kata 團隊已經意識到使用 virtio-9p 作為存儲驅動程序在主機和來賓 VM 之間共享路徑的性能缺陷。
Kata 版本 1.7(將于 2019 年 5 月 15 日發(fā)布)預計將附帶 virtio fs 的實驗支持，該版本有望改善 I / O 性能問題。初步結果令人鼓舞，其他已發(fā)布的基準測試報告顯示，virtio fs 驅動程序的磁盤 I / O 帶寬比 virtio-9p 提高了 2 到 8 倍。當新功能可用時，我們將重復我們的測試以及分析。
關于如何分析 Kata 容器的 I / O 性能就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。
