本文分享自华为云社区《流量治理架构对比:当Kmesh遇上Ambient Mesh》,作者:云容器大未来。

Kmesh是业内首个内核级流量治理引擎,Kmesh创新性地将服务治理卸载到内核eBPF和中心代理。Kmesh目前有两种工作模式:Kernel-Native 和 Dual-Engine模式。

Kernel-Native模式,Kmesh将流量治理完全下沉操作系统内核,通过eBPF和可编程内核模块对流量进行治理,在整个服务访问链路上不会增加任何多余的连接跳数,提供极致的性能体验。当然Kernel-Native模式对操作系统内核有一定的要求,比较适合对性能有极致要求的用户。 

流量治理架构对比:当Kmesh遇上Ambient Mesh_Sidecarless

今天重点谈的是Dual-Engine模式(本文后续均以Kmesh指代),这是一种分层的流量治理架构,它是通过eBPF程序拦截应用流量,并根据用户策略进行路由、负载均衡等四层的治理;七层治理则采用中心式代理,这样既可以保证七层治理需求的多样性和扩展性,又避免了Sidecar架构中,流量两次进出七层代理的复杂性。Kmesh Dual-Engine的架构如下图所示:

流量治理架构对比:当Kmesh遇上Ambient Mesh_Kmesh_02

Kmesh Dual-Engine架构

Ambient Mesh是Istio社区2022年推出的一种Sidecarless架构,其目的也是为用户提供资源开销更小的网络基础设施。Ambient也是采用分层的流量治理,其中节点上,用户态组件ztunnel负责拦截进出应用的流量,并进行四层转发;中心侧通过waypoint进行七层流量的治理,同样可以做到灵活、按需部署。

流量治理架构对比:当Kmesh遇上Ambient Mesh_云原生_03

Ambient Mesh架构

我们可以看到Kmesh和Ambient Mesh在架构上非常相似,两者均采用了四七层分离的流量治理架构。然而不同之处在于,Ambient Mesh流量的拦截和转发依靠节点级用户态ztunnel,而Kmesh则依靠eBPF。ztunnel工作在用户态,因此应用发送的流量首先经过iptables的拦截,进入本机协议栈处理一次,发送到ztunnel,而经过ztunnel处理后,再发起第二次连接。同理在服务端,流量也会先被拦截到ztunnel,再次发起连接,然后经由本机协议栈发送到应用进程。

但是Kmesh对应用流量的拦截和转发,则是通过eBPF程序在socket的不同钩子点完成,整个过程没有增加多余的连接,因此每次通信过程比Ambient Mesh少两条连接。说到这里就不得不提一下Kmesh的设计初衷了。

Kmesh设计之道 

当前用户在考虑服务网格落地时最担心的几个典型问题是:

  1. 网格基础设施不够可靠,运维复杂,因为过多的中间点出现在服务的访问链路中,服务访问被不同的连接管道串联, 故障定位变得复杂
  2. Sidecar带来的CPU、内存资源开销不可忽视
  3. 网格无法独立升级,它的生命周期与应用绑定,升级过程伴随着应用重启
  4. 基础设施代理额外的服务访问时延增加

Kmesh重点考虑了以上问题并结合用户对网格的基本诉求,定义了五大设计原则:

  1. 极简运维,打造足够可靠、轻量、解耦的网络基础设施,尽量的减少用户的维护成本。
  2. 高性能,微服务架构下,服务的调用拓扑一般都很长,有的请求甚至有10+次调用链,因此必须保证在绝大多数情况下,小于1ms的时延。
  3. 低开销,底层网络基础设施占用的CPU、Memory相对于业务容器应该足够小,并且不会随着业务容器的规模而大幅增加。
  4. 扩展性,为应对不同的协议治理,必须从架构层提供足够的扩展能力
  5. 高安全,构筑零信任安全的能力,为用户提供全链路可信保障

流量治理架构对比:当Kmesh遇上Ambient Mesh_Istio_04

Kmesh五大设计原则

Kmesh与Ambient Mesh性能对比  

几个月前,我们将Kmesh v0.5.0与Ambient Mesh v1.22.1在测试环境下(kind集群)进行过对比,只比对了两者在处理L7流量治理的场景下的时延,结果显示,Kmesh的端到端时延较Ambient Mesh提升25%左右

流量治理架构对比:当Kmesh遇上Ambient Mesh_Kmesh_05

Kmesh与Ambient v1.22对比

我们把这个结果汇报给了CNCF TAG-Network以及Istio社区,他们希望在真实的Kubernetes集群以及用最新的版本进行全面的测试。所以我们重新做了完整的测试。

测试环境

我们在华为云香港Region创建了一个Kubernetes 1.30标准版集群,并且纳管了三个Worker节点(Ubuntu 22.04, 规格为4U 16G)。

  • 集群中安装Istio 1.24.1 Ambient模式,以及Kmesh最新版本
  • 集群中部署了Fortio测试工具,无资源限制,其中Fortio-Client与Fortio-Server均为单副本,分别部署在不同的节点
  • 七层代理waypoint按需部署,在Kmesh和Ambient测试中,均与Fortio-Server部署在同一个节点,保证两者拓扑一致
  • waypoint 规格2核1G
  • Fortio测试采用连接复用,并发连接数(1,2,4,8,16,32,64,128)

最大吞吐量

流量治理架构对比:当Kmesh遇上Ambient Mesh_Kmesh_06

L4治理吞吐

四层服务治理,Kmesh的最大吞吐与基线(没有任何治理)基本一致,Kmesh的吞吐能力是Ambient Mesh的两倍左右。这里主要是因为,Kmesh的采用eBPF随流治理,不会增加访问路径的长度,而Ambient Mesh在客户端和服务端两个节点分别多了一个ztunnel用户态代理,导致流量路径多了两条连接。

流量治理架构对比:当Kmesh遇上Ambient Mesh_Kmesh_07

L7治理吞吐

流量治理架构对比:当Kmesh遇上Ambient Mesh_Istio_08

L7治理吞吐放大图

七层服务治理,Kmesh与Ambient吞吐量均比基线差,因为两者均多了一层七层Envoy代理。但是Kmesh的吞吐大概是Ambient Mesh的1.3倍,这里还是得益于Kmesh的治理路径上少了两次用户态代理,减少了数据的用户态和内核态拷贝次数以及协议栈处理的次数。

服务治理时延

我们选取了在固定QPS 1024下,分别测试Kmesh和Ambient Mesh的L4和L7治理的时延。

L4服务治理时延测试

流量治理架构对比:当Kmesh遇上Ambient Mesh_Sidecarless_09

流量治理架构对比:当Kmesh遇上Ambient Mesh_Istio_10

可以看到Kmesh的L4治理相比于基线,基本上没有增加额外的时延开销,而Ambient Mesh在并发连接数比较高的时候,增加了大概1.5ms的时延。可能是由于ztunnel在新版本引入了连接池导致。

L7服务治理时延测试

流量治理架构对比:当Kmesh遇上Ambient Mesh_Kmesh_11

流量治理架构对比:当Kmesh遇上Ambient Mesh_Sidecarless_12

我们可以看到在并发连接数低时,Kmesh与Ambient Mesh的七层治理时延增加非常少,在小于8并发的时候,Kmesh的时延小于1ms,Ambient Mesh的时延不可预测性更大,其P99时延甚至增加8ms。

随着并发连接数增加,Kmesh和Ambient Mesh的时延均增加。但是在小于32并发时,Kmesh的P99时延比Ambient Mesh好两倍多。在更高128并发时,Ambient Mesh的表现似乎更优一些,但是差距不大。

在笔者看来,造成以上结果的原因,主要有两点:

  1. Waypoint采用Envoy实现,当前测试中Envoy均启动两个worker线程并发处理。Envoy的线程间不共享任何状态和数据以避免锁冲突,但是同时带来了负载不均衡和延迟不稳定的问题。
  2. ztunnel的实现中增加了连接池的优化,虽然连接复用可以在高并发时节省一些连接资源,但是也可能带来额外的不稳定时延。

CPU和内存

Kmesh在节点流量治理采用了eBPF,没有用户态进程,所以引入的资源开销非常小,详细请参考:https://kmesh.net/en/docs/performance/resource_consumption/

而在最大吞吐量测试时,ztunnel的CPU占用率与Fortio应用基本一致,大概100%的CPU占用,而通过bpftop工具可以查看Kmesh的bpf程序CPU利用大概在10%左右,从CPU利用率上来说Kmesh优于Ambient 10 倍

数据面内存:在测试中,ztunnel占用的内存保持在10M+,相对比较稳定,Kmesh数据面的内存占用主要在BPF Map的内存分配,当前Kmesh使用的BPF Map已经采用按需分配,因此在测试过程占用的内存更少,小于5M。

测试感悟与总结  

本次测试,我们主要在时延和吞吐两个维度对Kmesh和Ambient进行了一定比较,总体来说Kmesh的性能略胜一筹。

  • 四层流量治理场景下,Kmesh的性能与基线基本保持一致,全面优于Ambient Mesh。
  • 七层治理的场景下,我们看到无论是Kmesh还是Ambient Mesh性能衰减还是比较大,而且也具有一些不稳定的延时。七层代理Waypoint是端到端访问的性能瓶颈,受限于其多线程无锁的设计,在高并发场景下,Envoy的资源分配以及参数调教对性能的影响很重要。

另外技术的对比不应该只局限在一些性能参数指标,还应该关注可靠性、运维的便捷性。服务访问链路就像是由多条管道连接起来的输水管,每一个接口连接就相当于一个用户态组件。输水管道中,接口连接处最容易漏水,而服务访问中同样如此,由于不同的代理组件接收、处理及发送数据的速度不一样,因此不同的代理设置不同的连接Buffer,不同的超时,不同的连接池等等参数。越多的连接级联,意味着越多的不可靠因素和风险存在。

Kmesh在设计之初就重点考虑了极简运维和高可靠性,Kmesh尽可能地将流量治理下沉,尽量减少连接的跳数,从下图可以看出,Kmesh在服务访问链路上连接跳数比Ambient Mesh少2条,这大大降低了用户在故障后问题定位的复杂度。将节点的流量治理下沉OS内核的另一个好处是,Kmesh在控制面升级时或者重启时,即使BPF程序更新,也不会导致业务的连接中断。而节点级用户态代理,天然不具备升级重启不影响业务通信的能力。

流量治理架构对比:当Kmesh遇上Ambient Mesh_云原生_13

如何使用Kmesh/加入社区贡献  

社区地址:https://github.com/kmesh-net/kmesh

安装试用:https://kmesh.net/en/docs/setup/quickstart/

参考链接

1. 实验步骤:https://github.com/hzxuzhonghu/playground/tree/main/performance_test

2. https://kmesh.net

3. https://istio.io/latest/blog/2022/introducing-ambient-mesh/

4. https://jimmysong.io/blog/introducing-kmesh-kernel-native-service-mesh/

点击关注,第一时间了解华为云新鲜技术~