流量治理架构对比：当Kmesh遇上Ambient Mesh

关注

原创 2024-12-20 10:23:24 1.4k 阅读 AI 写同款· GEO 优化 ›

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

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

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

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

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

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

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

Kmesh设计之道

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

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

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

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

Kmesh与Ambient Mesh性能对比

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

我们把这个结果汇报给了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的最大吞吐与基线（没有任何治理）基本一致，Kmesh的吞吐能力是Ambient Mesh的两倍左右。这里主要是因为，Kmesh的采用eBPF随流治理，不会增加访问路径的长度，而Ambient Mesh在客户端和服务端两个节点分别多了一个ztunnel用户态代理，导致流量路径多了两条连接。

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

服务治理时延

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

L4服务治理时延测试

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

L7服务治理时延测试

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

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

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

Waypoint采用Envoy实现，当前测试中Envoy均启动两个worker线程并发处理。Envoy的线程间不共享任何状态和数据以避免锁冲突，但是同时带来了负载不均衡和延迟不稳定的问题。
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程序更新，也不会导致业务的连接中断。而节点级用户态代理，天然不具备升级重启不影响业务通信的能力。