服务网格性能评估:Istio、Linkerd、Kuma 和Consul比较

22-09-23 banq

现代应用程序通常由大量微服务组成,这些微服务在本地和云中分布的容器中运行。在这种情况下,服务网格是解决这些分布式微服务的安全性、连接性和可观察性挑战的基础设施层。但是,额外的组件层(来自 Mesh 基础设施)拦截所有流量对延迟的影响又如何呢?

在本文中,对不同的 Service Mesh 性能进行了测量和评估。下图说明了一个基本的 Service Mesh 基础设施,代理拦截流量并应用一组配置的功能,例如路由、访问控制、可观察性、负载平衡。控制平面为网格中所有正在运行的代理提供策略和配置,并维护服务视图。随着规则或环境的变化,它会动态更新代理。


典型的服务网格基础设施
已经比较了基本服务网格配置,同时确保配置等效以使措施有意义。还使用了没有 Service Mesh 的基线。然后,添加了额外的 Service Mesh 功能,并且还测量了这些功能对性能的影响。已经评估了不同的服务网格:


代码库:https ://github.com/ELCAIT/service_mesh_performance

出于评估目的,我们使用 Spring Boot 开发了一个简单的 Java REST API 微服务:counter-api。
counter-api 微服务是一个简单的计数器:第一个响应是 0,并且这个数字在每个新请求时递增。响应采用 JSON 格式。

服务网格比较
不同的 Service Mesh 之间存在一些差异,并且不同的 Service Mesh 默认配置没有可比性。为了公平地比较解决方案,必须使用“接近等效”的配置:

  • 重试和超时在 Service Mesh 中有不同的默认配置。为了公平对待没有 Service Mesh 的基线,这些功能已被禁用。
  • Sidecar 请求的 CPU 和 RAM在 Service Mesh 中是不同的。通常,Service Mesh sidecar 代理 CPU 请求在 50 到 150 毫 CPU 之间。但是,CPU 限制(如果设置)可以从 325 毫 CPU (Linkerd) 到 2000 毫 CPU (Istio) 或根本没有限制 (Consul)。为了公平起见,CPU 限制已设置为 200 毫 CPU(可在此处此处此处获取配置)。 在基准测试期间,尚未达到此限制。
  • 默认情况下,安全性和可观察性功能在服务网格之间配置为不同的级别和粒度。为了公平地比较地面差异, 禁用了 mTLS 和可观察性功能。


结论
当服务没有压力时(RPS < 500),Linkerd 通常被测量为最快的 Service Mesh。这可以在中位数延迟以及 99.9% 的百分位数中看到。这个结果是意料之中的,因为 Linkerd 在市场上已经被称为轻量级和快速的 Service Mesh。

关于以不轻量着称的 Istio,观察到非常好的延迟结果令人惊讶,尤其是在高 RPS 的情况下。Istio 的缺点是 CPU 消耗,它平均消耗的资源是其他资源的两到三倍。

关于 Consul,在RPS > 200 之前,结果与其他结果相似,因此延迟测量始终落后于其他结果。

总的来说,最有趣的结果是测试服务的低到中等负载 . 事实上,由于 Kubernetes 云集群提供了弹性和可扩展性,负载的增加不应该像基准测试那样使服务饱和。
据观察,Service Mesh 将中值延迟从 0.5[ms] 增加到 2[ms] 。但是,平均延迟影响不太显着;在RPS < 200的情况下,使用 Service Mesh 的平均延迟有时会更好。这个结果出乎意料,但可以通过 Service Mesh 的高效流量管理来解释——尤其是根据活动请求的最少数量选择服务实例的能力——这降低了当数量过多时不必要地使服务饱和的风险RPS 低。
激活不同的功能后,没有观察到延迟影响模式。
通过这一观察,Service Mesh 操作员可以自由地添加更多功能,而不会对延迟产生巨大影响。
只有启用了 Istio 的Open Policy Agent才会对延迟产生重大影响。由于 OPA策略决策点在 pod 的本地网络中添加了一个额外的跃点,因此该结果是意料之中的。

最后,Service Mesh 边车使用的资源是可以接受的。关于 Service Mesh 带来的特性,CPU/RAM 的消耗并不显着。

但是,如果 CPU 资源受到限制,人们可能不想选择 Istio。

测试细节点击标题

1