1. 方案背景與挑戰(zhàn)

隨著云計算，大數(shù)據(jù)和人工智能等技術(shù)的蓬勃發(fā)展，數(shù)據(jù)中心面臨著前所未有的數(shù)據(jù)洪流和計算壓力，這對SDN提出了更高的性能和效率要求。自云原生概念被提出以來，Kubernetes為云原生應(yīng)用的落地提供了一個輕量級，可移植的運行環(huán)境，逐漸成為云原生時代基礎(chǔ)設(shè)施的事實標(biāo)準(zhǔn)。Kubernetes通過網(wǎng)絡(luò)插件（CNI，Container Network Interface）實現(xiàn)靈活地配置和管理集群中的容器網(wǎng)絡(luò)，確保容器之間的有效通信和網(wǎng)絡(luò)安全。然而在追求極致性能和云計算IaaS深度整合過程中，CNI插件面臨著諸多挑戰(zhàn)，具體表現(xiàn)為以下幾個方面：

1、網(wǎng)絡(luò)性能瓶頸：在高性能計算場景中，網(wǎng)絡(luò)延遲和吞吐量是關(guān)鍵指標(biāo)，現(xiàn)有的CNI插件(如Flannel、Calico、Cilium等)在處理大規(guī)模數(shù)據(jù)傳輸時可能會出現(xiàn)嚴(yán)重的延遲和吞吐量瓶頸。這一問題的根源是傳統(tǒng)CNI插件多采用基于軟件的虛擬化網(wǎng)絡(luò)方案,在數(shù)據(jù)包處理過程中需要經(jīng)過多層封裝和解封裝,增加了處理延遲。另外，在高并發(fā)場景下，軟件定義的網(wǎng)絡(luò)轉(zhuǎn)發(fā)表可能成為性能瓶頸，導(dǎo)致吞吐量下降。

2、硬件支持不足：當(dāng)前的Kubernetes CNI插件普遍缺乏對智能網(wǎng)卡（SmartNIC）和數(shù)據(jù)處理單元（DPU）的支持，導(dǎo)致無法完全發(fā)揮這些硬件的潛力。例如，傳統(tǒng)CNI插件可能無法充分使用網(wǎng)卡的物理功能（PF）、虛擬功能（VF）和共享功能（SF）資源，或者其提供的SDN網(wǎng)絡(luò)服務(wù)（如EIP等）無法充分利用SmartNIC/DPU實現(xiàn)硬件流量卸載等功能。

3、SDN服務(wù)集成困難：云計算IaaS提供了豐富的SDN網(wǎng)絡(luò)服務(wù)，如VPC、負載均衡、安全組，EIP，Qos等。然而，將這些SDN網(wǎng)絡(luò)服務(wù)無縫集成到Kubernetes的網(wǎng)絡(luò)架構(gòu)中并非易事，IaaS層的網(wǎng)絡(luò)模型通常基于虛擬機，而Kubernetes采用的是容器網(wǎng)絡(luò)模型,兩者在網(wǎng)絡(luò)抽象和實現(xiàn)機制上存在差異。CNI插件需要與SDN網(wǎng)絡(luò)服務(wù)深度集成，同時保持Kubernetes的網(wǎng)絡(luò)模型的一致性。

2. 方案介紹

2.1. 整體架構(gòu)

為了解決傳統(tǒng)SDN方案的問題，中科馭數(shù)提出了基于DPU/SmartNic的云原生SDN解決方案，馭云SDN將DPU/SmartNic卡進行統(tǒng)一管理將其，支持的網(wǎng)卡如PF/VF/SF/VFIO/VDPA等通過device-plugin發(fā)布給Kubernetes進行統(tǒng)一的管理和調(diào)度。同時，通過ovn/ovs機制將這些卡加入到同一個ovn集群，通過ovn/ovs對網(wǎng)絡(luò)進行統(tǒng)一的虛擬化，如下圖所示：

Host上的容器或者虛擬機能夠使用DPU/SmartNic提供的VF，SF，或者是其生成VFIO，VDPA設(shè)備，通過這些設(shè)備加入虛擬化網(wǎng)絡(luò)，達到近似物理機的性能。軟件整體架構(gòu)如下：

如圖所示，馭云SDN是基于Kubernetes，將master節(jié)點，dpu卡，Host都作為node加入k8s集群，這些node上運行著馭云SDN的相關(guān)組件，下面分別進行介紹：

ycloud-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ò)。

ycloud，一個二進制程序，作為kubelet和ycloud-cni之間的交互工具，將相應(yīng)的CNI請求發(fā)給ycloud-cni執(zhí)行。

ycloud-cni，該組件作為一個DaemonSet運行在每個節(jié)點上，實現(xiàn)CNI接口，并監(jiān)聽api-server配置本地網(wǎng)絡(luò)，其會根據(jù)工作模式做相應(yīng)的網(wǎng)絡(luò)配置，工作模式有以下幾種：

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

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

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

基于上述的軟件架構(gòu)，馭云SDN通過結(jié)合Kubernetes的能力，OVN控制器的能力，OpenVSwitch網(wǎng)絡(luò)功能/卸載能力，DPU/SmartNic硬件能力，實現(xiàn)符合Kubernetes CNI標(biāo)準(zhǔn)規(guī)范，充分發(fā)揮DPU/SmartNic的硬件潛力，深度整合云計算IAAS等這些目標(biāo)，為云計算在追求極致網(wǎng)絡(luò)性能上提供了新的云原生SDN解決方案。

2.2. 方案描述

在基于DPU/SmartNic的云原生SDN方案下，實現(xiàn)了IAAS領(lǐng)域中的vpc，subnet，eip，安全組，qos等常用功能，以下將會對核心資源和部分主要功能做詳細描述。

2.2.1.核心資源

為了充分利用SmartNic/DPU網(wǎng)卡資源，且高效靈活的進行SDN網(wǎng)絡(luò)虛擬化，馭云SDN抽象出3種核心資源，下面分別做介紹：

nic，對應(yīng)Kubernetes中的pod在linux系統(tǒng)中的某個網(wǎng)卡，類型可以是pf/vf/sf/veth，由系統(tǒng)根據(jù)用戶要求自動創(chuàng)建和刪除。

vnic，對應(yīng)一個邏輯網(wǎng)卡，即ovn的logical_switch_port，是虛擬網(wǎng)絡(luò)的接口，可以是用戶自動創(chuàng)建，也可以是系統(tǒng)自動生成。由系統(tǒng)自動和pod的nic進行綁定，綁定后，pod就加入到vnic對應(yīng)的虛擬網(wǎng)絡(luò)。

vnicip，對應(yīng)一個邏輯ip，即ovn的logical_switch_port中的ip地址，由系統(tǒng)自動和vnic進行綁定，eip也是和vnicip進行綁定實現(xiàn)云上資源訪問外網(wǎng)需求的。

通過上述nic/vnic，我們能夠充分利用dpu/smartnic上的網(wǎng)卡資源，并進行網(wǎng)絡(luò)虛擬化。通過vnicip，我們可以合理利用ip地址，如ip分配，預(yù)留等。傳統(tǒng)的CNI插件，對于POD來說，其實都是有這些資源，只是沒有將這些資源抽象出來，或者說只抽象出部分。對于DPU/SmartNic場景，抽象出NIC和VNIC尤為重要，NIC對應(yīng)POD使用DPU/SmartNic中的卡資源，而VNIC對應(yīng)虛擬網(wǎng)絡(luò)的接口，兩者解耦，又能綁定，為SDN靈活性上提供更多可能。

2.2.2.vpc和subnet

vpc（virtual private cloud）是一種基于云計算的網(wǎng)絡(luò)服務(wù)，它允許用戶在云中創(chuàng)建一個邏輯上的隔離網(wǎng)絡(luò)環(huán)境，用戶可以在這個環(huán)境中啟動虛擬機、存儲、數(shù)據(jù)庫等云資源，并且可以自由的配置網(wǎng)絡(luò)、子網(wǎng)（subnet）、路由、安全組等網(wǎng)絡(luò)設(shè)備和安全策略。馭云SDN包含兩種vpc，一種是默認(rèn)vpc（ovn-cluster），一種是租戶vpc。默認(rèn)vpc滿足k8s CNI插件規(guī)范，系統(tǒng)pod會加入這個vpc，如馭云SDN系統(tǒng)組件。租戶vpc之間是完全隔離的。pod與pod，node與pod之間通信，流量將會卸載到dpu/smartnic。網(wǎng)絡(luò)模型如下:

vpc和subnet都是分布式的。流量能夠按照最短路徑進行轉(zhuǎn)發(fā)，而不會出現(xiàn)繞路等現(xiàn)象，如下圖所示，有一個vpc1，vpc1中創(chuàng)建了兩個子網(wǎng)subnet1和subnet2，創(chuàng)建了6個pod分別安置在node-A和node-B。vpc和subnet會在每個node都存在，pod1和pod2，pod1和pod3會在本地直接進行轉(zhuǎn)發(fā)，而不會經(jīng)過其他節(jié)點。pod1和pod4則會在本地進行路由，然后通過隧道進行轉(zhuǎn)發(fā)。

2.2.3.eip和eip-gateway

彈性公網(wǎng) EIP（后文簡稱 EIP）是可以獨立購買和持有的公網(wǎng) IP 資源，包括公網(wǎng) IP 地址及公網(wǎng)出口帶寬服務(wù)。可以將申請到的 EIP 與多種云資源綁定，如：云服務(wù)器(基于vnicip綁定)、vpc網(wǎng)絡(luò)、負載均衡器，并且可以解綁，再分配到其他資源上。EIP 支持綁定以下云資源，以應(yīng)用于不同的公網(wǎng)連接場景，如下圖所示：

綁定vpc，為vpc內(nèi)的云資源提供公網(wǎng)出口;

綁定云服務(wù)器，為云服務(wù)器提供公網(wǎng)服務(wù)或云服務(wù)器對外提供公網(wǎng)服務(wù)。云服務(wù)器包含容器，虛擬機，裸金屬;

綁定負載均衡器，云外網(wǎng)絡(luò)訪問服務(wù)的流量分發(fā)到后端的多臺服務(wù)器

為了滿足上述需求，馭云SDN提供了eip和eip-gateway資源，其中eip用于綁定給云資源，eip-gateway用于eip流量路由。eip綁定給云資源是基于OVN提供的NAT和Loadbalancer功能進行了實現(xiàn)，下面將對ovn基本概念進行簡單介紹：

snat，對應(yīng)ovn nat規(guī)則的snat類型，實現(xiàn)eip綁定給vpc。

nat，對應(yīng)ovn nat規(guī)則的dnat_and_snat，實現(xiàn)eip綁定給云服務(wù)器（基于vnicip）。

loadbalancer：實現(xiàn)eip綁定給負載均衡器，這個負載均衡器是4層service。

馭云SDN支持集中式eip-gateway和分布式eip-gateway，不管eip-gateway是集中式還是分布式，云服務(wù)器（基于vnicip）綁定eip，都是在本地進行nat的，這樣使nat處理都分布在各個Host上完成，避免了NAT集中在單臺Host上，導(dǎo)致單臺Host上cpu負載過高。而對于vpc綁定eip，這種屬于snat，則會在vpc主節(jié)點進行集中式nat處理。不管是分布式eip還是集中式eip，基于DPU&SmartNic的馭云SDN系統(tǒng)會對這種eip流量進行卸載，加快這種流量的處理。其基本使用流程如下：

其中eip-gateway和eip subnet通常是管理人員，根據(jù)實際物理組網(wǎng)，提前配置好。用戶只需要從eip subnet申請eip資源，綁定給云資源即可實現(xiàn)上述需求。

2.2.4.安全組

安全組是一種虛擬防火墻，用戶可以在安全組中定義各種訪問規(guī)則，這些訪問規(guī)則稱為??安全組規(guī)則??，安全組便是一系列安全組規(guī)則的集合。安全組可以綁定給云服務(wù)器。當(dāng)云服務(wù)器綁定安全組后，便可受到安全組規(guī)則的保護，以提高內(nèi)部網(wǎng)絡(luò)或云服務(wù)器的安全性。對于云上資源的安全，k8s提供了network-policy規(guī)范，同時一些網(wǎng)絡(luò)CNI還額外提供subnet acl等功能。但是這些功能都難以達到iaas的要求，iaas通常的做法是通過security-group來為云上資源提供基礎(chǔ)的網(wǎng)絡(luò)安全防護。通過在security-group中配置規(guī)則，并將security-group與云資源進行綁定，實現(xiàn)網(wǎng)卡級別的安全防護與隔離，為云上資源提供一道靈活且精細的保護屏障。因此馭云暫時不支持network-policy，而是通過security-group支持安全隔離的需求。

安全組對流量有默認(rèn)訪問控制規(guī)則，默認(rèn)訪問控制規(guī)則和用戶自定義規(guī)則共同作用，來控制云上資源的流量。安全組里面分為上行規(guī)則和下行規(guī)則，上行規(guī)則代表云資源訪問外面，下行規(guī)則代表外面訪問云資源。用戶自定義規(guī)則的優(yōu)先級限定為1-80，值越小，優(yōu)先級越高，系統(tǒng)規(guī)則的優(yōu)先級限定為90-100，優(yōu)先級81-89做保留。映射到底層ovn acl優(yōu)先級時，會做一定偏移，避免與其他硬編碼的flow優(yōu)先級沖突。

下行規(guī)則：未配置的下行規(guī)則和端口默認(rèn)拒絕訪問，安全組默認(rèn)配置以下下行規(guī)則

行為	優(yōu)先級	協(xié)議	端口	源/目標(biāo)地址	說明
接受	95	arp	/	ALL	容許獲取實例arp信息
接受	95	icmp	Echo/echo request	ALL	容許所有ip地址通過ping程序測試實例連通性
接受	95	dhcp	offer	ALL	容許云平臺通過dhcp給實例配置ip
接受	96	ALL	ALL	組內(nèi)IP組	容許組內(nèi)互信（前提：安全組設(shè)置組內(nèi)互信）
拒絕	97	ALL	ALL	ALL	默認(rèn)拒絕

上行規(guī)則：未配置的上行規(guī)則和端口默認(rèn)放行，安全組暫時沒有配置默認(rèn)上行規(guī)則，后續(xù)可根據(jù)需求添加默認(rèn)上行規(guī)則，如對一些高危端口的TCP/UDP連接進行拒絕。

行為	優(yōu)先級	協(xié)議	端口	源/目標(biāo)地址	說明
接受	96	ALL	ALL	組內(nèi)IP組	容許組內(nèi)互信（前提：安全組設(shè)置組內(nèi)互信）
接受	97	ALL	ALL	ALL	默認(rèn)接受

2.2.5.共享網(wǎng)卡

服務(wù)器插上DPU/SmartNic網(wǎng)卡后，這個DPU/SmartNic能夠支持的PF/VF/SF數(shù)量是有限的，服務(wù)器上的容器組一般多于VF數(shù)量，比如BF2卡，VF最多是128個，那么如果想讓每個容器組都單獨使用一個VF卡，VF卡的數(shù)量可能會不夠，因此在這種情況下，容器組可以通過共享VF網(wǎng)卡來實現(xiàn)網(wǎng)絡(luò)訪問。共享網(wǎng)卡方案如下：

為實現(xiàn)共享網(wǎng)卡方案，工作于Host模式的CNI在初始化階段將會為Host創(chuàng)建以下資源：

一個共享vnic：vnic會綁定到一個單獨的nic，默認(rèn)為pf0vf0;

一個共享network namespace：共享vnic對應(yīng)的pf0vf0會加入到該netns，在里會通過路由、策略路由、arp代答等規(guī)則完成共享網(wǎng)絡(luò)的路由轉(zhuǎn)發(fā)等功能

當(dāng)創(chuàng)建一個使用共享網(wǎng)卡的pod時，如果pod沒有指定vnicip，那么系統(tǒng)會為這個pod分配一個vnicip，然后將pod的vnicip綁定到共享vnic，同時為pod創(chuàng)建veth-pair設(shè)備，一端加入pod自己的netns，一端放入nic-share中，nic-share中為這個vnicip配策略路由和arp將網(wǎng)絡(luò)打通。如上圖所示，紅色代表慢路徑，綠色代表快路徑。

2.2.6.多網(wǎng)卡

在現(xiàn)代企業(yè)IT基礎(chǔ)設(shè)施中，多網(wǎng)卡服務(wù)器已經(jīng)成為了提高網(wǎng)絡(luò)通信效率的利器，服務(wù)器配備兩個或更多的網(wǎng)卡可以帶來多種網(wǎng)絡(luò)設(shè)計上的優(yōu)勢，包括但不限于網(wǎng)絡(luò)分離，負載均衡，高可用性。與其他CNI一樣，馭云SDN也能基于multus向pod提供多網(wǎng)卡功能，如下圖所

pod創(chuàng)建后，Kubernetes將其安置在了某個node上，node上的kubelet將通過multus-cni為pod配置網(wǎng)絡(luò)，但是其實multus-cni并不執(zhí)行具體的網(wǎng)絡(luò)配置，而是獲取pod上的網(wǎng)卡需求，如多少個網(wǎng)卡，網(wǎng)卡名稱等，然后交給對應(yīng)的CNI如ycloud-cni做具體配置。除此之外，馭云SDN還支持以下特性：

支持指定網(wǎng)卡類型，如veth/vf/sf/vdpa

支持指定網(wǎng)卡加入的subnet

支持指定網(wǎng)卡ip地址

支持配置網(wǎng)卡路由

支持網(wǎng)卡限速

通過在pod annotations進行配置支持上述功能，配置較為靈活，也是本方案最大優(yōu)點。

annotations: k8s.v1.cni.cncf.io/networks: yusur-vf@eth1 cni.iaas.yusur.io/subnet: ovn-default eth1.iaas.yusur.io/subnet: subnet1 eth1.iaas.yusur.io/vnicip: vnicip-1 cni.iaas.yusur.io/ingress_rate:“100” cni.iaas.yusur.io/egress_rate:“200” eth1.iaas.yusur.io/ingress_rate:“500”

如上所示，這個pod將會有兩個網(wǎng)卡，默認(rèn)網(wǎng)卡eth0和次網(wǎng)卡eth1，次網(wǎng)卡使用vf直通網(wǎng)卡。主網(wǎng)卡加入默認(rèn)子網(wǎng)ovn-default，次網(wǎng)卡加入subnet1。主網(wǎng)卡將由系統(tǒng)分配一個ip地址，而次網(wǎng)卡將使用事先創(chuàng)建好的vnicip-1的ip地址。主網(wǎng)卡出向限速為200Mbps，入向限速100Mbps，而次網(wǎng)卡出向不限速，入向限速為500Mbps。

2.2.7.kube-proxy平替

kube-proxy是Kubernetes工作節(jié)點上的網(wǎng)絡(luò)代理組件，它實現(xiàn)了Kubernetes service概念的一部分功能，主要工作原理是通過ipvs或iptables為service配置負載均衡規(guī)則，將發(fā)往service的流量負載均衡到后端pod。原理如下：

基于這種方式，在對service進行訪問時，流量都通過host側(cè)的cpu進行處理，由于kubenetes上會有大量的service的訪問，會導(dǎo)致host側(cè)消耗較多的cpu資源用于流量處理。我們希望將這部分流量也卸載到DPU中，因此我們在馭云SDN中提供了基于dpu卸載加速的service能力，代替掉kube-proxy組件，避免了這類cpu資源消耗。馭云SDN提供的方案如下圖所示：

控制面流程如下：

ycloud-cni對所有節(jié)點配置路由或者策略路由，將所有訪問service的流量送到ovn/ovs。

ycloud-controller 為每個vpc都創(chuàng)建不同類型的lb，如udp lb/tcp lb。同時watch service和endpoints資源，為每個屬于自己vpc的service，在對應(yīng)lb中創(chuàng)建vip，為service中的endpoints，在vip中配置ip。并將這些lb綁定到vpc下所有subnet。

數(shù)據(jù)面流程如下:

訪問service的流量都走到dpu側(cè)，進入ovn/ovs

流量進入subnet，通過service-ip匹配到subnet綁定的lb的vip

通過lb，負載均衡到vip的ips中的某一個，也就是真實的后端ip

2.2.8.network-agent

由于馭云SDN引入了VPC，而VPC之間的網(wǎng)絡(luò)是相互隔離的，這就會導(dǎo)致在某些場景下網(wǎng)絡(luò)通訊出現(xiàn)問題，比如下面的場景：

iaas服務(wù)訪問租戶資源，比如健康檢查需要能夠訪問到租戶資源。

租戶資源訪問iaas服務(wù)，比如api-server，coredns等。

開源CNI方案，還沒有看到有組件能同時解決上述問題，對此馭云SDN提供了network-agent方案，通過一個組件解決上述問題。該組件以deamonset方式在每個node部署了一個network-agnet的pod，只為本地pod進行服務(wù)，如檢測本地節(jié)點上的pod健康狀態(tài)，為本地節(jié)點上不同vpc內(nèi)的pod提供訪問k8s service如api-server，coredns等服務(wù)的支持。該組件基于mark，策略路由，snat和ovn 的localport來實現(xiàn)上述功能。

2.2.9.qos

在我們馭云系統(tǒng)中的云資源，比如pod/vm/eip，支持通過qos對流量進行限速。對于EIP的限速，是基于ovn 提供的qos實現(xiàn)的，在此不做描述。對于有獨立vnic的pod云資源，我們是通過對ovs來進行限速，但是對于使用共享網(wǎng)卡的pod來說，由于沒有獨立的vnic，我們是直接通過tc對其進行限速，這兩種限速實現(xiàn)方式不同，但是底層原理其實是一致的。比如對于擁有獨立vnic的pod，其在ovs上有對應(yīng)網(wǎng)卡，因此可以利用ovs提供的方式對其進行ingress/egress方向的限速，如圖所示：

pod的egress限速，對應(yīng)著其ovs網(wǎng)卡的ingress，而pod的ingress限速，則對應(yīng)其ovs網(wǎng)卡的egress。比如為pod配置egress限速10Mbps和ingress限速4Mbps就可以通過下面方式：

??# pod egress????限速????10Mbps?? ??ovs-vsctl setinterface$interfaceName ingress_policing_rate=10000ingress_policing_burst=10000?? ??# pod ingress????限速4Mbps?? ??ovs-vsctl set port $portName qos=@newqos-- ?? ??--id=@newqoscreate qos type=linux-htb queues=0=@q0-- ?? ??--id=@q0create queue other-config:max-rate=4000000??

對于使用共享網(wǎng)卡的pod來說，通過在cni-share中的veth上配置tc規(guī)則來進行ingress/egress方向的限速。pod的egress限速，對應(yīng)著cni-share中相應(yīng)veth網(wǎng)卡的ingress，而pod的ingress限速，則對應(yīng)著cni-share中相應(yīng)veth網(wǎng)卡的egress。而由于在cni-share中的veth的ingress方向，隊列功能很簡單，不可指定復(fù)雜的隊列規(guī)則，因此我們采取將其ingress隊列的流量重定向到對應(yīng)的虛擬ifb設(shè)備上，然后對虛擬ifb設(shè)備通過tc配置HTB隊列，實現(xiàn)對veth輸入流量（對應(yīng)pod出向）復(fù)雜的隊列規(guī)則。

pod限速的用法如下，支持對每個網(wǎng)卡進行分別限速。

annotations: k8s.v1.cni.cncf.io/networks: yusur-vf@eth1 cni.iaas.yusur.io/ingress_rate:“100” cni.iaas.yusur.io/egress_rate:“200” eth1.iaas.yusur.io/ingress_rate:“500”

如上圖所示，對主網(wǎng)卡出向限速為200Mbps，入向限速100Mbps，而次網(wǎng)卡eth1出向不限速，入向限速為500Mbps。

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

3.1. 功能測試結(jié)果

3.1.1.共享網(wǎng)卡

pod1指定安置在host上，默認(rèn)就是使用共享網(wǎng)卡（pf0vf0），所以其沒有vnic，只有vnicip，這個vnicip是自動生成的，和共享vnic進行了綁定，網(wǎng)絡(luò)能通。

3.1.2.獨享網(wǎng)卡

對于pod2這種獨享網(wǎng)卡，有單獨vnic和vnicip，在本例中是系統(tǒng)生成。網(wǎng)絡(luò)能通。

3.1.3.多網(wǎng)卡

對于pod3獨享網(wǎng)卡eth1和eth2會有自己的vnic和vnicip，共享網(wǎng)卡eth0只有vnicip。如下圖所示：

vnic：pod3.eth1和pod3.eth2就是pod3獨享網(wǎng)卡，也就是次網(wǎng)卡eth1和eth2對應(yīng)的vnic，而vnicip：pod3.eth1和pod3.eth2就是其對應(yīng)的vnicip，本例pod3由于沒有手動配置pod網(wǎng)卡的vnic和vnicip，因此其對應(yīng)的vnic和vnicip由系統(tǒng)自動分配。

3.1.4.NAT

查看創(chuàng)建的eip和nat資源狀態(tài)，如下所示：

云外網(wǎng)絡(luò)就可以通過這個eip地址100.64.2.2來訪問這個pod，pod也通過這個eip訪問云外網(wǎng)絡(luò)。

3.1.5.SNAT

查看創(chuàng)建的eip和snat資源狀態(tài)，如下所示：

這個vpc內(nèi)的pod都可以訪問云外網(wǎng)絡(luò)。云外網(wǎng)絡(luò)不能主動通過這個eip去訪問vpc中的云資源。

3.1.6.安全組

綁定安全組sg-example的pod：pod-sg能夠訪問10.16.1.213，不能訪問10.16.1.207，因為安全組對目標(biāo)ip是10.16.1.213的流量放行，對目標(biāo)ip是10.16.1.207的流量丟棄。

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

馭云CNI支持帶DPU/SmartNic這種卸載環(huán)境，也支持不帶這種卡的非卸載環(huán)境，不帶DPU/SmartNic的非卸載環(huán)境，pod只能使用veth這種非直通網(wǎng)卡，帶DPU/SmartNic的卸載環(huán)境，pod支持使用VF/SF/veth等類型的網(wǎng)卡。對比卸載環(huán)境和非卸載環(huán)境上pod的帶寬，pps和延時三種性能指標(biāo)。

3.2.1.Pod的帶寬

帶寬單位Gbits/s。

	測試用例	網(wǎng)卡類型	馭云（卸載環(huán)境）	馭云（非卸載環(huán)境）
1	物理節(jié)點之間基準(zhǔn)測試	150		150
2	Pod與本地物理節(jié)點	vf	140	無
		sf	140
		共享網(wǎng)卡	130
		veth	450	450
3	Pod與遠端物理節(jié)點	vf	154	無
		sf	162
		共享網(wǎng)卡	168
		veth	60	60
4	同物理節(jié)點的不同Pod	vf	144	無
		sf	140
		共享網(wǎng)卡	476
		veth	450	420
5	跨物理節(jié)點的Pod	vf	142	無
		sf	140
		共享網(wǎng)卡	135
		veth	60	60

從上面測試數(shù)據(jù)得出以下結(jié)論：

1.使用VF/SF/共享網(wǎng)卡的pod能夠達到接近物理機的帶寬。

2.從常用場景上看，馭云SDN在卸載情況下在帶寬上性能提升了2-3倍左右。

3.卸載環(huán)境上使用和不卸載環(huán)境一樣的veth類型網(wǎng)卡，性能差不多。

4.veth中配置了tcp-segmentation-offload（TSO），veth虛擬設(shè)備驅(qū)動會處理更大的不被分片的報文，tcp具有非常好的性能。因此veth類型的pod與本地物理節(jié)點間，同物理節(jié)點的veth pod間，同物理節(jié)點上共享網(wǎng)卡的pod間，這三種測試帶寬非常大。而vf和sf在同節(jié)點訪問時，經(jīng)由物理網(wǎng)卡進行轉(zhuǎn)發(fā)，因此受到網(wǎng)卡帶寬限制。

3.2.2.Pod的pps

pps單位為Mpps。

	測試用例	網(wǎng)卡類型	馭云（卸載環(huán)境）	馭云（非卸載環(huán)境）
1	物理節(jié)點之間基準(zhǔn)測試	30		30
2	Pod與本地物理節(jié)點	vf	27	無
		sf	24
		共享網(wǎng)卡	23
		veth	3.2	3.2
3	Pod與遠端物理節(jié)點	vf	27	無
		sf	26
		共享網(wǎng)卡	27
		veth	4	4
4	同物理節(jié)點的不同Pod	vf	22	無
		sf	20
		共享網(wǎng)卡	2
		veth	2.2	2.5
5	跨物理節(jié)點的Pod	vf	29
		sf	26
		共享網(wǎng)卡	25
		veth	4	4

從下面數(shù)據(jù)得出以下結(jié)論：

1. 使用VF/SF網(wǎng)卡的pod能夠達到接近物理機性能的pps。

2. 從常用場景上看，馭云SDN在卸載情況下在pps上性能提升了8倍左右。

3.在同物理節(jié)點的測試中，使用共享網(wǎng)卡的pod，由于veth使用了65535的大包，因此pps統(tǒng)計更低。

3.2.3.Pod的延時

延時單位為us。

	測試用例	網(wǎng)卡類型	馭云（卸載環(huán)境）	馭云（非卸載環(huán)境）
1	物理節(jié)點之間基準(zhǔn)測試	36		36
2	Pod與本地物理節(jié)點	vf	30	無
		sf	30
		共享網(wǎng)卡	37
		veth	13.2	14
3	Pod與遠端物理節(jié)點	vf	36	無
		sf	36
		共享網(wǎng)卡	40
		veth	50	65
4	同物理節(jié)點的不同Pod	vf	30	無
		sf	30
		共享網(wǎng)卡	17
		veth	12	14.5
5	跨物理節(jié)點的Pod	vf	35	無
		sf	35
		共享網(wǎng)卡	180
		veth	65	70

從上面測試數(shù)據(jù)得出以下結(jié)論：

1.使用VF/SF網(wǎng)卡的pod能夠達到接近物理機性能的時延。

2.跨節(jié)點使用共享網(wǎng)卡pod之間，由于會走本地協(xié)議棧，因此時延會高一點。

3. 卸載環(huán)境上使用和不卸載環(huán)境一樣的veth類型網(wǎng)卡，時延差不多。

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

與傳統(tǒng)的CNI方案相比，馭云SDN展現(xiàn)出的顯著優(yōu)勢可以概括如下：

1. 高性能網(wǎng)絡(luò)卸載：

?馭云SDN充分利用DPU和SmartNIC硬件資源，通過PF（Physical Function）、SF（Sub function）、VF（Virtual Function）、VFIO和vDPA等技術(shù)，直通給容器或虛擬機，實現(xiàn)網(wǎng)絡(luò)功能的硬件卸載，從而達到接近物理機的網(wǎng)絡(luò)性能。相較于未卸載場景，帶寬提升可達2-3倍，PPS（Packets Per Second）性能提升約8倍，顯著增強了網(wǎng)絡(luò)處理能力。

2. 創(chuàng)新性解決方案：

?馭云SDN融合了Kubernetes的網(wǎng)絡(luò)架構(gòu)和傳統(tǒng)的IaaS網(wǎng)絡(luò)服務(wù)，如VPC、安全組、EIP等服務(wù)，滿足了云服務(wù)提供商和企業(yè)客戶的網(wǎng)絡(luò)運營需求。

?創(chuàng)新性地解決了IaaS領(lǐng)域中硬件資源限制與用戶需求之間的矛盾，通過共享網(wǎng)卡方案，平衡了資源分配與用戶需求，提升了資源利用率。

?基于OVN的EIP和EIP-Gateway方案，有效解決了復(fù)雜場景下用戶的EIP需求，提升了網(wǎng)絡(luò)靈活性和適應(yīng)性。

?多網(wǎng)卡方案簡化了用戶在多網(wǎng)卡配置上的復(fù)雜性，提升了運維效率。

?kube-proxy平替方案實現(xiàn)了Service流量的卸載，優(yōu)化了服務(wù)訪問路徑，提升了服務(wù)的響應(yīng)速度和穩(wěn)定性。

?network-agent方案解決了多租戶VPC場景下的健康檢查和訪問Service需求，增強了網(wǎng)絡(luò)的健壯性和用戶體驗。

?QoS方案實現(xiàn)了Pod和EIP流量的限速，確保了網(wǎng)絡(luò)資源的公平分配，提升了整體網(wǎng)絡(luò)服務(wù)質(zhì)量。

3. 豐富行業(yè)生態(tài)：

?在Kubernetes生態(tài)中，基于DPU/SmartNIC的CNI方案相對缺乏，馭云SDN解決方案豐富了該類CNI方案的選項，滿足了云原生環(huán)境對高性能和IaaS SDN網(wǎng)絡(luò)的需求，為云服務(wù)提供商和企業(yè)客戶提供了更加豐富的網(wǎng)絡(luò)解決方案。

4. 高度靈活性與可擴展性：

?通過抽象出NIC（Network Interface Card）、vNIC（Virtual Network Interface Card）、vNIC IP資源，馭云SDN為后續(xù)網(wǎng)絡(luò)功能的擴展提供了接口，增強了SDN的靈活性和可擴展性，能夠更好地適應(yīng)未來網(wǎng)絡(luò)技術(shù)的發(fā)展和業(yè)務(wù)需求的變化。

綜上所述，馭云SDN不僅在性能上顯著提升，而且在功能上提供了創(chuàng)新性的解決方案，滿足了云計算環(huán)境下對IaaS SDN網(wǎng)絡(luò)的高要求，為業(yè)務(wù)的高效運行和用戶體驗的提升提供了堅實的基礎(chǔ)。

審核編輯 黃宇