1. 方案背景與挑戰

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

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

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

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

2. 方案介紹

2.1. 整體架構

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

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

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

ycloud-controller，該組件執行Kubernetes內資源到ovn資源的翻譯工作，是SDN系統的控制平面，也相當于ovn的cms云管理系統。其監聽所有和網絡相關資源的事件，并根據資源變化情況更新ovn內的邏輯網絡。

ycloud，一個二進制程序，作為kubelet和ycloud-cni之間的交互工具，將相應的CNI請求發給ycloud-cni執行。

ycloud-cni，該組件作為一個DaemonSet運行在每個節點上，實現CNI接口，并監聽api-server配置本地網絡，其會根據工作模式做相應的網絡配置，工作模式有以下幾種：

Default模式： ycloud-cni的默認工作模式，master和帶SmartNic卡的Host節點中的ycloud-cni均工作于此模式。在該模式下，會對安置在其上的容器配置完整的虛擬網絡配置，如容器網絡和ovs網絡。

DPU模式：DPU節點中的ycloud-cni工作于此模式。在該模式下，會對安置在DPU內的容器配置完整的虛擬網絡配置。而對安置在其Host的容器，會配置ovs網絡。

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

基于上述的軟件架構，馭云SDN通過結合Kubernetes的能力，OVN控制器的能力，OpenVSwitch網絡功能/卸載能力，DPU/SmartNic硬件能力，實現符合Kubernetes CNI標準規范，充分發揮DPU/SmartNic的硬件潛力，深度整合云計算IAAS等這些目標，為云計算在追求極致網絡性能上提供了新的云原生SDN解決方案。

2.2. 方案描述

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

2.2.1.核心資源

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

nic，對應Kubernetes中的pod在linux系統中的某個網卡，類型可以是pf/vf/sf/veth，由系統根據用戶要求自動創建和刪除。

vnic，對應一個邏輯網卡，即ovn的logical_switch_port，是虛擬網絡的接口，可以是用戶自動創建，也可以是系統自動生成。由系統自動和pod的nic進行綁定，綁定后，pod就加入到vnic對應的虛擬網絡。

vnicip，對應一個邏輯ip，即ovn的logical_switch_port中的ip地址，由系統自動和vnic進行綁定，eip也是和vnicip進行綁定實現云上資源訪問外網需求的。

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

2.2.2.vpc和subnet

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

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

2.2.3.eip和eip-gateway

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

綁定vpc，為vpc內的云資源提供公網出口;

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

綁定負載均衡器，云外網絡訪問服務的流量分發到后端的多臺服務器

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

snat，對應ovn nat規則的snat類型，實現eip綁定給vpc。

nat，對應ovn nat規則的dnat_and_snat，實現eip綁定給云服務器（基于vnicip）。

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

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

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

2.2.4.安全組

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

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

下行規則：未配置的下行規則和端口默認拒絕訪問，安全組默認配置以下下行規則

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

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

行為	優先級	協議	端口	源/目標地址	說明
接受	96	ALL	ALL	組內IP組	容許組內互信（前提：安全組設置組內互信）
接受	97	ALL	ALL	ALL	默認接受

2.2.5.共享網卡

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

為實現共享網卡方案，工作于Host模式的CNI在初始化階段將會為Host創建以下資源：

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

一個共享network namespace：共享vnic對應的pf0vf0會加入到該netns，在里會通過路由、策略路由、arp代答等規則完成共享網絡的路由轉發等功能

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

2.2.6.多網卡

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

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

支持指定網卡類型，如veth/vf/sf/vdpa

支持指定網卡加入的subnet

支持指定網卡ip地址

支持配置網卡路由

支持網卡限速

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

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將會有兩個網卡，默認網卡eth0和次網卡eth1，次網卡使用vf直通網卡。主網卡加入默認子網ovn-default，次網卡加入subnet1。主網卡將由系統分配一個ip地址，而次網卡將使用事先創建好的vnicip-1的ip地址。主網卡出向限速為200Mbps，入向限速100Mbps，而次網卡出向不限速，入向限速為500Mbps。

2.2.7.kube-proxy平替

kube-proxy是Kubernetes工作節點上的網絡代理組件，它實現了Kubernetes service概念的一部分功能，主要工作原理是通過ipvs或iptables為service配置負載均衡規則，將發往service的流量負載均衡到后端pod。原理如下：

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

控制面流程如下：

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

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

數據面流程如下:

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

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

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

2.2.8.network-agent

由于馭云SDN引入了VPC，而VPC之間的網絡是相互隔離的，這就會導致在某些場景下網絡通訊出現問題，比如下面的場景：

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

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

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

2.2.9.qos

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

pod的egress限速，對應著其ovs網卡的ingress，而pod的ingress限速，則對應其ovs網卡的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??

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

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

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”

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

3. 方案測試結果

3.1. 功能測試結果

3.1.1.共享網卡

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

3.1.2.獨享網卡

對于pod2這種獨享網卡，有單獨vnic和vnicip，在本例中是系統生成。網絡能通。

3.1.3.多網卡

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

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

3.1.4.NAT

查看創建的eip和nat資源狀態，如下所示：

云外網絡就可以通過這個eip地址100.64.2.2來訪問這個pod，pod也通過這個eip訪問云外網絡。

3.1.5.SNAT

查看創建的eip和snat資源狀態，如下所示：

這個vpc內的pod都可以訪問云外網絡。云外網絡不能主動通過這個eip去訪問vpc中的云資源。

3.1.6.安全組

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

3.2. 性能測試結果

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

3.2.1.Pod的帶寬

帶寬單位Gbits/s。

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

從上面測試數據得出以下結論：

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

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

3.卸載環境上使用和不卸載環境一樣的veth類型網卡，性能差不多。

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

3.2.2.Pod的pps

pps單位為Mpps。

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

從下面數據得出以下結論：

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

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

3.在同物理節點的測試中，使用共享網卡的pod，由于veth使用了65535的大包，因此pps統計更低。

3.2.3.Pod的延時

延時單位為us。

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

從上面測試數據得出以下結論：

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

2.跨節點使用共享網卡pod之間，由于會走本地協議棧，因此時延會高一點。

3. 卸載環境上使用和不卸載環境一樣的veth類型網卡，時延差不多。

4. 優勢總結

與傳統的CNI方案相比，馭云SDN展現出的顯著優勢可以概括如下：

1. 高性能網絡卸載：

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

2. 創新性解決方案：

?馭云SDN融合了Kubernetes的網絡架構和傳統的IaaS網絡服務，如VPC、安全組、EIP等服務，滿足了云服務提供商和企業客戶的網絡運營需求。

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

?基于OVN的EIP和EIP-Gateway方案，有效解決了復雜場景下用戶的EIP需求，提升了網絡靈活性和適應性。

?多網卡方案簡化了用戶在多網卡配置上的復雜性，提升了運維效率。

?kube-proxy平替方案實現了Service流量的卸載，優化了服務訪問路徑，提升了服務的響應速度和穩定性。

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

?QoS方案實現了Pod和EIP流量的限速，確保了網絡資源的公平分配，提升了整體網絡服務質量。

3. 豐富行業生態：

?在Kubernetes生態中，基于DPU/SmartNIC的CNI方案相對缺乏，馭云SDN解決方案豐富了該類CNI方案的選項，滿足了云原生環境對高性能和IaaS SDN網絡的需求，為云服務提供商和企業客戶提供了更加豐富的網絡解決方案。

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

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

綜上所述，馭云SDN不僅在性能上顯著提升，而且在功能上提供了創新性的解決方案，滿足了云計算環境下對IaaS SDN網絡的高要求，為業務的高效運行和用戶體驗的提升提供了堅實的基礎。

審核編輯 黃宇