基于DPU与SmartNic的云原生SDN解决方案

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网络的高要求，为业务的高效运行和用户体验的提升提供了坚实的基础。

审核编辑 黄宇