专业做网站的公司 郑州,适合个人做的外贸平台,网站建设横条,wordpress本地环境转移1. 方案背景
1.1. Kubernetes Service介绍
Kubernetes Service是Kubernetes中的一个核心概念#xff0c;它定义了一种抽象#xff0c;用于表示一组提供相同功能的Pods#xff08;容器组#xff09;的逻辑集合#xff0c;并提供了一种方式让这些Pods能够被系统内的其他组…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上。
支持DNSKubernetes支持基于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的改进ipvsIP Virtual Server模式提供了更高的性能和更好的扩展性。ipvs使用更高效的哈希表来管理网络规则可以更快地查找和转发流量。这使得在大规模集群中Service的访问性能得到显著提升。
1.2. 问题与挑战
尽管kube-proxy在大多数基础场景中表现良好但它也存在一些明显的局限性
1、场景简单kube-proxy主要适用于简单的网络拓扑结构对于复杂的IaaSInfrastructure as a Service场景如需要支持VPCVirtual Private Cloud网络隔离、灵活的EIPElastic IP使用等高级网络功能时显得力不从心。
2、性能瓶颈由于kube-proxy的报文转发完全依赖于软件实现无论是iptables还是ipvs这意味着它无法利用现代硬件如DPU、SmartNIC进行网络加速在高负载跨节点转发的情况下这种软件实现的性能瓶颈尤为明显。
3、资源消耗基于软件实现的Kubernetes Service在高负载跨节点转发的情况下会导致CPU资源消耗过高从而影响整体系统的稳定性和性能。
与kube-proxy相似许多开源的容器网络接口CNI插件如使用Open vSwitchOVS的kube-ovn、Antrea等通常依赖于自己的数据面处理机制来转发Service网络流量在没有硬件加速的情况下也面临类似的性能瓶颈和资源消耗问题。 2. 方案介绍
2.1. 整体架构
本方案基于DPUSmartNIC实现了Kubernetes Service的解决方案简称“驭云Service”。
驭云Service在驭云SDN的架构中实现其中驭云SDN通过ovn/ovs机制将DPUSmartNIC加入到同一个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下的一组后端服务
在此场景下客户端通过云外访问集群内的服务。LoadBalancer类型Service会分配一个EIP此时外部流量通过EIP被路由到集群内部的Service。
场景④客户端在集群外部通过EIP访问多个VPC下的一组后端服务
当客户端需要访问跨多个VPC的服务时情况变得复杂。在这种情况下当外部流量通过EIP进入集群内Service时Servcie会同时充当网关将流量正确地路由到目标VPC。
本方案主要从控制面和数据面2各方面进行介绍。
2.2.1. 控制面
在控制层我们对原生Service进行了封装在Kubernetes基础上扩展了对Service的管理能力整体控制面结构如下图所示 Service和Endpoint是Kubernetes内置资源。资源Service定义了构造一个Service的基本信息。
由于内置资源无法满足我们需要功能包括网络访问场景和多种后端于是驭云Service增加了YusurService与NetworkProbe两种自定义资源定义CRDs
YusurService: 一种扩展的Service概念允许定义更广泛的后端资源包括Pod、VM、BM裸金属服务器、VNicIP虚拟网络接口IP。通过使用选择器selectors可以灵活地匹配不同类型的后端资源而不仅仅是Pod。支持定义多种网络场景灵活的指定eip和clusterIP等。
NetworkProbe: 用于健康检查的新CRD为每个后端资源生成相应的探针实时监控其健康状态。这可以确保负载均衡器只将请求转发给健康的实例。
用户只需要和YusurService进行交互yusurService-controller会根据YusurService的信息创建NetworkprobeEndpoint和Service这3种资源。
Service包含网络配置的大多基本信息Endpoint资源包含本次配置的所有后端Networkprobe返回后端健康检查结果yusurService-controller会根据Networkprobe的返回结果调整Endpoint所包含的健康后端。
yscloud-controller则会根据Endpoint和Service的信息通过ovn绘制出整个网络拓扑打通网络通路。
通过这样的架构系统不仅提供了高级别的抽象来简化Service管理和后端资源的健康监控还实现了跨VPC的负载均衡增强了Kubernetes集群的网络功能。
2.2.2. 数据面
Service的数据面依赖OVN和OpenVswitch根据不同的访问场景在不同的地方配置Load_BalancerLoad_Balancer是OVN的逻辑概念可以应用在OVN的逻辑交换机或者逻辑路由器上面它将在对应的地方上配置DNAT的规则将访问VIP的报文转到合适的后端上去。
下文分别针对控制面中所描述的4种Service使用场景进行说明。
2.2.2.1 同vpc下访问资源 当创建了Service之后LoadBalancer的网络策略会确保应用在vpc1内的所有Subnet上。当subnet3上的client访问10.0.0.100时其请求将首先被subnet3上的LoadBalancer接收。LoadBalancer会基于其算法例如轮询、最少连接数等选择一个后端Pod并将数据包的目标地址转换为所选Pod的实际IP地址。数据包随后会通过vpc1被转发到选定的Pod所在的Subnet例如subnet1最后转发至Pod1。
2.2.2.2. 从集群节点上访问vpc内资源 当集群节点上的client访问10.0.0.100时报文经过node-interface进入subnet0经过LoadBalancer将数据包的目标地址转换为所选Pod的实际IP地址后通过ovn-cluster到对应subnet完成一次转发。
2.2.2.3.从集群外部访问同一个vpc内资源 当创建了Service之后LoadBalancer的网络策略会应用在vpc1上当client访问200.0.0.100时其请求将首先被这个EIP子网所属的eipGateway接收。eipGateway会将报文路由到Servic所属的VPCvpc1内此时LoadBalancer规则会基于其算法例如轮询、最少连接数等选择一个后端Pod并将数据包的目标地址转换为所选Pod的实际IP地址。数据包随后会通过vpc1被转发到选定的Pod完成一次转发。
2.2.2.4.从集群外部访问多个vpc内资源 当创建了Service之后控制器会创建一个service-gateway的逻辑路由器LoadBalancer的网络策略会应用在该路由器上当client访问200.0.0.100时其请求将首先被这个eip子网所属的eipGateway接收。eipGateway会将报文路由到service-gateway上此时LoadBalancer规则会基于其算法例如轮询、最少连接数等选择一个后端Pod并将数据包的目标地址转换为所选Pod的实际IP地址源地址转换为所选service-gateway的系统IP地址。数据包随后会被转发到选定的Pod的vpc上然后vpc将数据包送到Pod完成一次转发。
3. 方案测试结果
3.1. 创建Service
创建一个带有特定选择器和端口映射的Service YAML文件ysvc1.yaml如下 apiVersion: iaas.yusur.io/v1 kind: YusurService metadata: name: ysvc1 spec: type: ClusterIP scope: vpc vpc: vpc1 ports: - port: 5001 name: iperf protocol: TCP targetPort: 5001 selector: svc: svc1-ep
使用kubectl apply -f ysvc1.yaml命令创建Service。
使用kubectl get ysvc ysvc1检查Service如下 访问Service clusterIP访问成功。 图中的netns为service后端同vpc下的一个pod10.233.46.185为service的clusterIP5001是service暴露的端口。
3.2. 性能对比
3.2.1 Pod的带宽
带宽单位Gbits/s。 测试用例 驭云卸载方案 未卸载方案 1 物理节点之间基准测试 163 166 2 物理节点访问后端在远端的Service 152 130 3 Pod访问后端在远端的Service 151 138
从上面测试数据得出以下结论
1. 卸载模式下驭云访问远端Service能够达到接近物理机的带宽。
2. 卸载模式比非卸载在带宽上性能提升了20%左右。
3.2.2 Pod的pps
pps单位为Mpps。 测试用例 驭云卸载方案 未卸载方案 1 物理节点之间基准测试 45 45 2 物理节点访问后端在远端的Service 25.5 12.1 3 Pod访问后端在远端的Service 24.5 12.2
从下面数据得出以下结论
1. 卸载模式下驭云访问远端Service能够达到接近物理机的60%pps。
2. 卸载模式比非卸载在pps上性能提升了2倍以上。
3.2.3 Pod的延时
延时单位为us。 测试用例 驭云卸载方案 未卸载方案 1 物理节点之间基准测试 32 32 2 物理节点访问后端在远端的Service 33 48 3 Pod访问后端在远端的Service 33 44
从上面测试数据得出以下结论
1. 卸载模式下驭云访问远端Service能够达到接近物理机的延迟。
2. 卸载模式比非卸载在延迟上降低了20%以上。
3.2.4 RPS
单位为Requests/s。 测试用例 驭云卸载方案 未卸载方案 1 物理节点之间基准测试 15999 2 Pod跨节点访问Service 15139 11040
从上面测试数据得出以下结论
1. 卸载模式下驭云访问远端Service能够达到接近物理机的rps。
2. 卸载模式比非卸载在rps上提升了40%左右。
3.2.5 每条request的CPU指令数以及CPI
每条request的CPU指令数单位为instructions/request。 测试用例 驭云卸载方案 未卸载方案 Pod跨节点访问Service 122,613 171,405
CPI单位为cycles/instruction。 测试用例 驭云卸载方案 未卸载方案 Pod跨节点访问Service 1.94 1.69
从上面测试数据得出以下结论
1. 一个请求消耗的CPU指令数量卸载模式比非卸载模式降低30%左右。
2. 在CPI方面卸载模式比非卸载模式增大了15%左右。
3. 综合消耗的CPU指令数量来看对CPU的消耗减少了25%左右。
4. 优势总结
基于DPU和SmartNIC的K8s Service解决方案展现出显著的优势具体总结如下
① 支持复杂网络拓扑与高级功能
在复杂的网络拓扑下实现K8s Service支持VPC网络隔离和EIP等高级网络功能大大增强了Kubernetes集群在IaaS环境中的网络灵活性和安全性满足复杂场景下的网络需求。
② 显著提升K8s Service性能
根据测试数据本方案在带宽上性能提升了20%左右pps上性能提升了2倍以上延迟降低了20%以上。DPU和SmartNIC内置了强大的网络处理引擎能够直接在硬件上完成报文的解析、转发和路由决策等任务这种硬件加速机制使得在高负载跨节点转发时仍能保持低延迟和高吞吐量显著提升了Kubernetes Service的性能。
③ 降低资源消耗与优化系统性能
根据测试数据本方案对CPU的消耗减少了25%左右。由于DPU和SmartNIC承担了大部分的网络处理工作CPU从繁重的网络转发任务中解放出来可以专注于执行其他更关键的计算任务这不仅降低了CPU的资源消耗还提升了整体系统的稳定性和性能。
综上所述基于DPU和SmartNIC的K8s Service解决方案在应对复杂网络拓扑、性能瓶颈和资源消耗等方面具有明显的优势能够显著提升Kubernetes集群在复杂IaaS环境中的网络性能和整体稳定性。
本方案来自于中科驭数软件研发团队团队核心由一群在云计算、数据中心架构、高性能计算领域深耕多年的业界资深架构师和技术专家组成不仅拥有丰富的实战经验还对行业趋势具备敏锐的洞察力该团队致力于探索、设计、开发、推广可落地的高性能云计算解决方案帮助最终客户加速数字化转型提升业务效能同时降低运营成本。
