基于DPU與SmartNic的云原生SDN解決方案

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

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

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

2、硬件支持不足：當(dāng)前的Kubernetes CNI插件普遍缺乏對(duì)智能網(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實(shí)現(xiàn)硬件流量卸載等功能。

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

2.? 方案介紹

2.1. 整體架構(gòu)

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

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

如圖所示，馭云SDN是基于Kubernetes，將master節(jié)點(diǎn)，dpu卡，Host都作為node加入k8s集群，這些node上運(yùn)行著馭云SDN的相關(guān)組件，下面分別進(jì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，一個(gè)二進(jìn)制程序，作為kubelet和ycloud-cni之間的交互工具，將相應(yīng)的CNI請(qǐng)求發(fā)給ycloud-cni執(zhí)行。
• ycloud-cni，該組件作為一個(gè)DaemonSet運(yùn)行在每個(gè)節(jié)點(diǎn)上，實(shí)現(xiàn)CNI接口，并監(jiān)聽api-server配置本地網(wǎng)絡(luò)，其會(huì)根據(jù)工作模式做相應(yīng)的網(wǎng)絡(luò)配置，工作模式有以下幾種：
• Default模式： ycloud-cni的默認(rèn)工作模式，master和帶SmartNic卡的Host節(jié)點(diǎn)中的ycloud-cni均工作于此模式。在該模式下，會(huì)對(duì)安置在其上的容器配置完整的虛擬網(wǎng)絡(luò)配置，如容器網(wǎng)絡(luò)和ovs網(wǎng)絡(luò)。
• DPU模式：DPU節(jié)點(diǎn)中的ycloud-cni工作于此模式。在該模式下，會(huì)對(duì)安置在DPU內(nèi)的容器配置完整的虛擬網(wǎng)絡(luò)配置。而對(duì)安置在其Host的容器，會(huì)配置ovs網(wǎng)絡(luò)。
• Host模式：帶DPU卡的Host節(jié)點(diǎn)中的ycloud-cni工作于此模式。在該模式下，只會(huì)去配置容器網(wǎng)絡(luò)，而對(duì)應(yīng)的底層網(wǎng)絡(luò)如ovs網(wǎng)絡(luò)，則交由其對(duì)應(yīng)DPU上工作在DPU模式的ycloud-cni完成。

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

2.2. 方案描述

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

2.2.1.??核心資源

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

• nic，對(duì)應(yīng)Kubernetes中的pod在linux系統(tǒng)中的某個(gè)網(wǎng)卡，類型可以是pf/vf/sf/veth，由系統(tǒng)根據(jù)用戶要求自動(dòng)創(chuàng)建和刪除。
• vnic，對(duì)應(yīng)一個(gè)邏輯網(wǎng)卡，即ovn的logical_switch_port，是虛擬網(wǎng)絡(luò)的接口，可以是用戶自動(dòng)創(chuàng)建，也可以是系統(tǒng)自動(dòng)生成。由系統(tǒng)自動(dòng)和pod的nic進(jìn)行綁定，綁定后，pod就加入到vnic對(duì)應(yīng)的虛擬網(wǎng)絡(luò)。
• vnicip，對(duì)應(yīng)一個(gè)邏輯ip，即ovn的logical_switch_port中的ip地址，由系統(tǒng)自動(dòng)和vnic進(jìn)行綁定，eip也是和vnicip進(jìn)行綁定實(shí)現(xiàn)云上資源訪問外網(wǎng)需求的。

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

2.2.2.??vpc和subnet

vpc（virtual private cloud）是一種基于云計(jì)算的網(wǎng)絡(luò)服務(wù)，它允許用戶在云中創(chuàng)建一個(gè)邏輯上的隔離網(wǎng)絡(luò)環(huán)境，用戶可以在這個(gè)環(huán)境中啟動(dòng)虛擬機(jī)、存儲(chǔ)、數(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會(huì)加入這個(gè)vpc，如馭云SDN系統(tǒng)組件。租戶vpc之間是完全隔離的。pod與pod，node與pod之間通信，流量將會(huì)卸載到dpu/smartnic。網(wǎng)絡(luò)模型如下:

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

2.2.3.??eip和eip-gateway

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

• 綁定vpc，為vpc內(nèi)的云資源提供公網(wǎng)出口;
• 綁定云服務(wù)器，為云服務(wù)器提供公網(wǎng)服務(wù)或云服務(wù)器對(duì)外提供公網(wǎng)服務(wù)。云服務(wù)器包含容器，虛擬機(jī)，裸金屬;
• 綁定負(fù)載均衡器，云外網(wǎng)絡(luò)訪問服務(wù)的流量分發(fā)到后端的多臺(tái)服務(wù)器

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

• snat，對(duì)應(yīng)ovn nat規(guī)則的snat類型，實(shí)現(xiàn)eip綁定給vpc。
• nat，對(duì)應(yīng)ovn nat規(guī)則的dnat_and_snat，實(shí)現(xiàn)eip綁定給云服務(wù)器（基于vnicip）。
• loadbalancer：實(shí)現(xiàn)eip綁定給負(fù)載均衡器，這個(gè)負(fù)載均衡器是4層service。

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

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

2.2.4.??安全組

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

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

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

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

2.2.5.??共享網(wǎng)卡

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

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

• 一個(gè)共享vnic：vnic會(huì)綁定到一個(gè)單獨(dú)的nic，默認(rèn)為pf0vf0;
• 一個(gè)共享network namespace：共享vnic對(duì)應(yīng)的pf0vf0會(huì)加入到該netns，在里會(huì)通過路由、策略路由、arp代答等規(guī)則完成共享網(wǎng)絡(luò)的路由轉(zhuǎn)發(fā)等功能

當(dāng)創(chuàng)建一個(gè)使用共享網(wǎng)卡的pod時(shí)，如果pod沒有指定vnicip，那么系統(tǒng)會(huì)為這個(gè)pod分配一個(gè)vnicip，然后將pod的vnicip綁定到共享vnic，同時(shí)為pod創(chuàng)建veth-pair設(shè)備，一端加入pod自己的netns，一端放入nic-share中，nic-share中為這個(gè)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ù)器配備兩個(gè)或更多的網(wǎng)卡可以帶來多種網(wǎng)絡(luò)設(shè)計(jì)上的優(yōu)勢(shì)，包括但不限于網(wǎng)絡(luò)分離，負(fù)載均衡，高可用性。與其他CNI一樣，馭云SDN也能基于multus向pod提供多網(wǎng)卡功能，如下圖所

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

• 支持指定網(wǎng)卡類型，如veth/vf/sf/vdpa
• 支持指定網(wǎng)卡加入的subnet
• 支持指定網(wǎng)卡ip地址
• 支持配置網(wǎng)卡路由
• 支持網(wǎng)卡限速

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

如上所示，這個(gè)pod將會(huì)有兩個(gè)網(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)分配一個(gè)ip地址，而次網(wǎng)卡將使用事先創(chuàng)建好的vnicip-1的ip地址。主網(wǎng)卡出向限速為200Mbps，入向限速100Mbps，而次網(wǎng)卡出向不限速，入向限速為500Mbps。

2.2.7.??kube-proxy平替

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

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

控制面流程如下：

• ycloud-cni對(duì)所有節(jié)點(diǎn)配置路由或者策略路由，將所有訪問service的流量送到ovn/ovs。
• ycloud-controller 為每個(gè)vpc都創(chuàng)建不同類型的lb，如udp lb/tcp lb。同時(shí)watch service和endpoints資源，為每個(gè)屬于自己vpc的service，在對(duì)應(yīng)lb中創(chuàng)建vip，為service中的endpoints，在vip中配置ip。并將這些lb綁定到vpc下所有subnet。

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

• 訪問service的流量都走到dpu側(cè)，進(jìn)入ovn/ovs
• 流量進(jìn)入subnet，通過service-ip匹配到subnet綁定的lb的vip
• 通過lb，負(fù)載均衡到vip的ips中的某一個(gè)，也就是真實(shí)的后端ip

2.2.8.??network-agent

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

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

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

2.2.9.??qos

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

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

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

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

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

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

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

3.1.1.??共享網(wǎng)卡

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

3.1.2.??獨(dú)享網(wǎng)卡

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

3.1.3.??多網(wǎng)卡

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

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

3.1.4.??NAT

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

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

3.1.5.??SNAT

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

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

3.1.6.??安全組

綁定安全組sg-example的pod：pod-sg能夠訪問10.16.1.213，不能訪問10.16.1.207，因?yàn)榘踩M對(duì)目標(biāo)ip是10.16.1.213的流量放行，對(duì)目標(biāo)ip是10.16.1.207的流量丟棄。

3.2. 性能測(cè)試結(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)卡。對(duì)比卸載環(huán)境和非卸載環(huán)境上pod的帶寬，pps和延時(shí)三種性能指標(biāo)。

3.2.1.??Pod的帶寬

帶寬單位Gbits/s。

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

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

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

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

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

3.2.2.??Pod的pps

pps單位為Mpps。

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

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

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

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

3.2.3.??Pod的延時(shí)

延時(shí)單位為us。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. 高度靈活性與可擴(kuò)展性：

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

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

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