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来说，通过在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网络的高要求，为业务的高效运行和用户体验的提升提供了坚实的基础。
本方案来自于中科驭数软件研发团队，团队核心由一群在云计算、数据中心架构、高性能计算领域深耕多年的业界资深架构师和技术专家组成，不仅拥有丰富的实战经验，还对行业趋势具备敏锐的洞察力，该团队致力于探索、设计、开发、推广可落地的高性能云计算解决方案，帮助最终客户加速数字化转型，提升业务效能，同时降低运营成本。更多内容敬请访问yusur.tech。
