标签: Kubernetes

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下的一组后端服务： 在此场景下，客户端通过云外访问集群内的服务。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的信息创建Networkprobe，Endpoint和Service这3种资源。 Service包含网络配置的大多基本信息，Endpoint资源包含本次配置的所有后端；Networkprobe返回后端健康检查结果，yusurService-controller会根据Networkprobe的返回结果调整Endpoint所包含的健康后端。 yscloud-controller则会根据Endpoint和Service的信息通过ovn绘制出整个网络拓扑，打通网络通路。 通过这样的架构，系统不仅提供了高级别的抽象来简化Service管理和后端资源的健康监控，还实现了跨VPC的负载均衡，增强了Kubernetes集群的网络功能。 2.2.2. 数据面 Service的数据面依赖OVN和OpenVswitch，根据不同的访问场景，在不同的地方配置Load_Balancer，Load_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所属的VPC，vpc1内，此时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下的一个pod，10.233.46.185为service的clusterIP，5001是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环境中的网络性能和整体稳定性。 本方案来自于中科驭数软件研发团队，团队核心由一群在云计算、数据中心架构、高性能计算领域深耕多年的业界资深架构师和技术专家组成，不仅拥有丰富的实战经验，还对行业趋势具备敏锐的洞察力，该团队致力于探索、设计、开发、推广可落地的高性能云计算解决方案，帮助最终客户加速数字化转型，提升业务效能，同时降低运营成本。

一、什么是数据可观测性？ 数据可观测性是一种数据操作的方法和解决方案，可以实时监控、检测、预测、预防和解决基础架构、数据和应用程序层中的问题。 企业应用程序的可观察性越高，就越容易确定影响其问题的根本原因。随着问题的确定和修复，应用程序变得更加可靠和高效。 二、什么是APM？ APM就是应用性能监测，APM工具是一种万能的解决方案，用于监控企业基础架构中的应用层。APM通过输出日志和跟踪应用程序的运行状况，并向数据团队发出有关问题、瓶颈和停机问题的警报。 APM有两个显著特点 ： *APM工具首先采用了可观察性原则，使应用层的输出更加可观察。 *APM可以识别哪个 API 服务请求失败，并且可以突出显示计算资源被锁定的位置。 除了上述功能外， APM也有显著的缺点 ： *APM 仅限于应用层，APM 工具不具备监控数据和基础设施层所需的功能。 *APM 工具无法验证数据管道的质量。由于 APM 通常仅限于跟踪采样，因此它们无法分析完整的数据集，难以避免数据倾斜并分析原因，因此数据团队难以通过APM识别和修复数据的根本问题。 三、企业为什么需要数据可观测平台？ 对于企业而言，即便有APM 工具，也应该选择数据可观测平台。与仅监控应用层的 APM 工具不同，数据可观测平台将监控功能一直延伸到数据和基础设施层。数据可观测性改进了对数据管道的控制，创建了更好的SLA，并为数据团队提供了更好的业务决策洞察力。 数据可观测性解决方案在以下方面比 APM 工具更具优势 ： *提供更好的数据层可观察性，使DataOps团队可以更好地控制数据管道。 *提供改进的基础设施层可观察性，使ITOps团队可以更好地控制基础设施资源。 数据可观测平台对企业的作用 ： *ITOps团队可以在APM无法提供的粒度级别上监控关键基础设施层指标，例如内存可用性、CPU存储消耗和集群节点状态，数据可观测平台可以比其他解决方案更快地排除和解决数据拥塞和中断问题。 *DataOps团队可以通过自动检查功能来检查数据传输的准确性、完整性和一致性来确保高质量的数据标准，从而建立更健康的数据管道。 *数据工程师可以自动收集数千个管道事件，将它们关联起来以识别异常或峰值，并使用这些结果来预测、预防、排除故障和修复数据问题。 *业务领导者可以与BI分析师合作，创建准确的容量估计以及更明智的SLA，以满足业务目标的需求。 总体而言，数据可观测性有助于企业的数据团队在数据问题发生之前进行预防、识别和修复，这对于无法承受数据中断或停机时间的企业而言非常关键。 四、APM工具 VS数据可观测平台 DataOps团队应选择满足其业务范围、规模、预算、可用性、可靠性和自动化需求的解决方案。本文选择了六个参数来对比常见的APM工具和数据可观测性解决方案，为企业选择APM还是数据可观测方案提供参考： 从上述对比看，使用数据可观测平台具有如下优点 ： *监控范围更广 ：数据可观测平台使企业的基础架构层、数据层和应用程序层更易于观察。可以帮助企业优化资源、维护有效的数据管道并做出更好的数据驱动型业务决策。还可以帮助企业观察应用程序使用的所有服务、API和SDK。 *可扩展性高 ：通过数据可观测平台可以使用微服务为分布式企业应用程序提供服务，即便每天具有2000亿次展示的规模也可以做到。 *高复杂性 ：数据可观测平台可以为在云原生和混合基础架构上运行的企业应用程序提供服务，帮助企业深入了解其基础架构、数据层和应用程序层。 *可靠性高 ：数据可观测平台可以提高数据管道的质量和可靠性，允许分析完整的数据集，而不会出现任何数据偏差，从而识别和修复根本原因问题。 *可用性高 ：与企业APM类似，像HK-Acceldata等高端数据可观测平台还可以为企业提供一流的客户支持服务，帮助企业的数据团队充分利用数据管道。 *提供AI自动化 ：数据可观测平台支持AI自动化，可以过滤掉数TB的噪音，还可以在问题发生之前就预防问题，而不是在问题出现时才想如何解决问题。这样企业的团队就可以将更多的时间花在优化和扩展应用程序上。 五、选择数据可观测性平台比APM工具更好 如果企业运行使用了Spark、Kafka或Kubernetes的关键任务云原生或混合企业应用程序，则企业将无法承受任何数据中断或停机时间。此外，数据分析需要更健康的数据管道，如果让垃圾数据进入，企业只会得到垃圾分析。为了解决这两个问题，企业需要一个完整的数据可观测平台（例如HK-Acceldata）来分析完整的数据集、避免数据倾斜、深入挖掘必要的信息以识别根本原因问题并改善数据管道的健康状况。 使用像HK-Acceldata这样的数据可观测平台，企业可以扩展数据功能 ： *更好地控制数据管道。 *提高数据集的质量和健康度。 *分析完整的数据，避免偏差。 同时，还将扩展企业的业务能力： *利用AI自动化构建模型，帮助消除噪音。 *识别根本原因问题，获得实时洞察，并做出数据驱动的决策。 *通过优化资源使用和避免手动编码/配置更改来降低成本。