Istio真的性能低吗？

Posted 2021-04-13 架构头条

作者 | hzxuzhonghu

来源 | 容器魔方

长期以来听到种种质疑声：“Istio 性能很差”、“数据延迟很大”、“sidecar 内存、cpu 占用很高”......Istio 社区为了回应种种质疑，从 1.1 版本开始做了很多性能测试工作，希望用数据说话，改变广大用户、开发者的偏见。笔者希望通过本文 Istio1.3 的测试报告将事实告诉更多开发者，以改变固有偏见，因此翻译社区的性能测试结果。

通过丰富的路由，负载平衡，服务到服务身份验证，监控等，Istio 可以轻松创建已部署服务的网络， 所有这些都无需更改应用程序代码。Istio 致力于以最小的资源开销提供这些优势，旨在以最小的时延代价支持具有最大吞吐量的大规模网格。

Istio 数据平面组件，即 Envoy 代理，处理流经系统的数据。Istio 控制平面组件，Pilot，Galley 和 Citadel 配置数据平面。数据平面和控制平面具有明显的性能问题。

Istio 1.3 的性能总结  

Istio 性能测试网格（https://github.com/istio/tools/tree/master/perf/load）由 1000 个服务和 2000 个 sidecar 组成，并以 70000 qps 的速率在网格范围内发送请求。使用 Istio 1.3 运行测试后，我们得到以下结果：

• Envoy 代理每秒处理 1000 个请求时，使用 0.6 vCPU 和 50 MB 内存。

• istio-telemetry 服务每秒处理 1000 个网格范围的请求时，使用 0.6 个 vCPU。

• Pilot 使用 1 个 vCPU 和 1.5 GB 内存。

• Envoy 代理 p90 延迟增加了 8 毫秒。

控制平面性能  

Pilot 根据用户创建的配置文件和系统的当前状态配置 sidecar 代理。在 Kubernetes 环境中，自定义资源定义（CRD）和 deployments 构成了系统的配置和状态。像 gateways 和 virtual services 这样的 Istio 配置对象提供了用户编写的配置。为了生成代理的配置，Pilot 处理来自 Kubernetes 环境和用户编写的配置的组合配置和系统状态。

控制平面支持数千个服务，分布在数千个用户创作的具有相似数量的虚拟服务和其他配置对象的 pod 中。Pilot 的 CPU 和内存要求随配置量和可能的系统状态而变化。CPU 消耗与以下因素成比例：

• deployment/pod 变化频率；

• 配置规则变化频率；

• 连接到 Pilot 的代理数量。

但是 Pilot 部分本质上是水平可伸缩的。当命名空间隔离（Sidecar 对象）被启用，一个 Pilot 实例可以在支持 1000 个服务，2000 个 sidecar 的场景下仅占用 1 个 vCPU 和 1.5 GB 的内存。您可以增加 Pilot 实例的数量，以减少配置下发到所有代理所需的时间。

数据平面性能  

数据平面性能取决于许多因素，例如：

• 客户端连接数；

• 目标请求速率；

• 请求大小和响应大小；

• 代理工作线程数；

• 协议；

• CPU 核心；

• 代理过滤器的数量和类型，特别是 mixer 过滤器。

系统时延，吞吐量和代理的 CPU 和内存消耗由以上因素共同决定。

CPU 和内存  

由于 sidecar 代理在数据路径上执行额外的工作，因此它消耗 CPU 和内存。从 Istio 1.1 开始，代理每秒处理 1000 个请求消耗大约 0.6 个 vCPU。

代理的内存消耗取决于代理所拥有的总配置状态。大量的侦听器，集群和路由可以增加内存使用量。Istio 1.1 引入了名称空间隔离，以限制发送到代理的配置范围。在大型命名空间中，代理消耗大约 50 MB 的内存。

由于代理通常不缓冲通过的数据，因此请求率不会影响内存消耗。

   延迟     

由于 Istio 在数据路径上注入了 sidecar 代理，因此延迟是一个重要的考虑因素。Istio 为代理添加了身份验证和 mixer 过滤器。每个额外的过滤器都会增加代理内部的数据处理路径长度并影响延迟。

Envoy 代理在将响应发送到客户端后收集原始遥测数据。为请求收集原始遥测所花费的时间不会影响完成该请求所花费的总时间。但是，由于工作线程忙于处理请求，因此它不会立即开始处理下一个请求。此过程会增加下一个请求的队列等待时间，并影响平均延迟和尾部延迟。实际的尾部延迟取决于流量模式。

在网格内部，请求首先通过客户端代理，然后通过服务器端代理。数据路径上的这两个代理在每秒 1000 个请求的情况下增加了大约 7 毫秒的 P90 延迟。仅服务器端代理 P90 延迟就增加了 2 毫秒。

Istio1.3 的延迟  

Istio 1.3 的默认配置在数据面增加了 7 毫秒的 p90 延迟。我们获得这些结果使用的是 Istio 基准（https://github.com/istio/tools/tree/master/perf/benchmark） 测试 http/1.1，测试条件是：

• 16 条客户端连接；

• 每秒发送 1000 个负载为 1KB 的请求；

• 代理配置 2 工作线程；

• 开启 mTLS。

在即将到来的 Istio 版本中，我们将会把 istio-policy 和 istio-telemetry 功能集成到代理中，称为 MixerV2。这将减少流经系统的数据量，从而减少 CPU 使用和延迟。

P90 延迟与客户端连接

• baseline 客户端 pod 直接调用服务器 pod，不存在 sidecars。

• server-sidecar 仅存在服务器 sidecar。

• both-sidecars 存在客户端和服务器 sidecars。这是网格内部的默认情况。

• nomixer-both 与没有 mixer 的 both-sidecars 相同。MixerV2 延迟配置文件将类似。

• nomixer-server 与没有 Mixer 的 server-sidecar 相同。MixerV2 延迟配置文件将类似。

基准测试工具  

Istio 使用以下工具进行基准测试：

• fortio.org（https://fortio.org/）- 恒定吞吐量负载测试工具。

• blueperf（https://github.com/blueperf/）- 真实的云原生应用程序。

• isotope（https://github.com/istio/tools/tree/master/isotope）- 具有可配置拓扑的合成应用程序。

原文链接：

https://istio.io/docs/concepts/performance-and-scalability/