基于DPU与SmartNIC的K8s Service解决方案

1.  方案背景

1.1. Kubernetes Service介绍

Kubernetes Service是Kubernetes中的一个核心概念，它定义了一种抽象，用于表示一组提供相同功能的Pods（容器组）的逻辑集合，并提供了一种方式让这些Pods能够被系统内的其他组件发现并访问。简单来说，Service提供了一种让客户端能够稳定地连接到后端Pods的机制，即使这些Pods会动态地创建、销毁或迁移。

Kubernetes Service主要特性和用途

服务发现：Service允许客户端（如Pods中的应用程序）通过稳定的IP地址和端口号访问后端Pods集合，而无需关心实际Pod的IP地址或端口号，因为这些信息可能会因为Pod的重启或迁移而改变。

负载均衡：Kubernetes会自动在Service后面创建的Pods之间分配进入的流量，实现了简单的负载均衡。这意味着当多个Pods提供了相同的服务时，客户端的请求可以被均衡地分发到这些Pods上。

支持DNS：Kubernetes支持基于DNS的服务发现，允许Pods通过服务名（而不是IP地址）来相互通信。这大大简化了服务之间的调用和依赖关系的管理。

定义服务类型：Service可以有多种类型，最常见的是ClusterIP（默认，仅集群内部可访问）、NodePort（通过集群中每个节点的静态端口暴露服务）、LoadBalancer（在Cloud环境中，使用云提供商的负载均衡器暴露服务）和ExternalName（将服务映射到DNS名称，而不是选择Pods）。

在Kubernetes集群中，kube-proxy作为Service的代理组件，负责实现集群内部及外部对Service的访问。kube-proxy通过监听Kubernetes API Server中的Service和Endpoint资源变化，动态地在每个节点上配置网络规则，确保对Service的请求能够被正确地路由到后端的Pod实例上。

在iptables 模式下，kube-proxy会在每个节点上通过iptables规则来实现请求的转发。它会创建一系列的iptables规则，这些规则根据Service的IP和端口，将访问Service的流量重定向到后端的Pod IP和端口上。这种方式简单直接，但随着Service和Pod数量的增加，iptables规则会急剧膨胀，影响性能。

作为iptables的改进，ipvs（IP Virtual Server）模式提供了更高的性能和更好的扩展性。ipvs使用更高效的哈希表来管理网络规则，可以更快地查找和转发流量。这使得在大规模集群中，Service的访问性能得到显著提升。

1.2. 问题与挑战

尽管kube-proxy在大多数基础场景中表现良好，但它也存在一些明显的局限性：

1、场景简单：kube-proxy主要适用于简单的网络拓扑结构，对于复杂的IaaS（Infrastructure as a Service）场景，如需要支持VPC（Virtual Private Cloud）网络隔离、灵活的EIP（Elastic IP）使用等高级网络功能时，显得力不从心。

2、性能瓶颈：由于kube-proxy的报文转发完全依赖于软件实现（无论是iptables还是ipvs），这意味着它无法利用现代硬件（如DPU、SmartNIC）进行网络加速，在高负载跨节点转发的情况下，这种软件实现的性能瓶颈尤为明显。

3、资源消耗：基于软件实现的Kubernetes Service，在高负载跨节点转发的情况下会导致CPU资源消耗过高，从而影响整体系统的稳定性和性能。

与kube-proxy相似，许多开源的容器网络接口（CNI）插件，如使用Open vSwitch（OVS）的kube-ovn、Antrea等，通常依赖于自己的数据面处理机制来转发Service网络流量，在没有硬件加速的情况下，也面临类似的性能瓶颈和资源消耗问题。

2. 方案介绍

2.1. 整体架构

本方案基于DPU&SmartNIC实现了Kubernetes Service的解决方案，简称“驭云Service”。

驭云Service在驭云SDN的架构中实现，其中驭云SDN通过ovn/ovs机制将DPU&SmartNIC加入到同一个ovn集群，对网络进行统一的虚拟化，整体物理架构图如所示:

在Pod/裸机/VM接入DPU卡或SmartNIC卡后，用户的请求由Service处理后送往对应的Pod/裸机/VM。

软件整体架构如下：

如图所示，驭云Service基于驭云SDN，上图各个组件中均会参与处理Service的逻辑，下面分别进行介绍：

ycloud-controller，是SDN系统的控制平面，处理Service的主要逻辑，将用户创建的Service数据通过ovn转换成实际的网络拓扑。

yusurService-controller，处理用户创建的YusurService资源，翻译成内置Service资源给ycloud-controller使用。

ycloud-cni，该组件作为一个DaemonSet运行在每个节点上，是SDN的CNI接口，同时也会负责各个节点上Service的一些处理逻辑。

注：驭云SDN参见《基于DPU与SmartNIC的云原生SDN解决方案》

2.2. 方案描述

在驭云SDN的概念中，所有后端资源，无论是Pod、VM还是裸金属服务器，都属于某一个VPC（虚拟私有云）。VPC实现了逻辑隔离的网络空间，这意味着不同VPC内的网络流量不会相互干扰，这提供了重要的安全边界，同时也便于多租户环境中的资源管理和隔离。然而，这种隔离也带来了一个挑战：如何允许不同VPC之间或者外部网络访问这些VPC内的资源。

Service需要解决的就是从不同地方经过Service访问到这些VPC内的资源，并且根据策略进行请求的负载均衡。在驭云Service中，具体包含以下场景：

集群内部互通（ClusterIP类型Service）

场景①：客户端在集群VPC内，访问同VPC下的后端服务：

在这种情况下，客户端可以直接通过Service的ClusterIP访问后端服务。ClusterIP是一种虚拟IP地址，由Kubernetes为Service分配，只在集群内部可见。流量在VPC内直接转发，无需经过额外的网关或负载均衡器。

场景②：客户端在集群节点上，访问默认VPC下的一组后端服务：

当客户端运行在集群节点上时，它同样可以通过ClusterIP访问服务。Kubernetes的网络策略确保流量在节点和后端服务之间正确路由。这种访问方式同样限于集群内部，不需要EIP。

集群外部访问集群内（LoadBalancer类型Service）

场景③：客户端在集群外部，通过EIP访问一个VPC下的一组后端服务：

在此场景下，客户端通过云外访问集群内的服务。Loa