KubeVirt虛擬機(jī)存儲及網(wǎng)絡(luò)卸載加速解決方案

1.? 方案背景

1.1. KubeVirt介紹

隨著云計算和容器技術(shù)的飛速發(fā)展，Kubernetes已成為業(yè)界公認(rèn)的容器編排標(biāo)準(zhǔn)，為用戶提供了強(qiáng)大、靈活且可擴(kuò)展的平臺來部署和管理各類應(yīng)用。然而，在企業(yè)的實際應(yīng)用中，仍有許多傳統(tǒng)應(yīng)用或遺留系統(tǒng)難以直接容器化，通常采用傳統(tǒng)的虛擬化技術(shù)來支撐。因此，企業(yè)需要同時運(yùn)行容器和虛擬機(jī)的混合云或私有云環(huán)境，以便開發(fā)者和運(yùn)維人員方便地管理和維護(hù)這兩種類型的工作負(fù)載，這促使了KubeVirt項目的誕生。

KubeVirt是一個開源項目，由Red Hat、IBM、Google、Intel和SUSE等多家公司共同推動和貢獻(xiàn)。該項目旨在通過Kubernetes來管理和運(yùn)行虛擬機(jī)（VMs），使虛擬機(jī)能夠像容器一樣被部署和消費(fèi)。KubeVirt擴(kuò)展了Kubernetes的API，增加了VirtualMachine和VirtualMachineInstance等自定義資源定義（CRDs），允許用戶通過YAML文件或kubectl命令來管理虛擬機(jī)，極大簡化了虛擬機(jī)的創(chuàng)建、更新、刪除和查詢過程。

KubeVirt 的價值主要體現(xiàn)在統(tǒng)一的資源管理，使得 Kubernetes 能夠同時管理容器和虛擬機(jī)，為用戶提供統(tǒng)一的資源管理界面。這消除了容器和虛擬機(jī)之間的管理界限，提高了資源管理的靈活性和效率，為用戶提供了更多的選擇，確保了應(yīng)用的完整性和性能，促進(jìn)了傳統(tǒng)應(yīng)用的現(xiàn)代化和云原生轉(zhuǎn)型。

1.2. 問題與挑戰(zhàn)

KubeVirt在提供虛擬機(jī)實例的部署和管理能力時，會面臨著諸多網(wǎng)絡(luò)和存儲方面的問題與挑戰(zhàn)。

如上圖所示，構(gòu)建KubeVirt虛擬機(jī)環(huán)境需要先啟動一個Pod，在Pod中構(gòu)建虛擬機(jī)的運(yùn)行環(huán)境。

在無DPU/SmartNIC的場景下，Pod通過Kubernetes CNI創(chuàng)建的veth pair連接網(wǎng)絡(luò)， 虛擬機(jī)為了對接CNI接入Pod中的網(wǎng)卡（eth0-nic），傳統(tǒng)的虛擬機(jī)環(huán)境是需要創(chuàng)建網(wǎng)橋設(shè)備（k6t-eth0），網(wǎng)卡（eth0-nic）連接到網(wǎng)橋設(shè)備，然后再創(chuàng)建TAP設(shè)備（tap0），TAP設(shè)備（tap0）的一端連接到網(wǎng)橋設(shè)備，另外一端連接虛擬機(jī)，這樣虛擬機(jī)網(wǎng)絡(luò)打通了與主機(jī)上OVS的網(wǎng)絡(luò)連接。在上圖中可以看到，虛擬機(jī)的網(wǎng)絡(luò)路徑為：ovs --> vethxxx --> eth0-nic --> k6t-eth0 --> tap0 --> eth0。

此外，Pod的存儲是通過Kubernetes CSI掛載到主機(jī)上云盤設(shè)備，傳統(tǒng)網(wǎng)絡(luò)存儲都是基于TCP的iscsi/rbd/nvmeof-tcp提供的遠(yuǎn)端存儲，在KubeVirt虛擬機(jī)環(huán)境中，遠(yuǎn)端存儲被CSI掛載到Pod中直接被虛擬機(jī)使用。

如上所述，在KubeVirt虛擬機(jī)環(huán)境中，網(wǎng)絡(luò)和存儲的配置面臨著一系列問題與挑戰(zhàn)：

1、網(wǎng)絡(luò)路徑復(fù)雜且冗長：

在無DPU/SmartNIC的場景下，虛擬機(jī)網(wǎng)絡(luò)路徑包含了多個虛擬設(shè)備（如veth pair、網(wǎng)橋、TAP設(shè)備等），這使得網(wǎng)絡(luò)路徑復(fù)雜且冗長，這種長路徑不僅增加了數(shù)據(jù)包處理的復(fù)雜度，提升了運(yùn)維排障難度，還可能導(dǎo)致更高的延遲和性能瓶頸。

2、資源消耗高：

路徑中過多的網(wǎng)絡(luò)虛擬設(shè)備需要CPU和內(nèi)存資源來處理數(shù)據(jù)包的轉(zhuǎn)發(fā)和路由。這些資源消耗在高負(fù)載場景下尤為顯著，可能導(dǎo)致宿主機(jī)資源緊張，整體資源利用率低。

3、網(wǎng)絡(luò)性能低下：

由于網(wǎng)絡(luò)路徑復(fù)雜和資源消耗高，虛擬機(jī)的網(wǎng)絡(luò)性能往往受到限制，在高吞吐量或低延遲要求的應(yīng)用場景中，這種性能問題尤為明顯。

4、基于TCP的遠(yuǎn)端存儲存在性能瓶頸：

使用iSCSI、RBD（Ceph RBD）或NVMe-oF（TCP模式）等基于TCP的遠(yuǎn)端存儲方案時，數(shù)據(jù)需要經(jīng)過網(wǎng)絡(luò)協(xié)議棧的處理，這增加了CPU的負(fù)擔(dān)并可能導(dǎo)致較高的延遲，這些存儲協(xié)議沒有硬件加速的支持，因此在高I/O需求下性能表現(xiàn)不佳。

2.? 方案介紹

2.1. 整體方案架構(gòu)

為了應(yīng)對KubeVirt虛擬機(jī)在網(wǎng)絡(luò)與存儲方面所遭遇的問題與挑戰(zhàn)，本方案創(chuàng)造性地集成了DPU（數(shù)據(jù)處理單元）硬件，以下將詳細(xì)闡述基于DPU卸載加速技術(shù)的KubeVirt虛擬機(jī)網(wǎng)絡(luò)及存儲解決方案的架構(gòu)。

如上圖所示，基于DPU改造后后，網(wǎng)絡(luò)和存儲都是從DPU卡接入的，DPU硬件支持?jǐn)?shù)據(jù)包的高速處理和RDMA（遠(yuǎn)程直接內(nèi)存訪問）技術(shù)，提供對網(wǎng)絡(luò)和存儲的硬件加速能力。同時DPU集成了CPU核心，能夠?qū)VS控制面卸載到DPU中，從而減少Host節(jié)點(diǎn)CPU的負(fù)載。為了把DPU接入K8S平臺，需要使用基于DPU的CNI和CSI，用于對接DPU的網(wǎng)絡(luò)和存儲功能。

• cni-controller：該組件執(zhí)行kubernetes內(nèi)資源到ovn資源的翻譯工作，是SDN系統(tǒng)的控制平面，也相當(dāng)于ovn的cms云管理系統(tǒng)。其監(jiān)聽所有和網(wǎng)絡(luò)相關(guān)資源的事件，并根據(jù)資源變化情況更新ovn內(nèi)的邏輯網(wǎng)絡(luò)。
• cni-node：為虛擬機(jī)提供虛擬網(wǎng)卡配置功能，調(diào)用 ovs 進(jìn)行配置。
• csi-controller：用于創(chuàng)建volume和nvmeof target；針對pvc，調(diào)用第三方的controller創(chuàng)建卷，創(chuàng)建快照和擴(kuò)容等。
• csi-node：為虛擬機(jī)所在容器提供云盤掛載功能，最終通過spdk 進(jìn)行配置，spdk 通過 pcie 給虛擬機(jī)所在容器模擬磁盤。

2.2. 方案描述

2.2.1.??核心資源

KubeVirt的核心資源主要是虛擬機(jī)資源，圍繞虛擬機(jī)生命周期管理定義了其他的CRD資源，包括：

• virtualmachines（vm）: 該結(jié)果為集群內(nèi)的VirtualMachineInstance提供管理功能，例如開機(jī)、關(guān)機(jī)、重啟虛擬機(jī)，確保虛擬機(jī)實例的啟動狀態(tài)，與虛擬機(jī)實例是1:1的關(guān)系，類似與spec.replica為1的StatefulSet。
• Virtualmachineinstances(vmi)：VMI類似于kubernetes Pod，是管理虛擬機(jī)的最小資源。一個VirtualMachineInstance對象即表示一臺正在運(yùn)行的虛擬機(jī)實例，包含一個虛擬機(jī)所需要的各種配置。

2.2.2.??網(wǎng)絡(luò)

KubeVirt以multus(OVS)+sriov的網(wǎng)絡(luò)接入方式使用DPU，虛擬機(jī)網(wǎng)絡(luò)的接入定義需要分成2部分:

• 節(jié)點(diǎn)的基礎(chǔ)網(wǎng)絡(luò)如何接入pod中。
• pod中的網(wǎng)絡(luò)如何接入虛擬機(jī)中。

2.2.2.1.?網(wǎng)絡(luò)控制面

如上圖所示，將master節(jié)點(diǎn)，dpu卡，Host都作為node加入k8s集群，這些node上運(yùn)行著DPU CNI的相關(guān)組件，下面分別進(jìn)行介紹：

• ovn和ovs為轉(zhuǎn)發(fā)面核心組件，共同提供SDN（軟件定義網(wǎng)絡(luò)）能力，其中ovn負(fù)責(zé)網(wǎng)絡(luò)邏輯層面的管理和抽象，而ovs則負(fù)責(zé)實際數(shù)據(jù)包的轉(zhuǎn)發(fā)和處理。
• cni-controller，該組件執(zhí)行kubernetes內(nèi)資源到ovn資源的翻譯工作，是SDN系統(tǒng)的控制平面，也相當(dāng)于ovn的cms云管理系統(tǒng)。其監(jiān)聽所有和網(wǎng)絡(luò)相關(guān)資源的事件，并根據(jù)資源變化情況更新ovn內(nèi)的邏輯網(wǎng)絡(luò)。
• cni-bin，一個二進(jìn)制程序，作為kubelet和cni-node之間的交互工具，將相應(yīng)的CNI請求發(fā)給cni-node執(zhí)行。
• cni-node，該組件作為一個DaemonSet運(yùn)行在每個節(jié)點(diǎn)上，實現(xiàn)CNI接口，并監(jiān)聽api-server配置本地網(wǎng)絡(luò)，其會根據(jù)工作模式做相應(yīng)的網(wǎng)絡(luò)配置，工作模式有以下幾種：

1）Default模式： cni-node的默認(rèn)工作模式，master和帶SmartNic卡的Host節(jié)點(diǎn)中的cni-node均工作于此模式。在該模式下，會對安置在其上的容器配置完整的虛擬網(wǎng)絡(luò)配置，如容器網(wǎng)絡(luò)和ovs網(wǎng)絡(luò)。

2）DPU模式：DPU節(jié)點(diǎn)中的cni-node工作于此模式。在該模式下，會對安置在DPU內(nèi)的容器配置完成的虛擬網(wǎng)絡(luò)配置。而對安置在其Host的容器，會配置ovs網(wǎng)絡(luò)。

3）Host模式：帶DPU卡的Host節(jié)點(diǎn)中的cni-node工作于此模式。在該模式下，只會去配置容器網(wǎng)絡(luò)，而對應(yīng)的底層網(wǎng)絡(luò)如ovs網(wǎng)絡(luò)，則交由其對應(yīng)DPU上工作在DPU模式的cni-node完成。

2.2.2.2.?網(wǎng)絡(luò)數(shù)據(jù)面

基于DPU卸載與加速的高性能網(wǎng)絡(luò)，其核心技術(shù)的數(shù)據(jù)面原理如上圖所示。基于ovn/ovs提供SDN的能力，并基于DPU提供的SRIOV及流表卸載功能，對網(wǎng)絡(luò)進(jìn)行了加速，為云上業(yè)務(wù)提高了高性能網(wǎng)絡(luò)。

2.2.3.??存儲

Kubevirt并沒有重新定義存儲，存儲還是由Kubernetes定義的，所以還是沿用CSI規(guī)范創(chuàng)建/掛載/刪除磁盤卷，如上圖所示。主流平臺的磁盤卷都是通過網(wǎng)絡(luò)（TCP/RDMA）來掛載的，一般都是基于TCP的，RDMA需要硬件的支持。

2.2.3.1.?存儲控制面

基于DPU的虛擬機(jī)磁盤卷架構(gòu)如如上圖所示，將master節(jié)點(diǎn)，dpu卡，Host都作為node加入k8s集群，這些node上運(yùn)行著DPU CSI的相關(guān)組件，k8s node分為不同的角色，不同組件分別部署在不同的node之上。

• Master上，部署 csi的控制器csi-controller，其中部署包含了組件external-provisioner、csi-plugin、??csi-attacher???、??csi-resizer??和csi-snapshotter等組件，用于創(chuàng)建volume和nvmeof target；
• Host上，部署csi-node-host，配合csi-node-dpu，通過va發(fā)現(xiàn)DPU掛載的nvme盤，然后執(zhí)行綁定或者格式化；
• DPU上，部署csi-node-dpu，volume-attacher，opi-bridge和SPDK，主要負(fù)責(zé)連接遠(yuǎn)端存儲target，及向宿主機(jī)模擬nvme硬盤;

1. opi-bridge是卡對opi-api存儲的實現(xiàn)。
2. volume-attacher是對DPU存儲相關(guān)方法的封裝；csi-node-dpu 調(diào)用volume-attacher給host掛盤 為了對接不同的存儲，CSI提供了csi-framework, 通過csi-framework能快速的接入第三方的存儲，讓第三方存儲很方便的使用DPU的能力；同時CSI提供基于opi框架的opi-framework，通過opi-framework能快速讓DPU適配到K8S集群。

2.2.3.2.?存儲數(shù)據(jù)面

DPU通過網(wǎng)絡(luò)連接遠(yuǎn)端存儲target，實現(xiàn)了存儲協(xié)議的卸載，同時能基于RDMA進(jìn)行網(wǎng)絡(luò)路徑上的加速；另一方面，DPU模擬了nvme協(xié)議，通過PCIe向宿主機(jī)提供了nvme塊設(shè)備。

3.? 方案測試結(jié)果

3.1. 測試步驟說明

主要是對KubeVirt虛擬機(jī)的網(wǎng)絡(luò)和存儲進(jìn)行性能驗證：

• 網(wǎng)絡(luò)性能主要測試卸載CNI方案和非卸載CNI方案下的虛擬機(jī)網(wǎng)卡性能，包括帶寬、PPS、時延。
• 存儲性能主要針對虛擬機(jī)的數(shù)據(jù)盤進(jìn)行驗證，包括順序?qū)懲掏?、順序讀吞吐、隨機(jī)寫IOPS、隨機(jī)讀IOPS、隨機(jī)寫時延、隨機(jī)讀時延。虛擬機(jī)的數(shù)據(jù)盤來源于DPU模擬的nvme磁盤，后端存儲協(xié)議有2種：nvme over tcp和nvme over rdma。

使用卸載CNI方案的虛擬機(jī)網(wǎng)絡(luò)拓?fù)?/a>如下圖：

使用非卸載CNI方案的虛擬機(jī)網(wǎng)絡(luò)拓?fù)淙缦聢D：

3.2. 性能測試結(jié)果

以下列舉基于DPU （100G）網(wǎng)絡(luò)方案的網(wǎng)絡(luò)性能指標(biāo)，并與非硬件卸載CNI方案做簡單對比：

分類	性能指標(biāo)	非卸載CNI方案	卸載CNI方案
網(wǎng)絡(luò)	網(wǎng)絡(luò)帶寬	27.4Gbps	137Gbps
	網(wǎng)絡(luò)PPS	3.4M	26M
	網(wǎng)絡(luò)時延	783us	18us

從上表可知基于卸載CNI方案的網(wǎng)絡(luò)性能相比于非卸載CNI方案來說，網(wǎng)絡(luò)帶寬提升了4倍，網(wǎng)絡(luò)PPS提升了6.6倍，網(wǎng)絡(luò)時延降低了97.7%

基于DPU（100G）存儲方案性能指標(biāo)，nvme over rdma對比nvme over tcp：

分類	性能指標(biāo)	nvme over tcp	nvme over rdma
存儲	順序?qū)懲掏?/td>	1146MiB/s	2577MiB/s
	順序讀吞吐	431MiB/s	5182MiB/s
	隨機(jī)寫IOPS	104k	232k
	隨機(jī)讀IOPS	63.1k	137k
	隨機(jī)寫時延	164us	60us
	隨機(jī)讀時延	429us	127us

從上表可知，nvme over rdma方式的存儲在吞吐、IOPS、時延方面全面優(yōu)于nvme over tcp方式的存儲。另外，nvme over rdma場景下的存儲性能遠(yuǎn)低于容器掛載硬盤時的性能(650kiops)，原因是當(dāng)前虛擬機(jī)的硬盤是通過virtio方式掛載的，存在額外的虛擬化開銷，性能上受到限制。

4.? 優(yōu)勢總結(jié)

在KubeVirt虛擬機(jī)環(huán)境中，基于DPU硬件卸載的方案相較于傳統(tǒng)的非卸載方案，具有顯著的優(yōu)勢，這些優(yōu)勢主要體現(xiàn)在網(wǎng)絡(luò)性能、資源利用率、時延降低以及存儲性能加速等方面，具體總結(jié)如下：

1、降低網(wǎng)絡(luò)復(fù)雜度和運(yùn)維排障難度：

通過DPU的網(wǎng)絡(luò)卸載能力，實現(xiàn)了網(wǎng)卡直通到虛擬機(jī)，減少了虛擬網(wǎng)絡(luò)設(shè)備（veth pair、網(wǎng)橋、TAP設(shè)備等），極大地縮短了網(wǎng)絡(luò)路徑，降低了網(wǎng)絡(luò)復(fù)雜性和運(yùn)維排障難度，并減少了數(shù)據(jù)在傳輸過程中的延遲和損耗。

2、顯著提升網(wǎng)絡(luò)性能：

將虛擬機(jī)的流表卸載到DPU中，利用硬件進(jìn)行流表處理，直接將網(wǎng)絡(luò)數(shù)據(jù)對接到虛擬機(jī)，這一過程比軟件處理更為高效，為虛擬機(jī)提供了接近物理網(wǎng)卡的極致性能。這種方式使得網(wǎng)絡(luò)帶寬提升了4倍，PPS（每秒包數(shù)）提升了6.6倍，網(wǎng)絡(luò)時延降低了97.7%，顯著提升了網(wǎng)絡(luò)吞吐量和處理速度。

3、降低資源消耗：

將OVS（Open vSwitch）控制面和數(shù)據(jù)面都部署在DPU中，利用DPU的硬件資源進(jìn)行網(wǎng)絡(luò)數(shù)據(jù)包的轉(zhuǎn)發(fā)和處理，大大減輕了Host主機(jī)CPU和內(nèi)存的負(fù)擔(dān)。在40Gbps的TCP/IP流量場景下，傳統(tǒng)服務(wù)器容易因處理網(wǎng)絡(luò)任務(wù)而耗盡CPU資源，而基于DPU的硬件卸載方案能夠顯著降低CPU占用率，使得服務(wù)器能夠處理更多的計算任務(wù)或支持更高的網(wǎng)絡(luò)負(fù)載。

4、加速存儲性能：

通過yusur-csi提供的基于DPU的RDMA支持，相對于傳統(tǒng)的TCP存儲方案，能夠?qū)崿F(xiàn)硬件級別的性能加速。這種加速效果最低能達(dá)到2倍，最高能達(dá)到10倍，顯著提升了存儲系統(tǒng)的吞吐量和響應(yīng)速度。

綜上所述，基于DPU硬件卸載CNI方案通過縮短網(wǎng)絡(luò)路徑、降低資源消耗、減少網(wǎng)絡(luò)時延以及加速存儲性能等多方面優(yōu)勢，為云計算和虛擬化環(huán)境提供了更高效、更可靠的網(wǎng)絡(luò)和存儲解決方案。

本方案來自于中科馭數(shù)軟件研發(fā)團(tuán)隊，團(tuán)隊核心由一群在云計算、數(shù)據(jù)中心架構(gòu)、高性能計算領(lǐng)域深耕多年的業(yè)界資深架構(gòu)師和技術(shù)專家組成，不僅擁有豐富的實戰(zhàn)經(jīng)驗，還對行業(yè)趨勢具備敏銳的洞察力，該團(tuán)隊致力于探索、設(shè)計、開發(fā)、推廣可落地的高性能云計算解決方案，幫助最終客戶加速數(shù)字化轉(zhuǎn)型，提升業(yè)務(wù)效能，同時降低運(yùn)營成本。