性能与可扩展性

4 分钟阅读

Istio 使得轻松创建部署服务的网络，这些网络具有丰富的路由、负载均衡、服务间身份验证、监控等等，所有这一切都无需更改应用程序代码。Istio 努力以最少的资源开销提供这些优势，并旨在支持具有高请求率的超大型网格，同时增加的延迟最小。

Istio 数据平面组件（Envoy 代理）处理流经系统的数据。Istio 控制平面组件 Istiod 配置数据平面。数据平面和控制平面具有不同的性能问题。

Istio 1.24 的性能摘要

Istio 负载测试网格由 Istio 网格中的 1000 个服务和 2000 个 Pod 组成，每秒有 70,000 个网格范围内的请求。

控制平面性能

Istiod 根据用户编写的配置文件和系统的当前状态配置 Sidecar 代理。在 Kubernetes 环境中，自定义资源定义 (CRD) 和部署构成系统的配置和状态。Istio 配置对象（如网关和虚拟服务）提供用户编写的配置。为了生成代理的配置，Istiod 处理来自 Kubernetes 环境的组合配置和系统状态以及用户编写的配置。

控制平面支持数千个服务，这些服务分布在数千个 Pod 中，具有类似数量的用户编写的虚拟服务和其他配置对象。Istiod 的 CPU 和内存要求随着配置量和可能系统状态的增加而扩展。CPU 占用率随着以下因素的增加而增加

部署更改的速率。
配置更改的速率。
连接到 Istiod 的代理数量。

但是，这部分本质上是水平可扩展的。

您可以增加 Istiod 实例的数量，以减少配置到达所有代理所需的时间。

在大规模情况下，强烈建议使用配置范围。

数据平面性能

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

客户端连接数
目标请求速率
请求大小和响应大小
代理工作线程数
协议
CPU 内核
各种代理功能。特别是，遥测过滤器（日志记录、跟踪和指标）已知会对性能产生中等影响。

延迟、吞吐量以及代理的 CPU 和内存消耗都是作为上述因素的函数来衡量的。

Sidecar 和 ztunnel 资源使用情况

由于边车代理在数据路径上执行了额外的操作，因此它会消耗 CPU 和内存。在 Istio 1.24 中，每秒包含 1 KB 负载的 1000 个 http 请求

具有 2 个工作线程的单个边车代理大约消耗 0.20 个 vCPU 和 60 MB 内存。
具有 2 个工作线程的单个航点代理大约消耗 0.25 个 vCPU 和 60 MB 内存
具有 2 个工作线程的单个 ztunnel 代理大约消耗 0.06 个 vCPU 和 12 MB 内存。

代理的内存消耗取决于代理保存的总配置状态。大量的监听器、集群和路由会增加内存使用量。

延迟

由于 Istio 在数据路径上添加了一个边车代理或 ztunnel 代理，因此延迟是一个重要的考虑因素。Istio 添加的每个功能都会增加代理内部的路径长度，并可能影响延迟。

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

Istio 1.24 的延迟

在边车模式下，请求将在到达服务器之前通过客户端边车代理和服务器边车代理，反之亦然。在环境模式下，请求将在到达服务器之前通过客户端节点 ztunnel 和服务器节点 ztunnel。配置了航点后，请求将通过 ztunnel 之间的航点代理。以下图表显示了通过各种数据平面模式传播的 http/1.1 请求的 P90 和 P99 延迟。为了运行测试，我们使用了一个由 5 台 M3 Large 机器组成的裸机集群，并将 Flannel 作为主要 CNI。我们使用 Istio 基准测试获得了这些结果，用于 1 KB 负载下的 http/1.1 协议，每秒 500、750、1000、1250 和 1500 个请求，使用 4 个客户端连接、2 个代理工作线程并启用双向 TLS。

注意：此测试是在 CNCF 社区基础设施实验室上执行的。不同的硬件会产生不同的值。

P90 latency vs client connections

P99 latency vs client connections