1. 方案背景

1.1. KubeVirt介紹

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

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

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

1.2. 問題與挑戰

KubeVirt在提供虛擬機實例的部署和管理能力時，會面臨著諸多網絡和存儲方面的問題與挑戰。

如上圖所示，構建KubeVirt虛擬機環境需要先啟動一個Pod，在Pod中構建虛擬機的運行環境。

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

此外，Pod的存儲是通過Kubernetes CSI掛載到主機上云盤設備，傳統網絡存儲都是基于TCP的iscsi/rbd/nvmeof-tcp提供的遠端存儲，在KubeVirt虛擬機環境中，遠端存儲被CSI掛載到Pod中直接被虛擬機使用。

如上所述，在KubeVirt虛擬機環境中，網絡和存儲的配置面臨著一系列問題與挑戰：

1、網絡路徑復雜且冗長：

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

2、資源消耗高：

路徑中過多的網絡虛擬設備需要CPU和內存資源來處理數據包的轉發和路由。這些資源消耗在高負載場景下尤為顯著，可能導致宿主機資源緊張，整體資源利用率低。

3、網絡性能低下：

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

4、基于TCP的遠端存儲存在性能瓶頸：

使用iSCSI、RBD（Ceph RBD）或NVMe-oF（TCP模式）等基于TCP的遠端存儲方案時，數據需要經過網絡協議棧的處理，這增加了CPU的負擔并可能導致較高的延遲，這些存儲協議沒有硬件加速的支持，因此在高I/O需求下性能表現不佳。

2. 方案介紹

2.1. 整體方案架構

為了應對KubeVirt虛擬機在網絡與存儲方面所遭遇的問題與挑戰，本方案創造性地集成了DPU（數據處理單元）硬件，以下將詳細闡述基于DPU卸載加速技術的KubeVirt虛擬機網絡及存儲解決方案的架構。

如上圖所示，基于DPU改造后后，網絡和存儲都是從DPU卡接入的，DPU硬件支持數據包的高速處理和RDMA（遠程直接內存訪問）技術，提供對網絡和存儲的硬件加速能力。同時DPU集成了CPU核心，能夠將OVS控制面卸載到DPU中，從而減少Host節點CPU的負載。為了把DPU接入K8S平臺，需要使用基于DPU的CNI和CSI，用于對接DPU的網絡和存儲功能。

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

2.2. 方案描述

2.2.1.核心資源

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

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

2.2.2.網絡

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

• 節點的基礎網絡如何接入pod中。
• pod中的網絡如何接入虛擬機中。

2.2.2.1.網絡控制面

如上圖所示，將master節點，dpu卡，Host都作為node加入k8s集群，這些node上運行著DPU CNI的相關組件，下面分別進行介紹：

• ovn和ovs為轉發面核心組件，共同提供SDN（軟件定義網絡）能力，其中ovn負責網絡邏輯層面的管理和抽象，而ovs則負責實際數據包的轉發和處理。
• cni-controller，該組件執行kubernetes內資源到ovn資源的翻譯工作，是SDN系統的控制平面，也相當于ovn的cms云管理系統。其監聽所有和網絡相關資源的事件，并根據資源變化情況更新ovn內的邏輯網絡。
• cni-bin，一個二進制程序，作為kubelet和cni-node之間的交互工具，將相應的CNI請求發給cni-node執行。
• cni-node，該組件作為一個DaemonSet運行在每個節點上，實現CNI接口，并監聽api-server配置本地網絡，其會根據工作模式做相應的網絡配置，工作模式有以下幾種：
  • Default模式： cni-node的默認工作模式，master和帶SmartNic卡的Host節點中的cni-node均工作于此模式。在該模式下，會對安置在其上的容器配置完整的虛擬網絡配置，如容器網絡和ovs網絡。
  • DPU模式：DPU節點中的cni-node工作于此模式。在該模式下，會對安置在DPU內的容器配置完成的虛擬網絡配置。而對安置在其Host的容器，會配置ovs網絡。
  • Host模式：帶DPU卡的Host節點中的cni-node工作于此模式。在該模式下，只會去配置容器網絡，而對應的底層網絡如ovs網絡，則交由其對應DPU上工作在DPU模式的cni-node完成。

2.2.2.2.網絡數據面

基于DPU卸載與加速的高性能網絡，其核心技術的數據面原理如上圖所示。基于ovn/ovs提供SDN的能力，并基于DPU提供的SRIOV及流表卸載功能，對網絡進行了加速，為云上業務提高了高性能網絡。

2.2.3.存儲

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

2.2.3.1.存儲控制面

基于DPU的虛擬機磁盤卷架構如如上圖所示，將master節點，dpu卡，Host都作為node加入k8s集群，這些node上運行著DPU CSI的相關組件，k8s node分為不同的角色，不同組件分別部署在不同的node之上。

• Master上，部署 csi的控制器csi-controller，其中部署包含了組件external-provisioner、csi-plugin、??csi-attacher???、??csi-resizer??和csi-snapshotter等組件，用于創建volume和nvmeof target；
• Host上，部署csi-node-host，配合csi-node-dpu，通過va發現DPU掛載的nvme盤，然后執行綁定或者格式化；
• DPU上，部署csi-node-dpu，volume-attacher，opi-bridge和SPDK，主要負責連接遠端存儲target，及向宿主機模擬nvme硬盤;
  • opi-bridge是卡對opi-api存儲的實現。
  • volume-attacher是對DPU存儲相關方法的封裝；csi-node-dpu 調用volume-attacher給host掛盤 為了對接不同的存儲，CSI提供了csi-framework, 通過csi-framework能快速的接入第三方的存儲，讓第三方存儲很方便的使用DPU的能力；同時CSI提供基于opi框架的opi-framework，通過opi-framework能快速讓DPU適配到K8S集群。

2.2.3.2.存儲數據面

DPU通過網絡連接遠端存儲target，實現了存儲協議的卸載，同時能基于RDMA進行網絡路徑上的加速；另一方面，DPU模擬了nvme協議，通過PCIe向宿主機提供了nvme塊設備。

3. 方案測試結果

3.1. 測試步驟說明

主要是對KubeVirt虛擬機的網絡和存儲進行性能驗證：

• 網絡性能主要測試卸載CNI方案和非卸載CNI方案下的虛擬機網卡性能，包括帶寬、PPS、時延。
• 存儲性能主要針對虛擬機的數據盤進行驗證，包括順序寫吞吐、順序讀吞吐、隨機寫IOPS、隨機讀IOPS、隨機寫時延、隨機讀時延。虛擬機的數據盤來源于DPU模擬的nvme磁盤，后端存儲協議有2種：nvme over tcp和nvme over rdma。

使用卸載CNI方案的虛擬機網絡拓撲如下圖：

使用非卸載CNI方案的虛擬機網絡拓撲如下圖：

3.2. 性能測試結果

以下列舉基于DPU （100G）網絡方案的網絡性能指標，并與非硬件卸載CNI方案做簡單對比：

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

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

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

4. 優勢總結

在KubeVirt虛擬機環境中，基于DPU硬件卸載的方案相較于傳統的非卸載方案，具有顯著的優勢，這些優勢主要體現在網絡性能、資源利用率、時延降低以及存儲性能加速等方面，具體總結如下：

1、降低網絡復雜度和運維排障難度：

通過DPU的網絡卸載能力，實現了網卡直通到虛擬機，減少了虛擬網絡設備（veth pair、網橋、TAP設備等），極大地縮短了網絡路徑，降低了網絡復雜性和運維排障難度，并減少了數據在傳輸過程中的延遲和損耗。

2、顯著提升網絡性能：

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

3、降低資源消耗：

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

4、加速存儲性能：

通過yusur-csi提供的基于DPU的RDMA支持，相對于傳統的TCP存儲方案，能夠實現硬件級別的性能加速。這種加速效果最低能達到2倍，最高能達到10倍，顯著提升了存儲系統的吞吐量和響應速度。

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

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

審核編輯 黃宇