最佳实践：服务网格性能基准测试

服务网格为应用程序部署添加了许多功能，包括流量策略、可观测性和安全通信。但是，将服务网格添加到您的环境会产生成本，无论是时间（增加延迟）还是资源（CPU 周期）。为了对是否将服务网格用于您的用例做出明智的决定，评估应用程序在与服务网格一起部署时的性能非常重要。

今年早些时候，我们发布了一篇关于 Istio 在 1.1 版中性能改进的博文。在发布Istio 1.2之后，我们希望提供指导和工具来帮助您在生产就绪的 Kubernetes 环境中对 Istio 的数据平面性能进行基准测试。

总的来说，我们发现 Istio 的边车代理延迟会随着并发连接数的增加而增加。在每秒 1000 个请求 (RPS) 下，跨 16 个连接，Istio 在第 50 个百分位数处每个请求增加3 毫秒，在第 99 个百分位数处增加10 毫秒。

在Istio 工具存储库中，您将找到用于测量 Istio 数据平面性能的脚本和说明，以及有关如何使用另一个服务网格实现Linkerd运行这些脚本的其他说明。请继续阅读，我们将详细介绍性能测试框架每个步骤的一些最佳实践。

1. 使用生产就绪的 Istio 安装

为了准确地衡量服务网格在规模上的性能，使用适当大小的 Kubernetes 集群非常重要。我们在三个工作节点上进行测试，每个节点至少具有 4 个 vCPU 和 15 GB 内存。

然后，重要的是在该集群上使用生产就绪的 Istio 安装配置文件。这使我们能够实现面向性能的设置，例如控制平面 Pod 自动扩展，并确保资源限制适合繁重的流量负载。默认的 Istio 安装适用于大多数基准测试用例。对于使用数千个代理注入服务的广泛性能基准测试，我们还提供调整后的 Istio 安装，该安装为 Istio 控制平面分配额外的内存和 CPU。

Istio 的演示安装不适合性能测试，因为它旨在部署在小型试验集群上，并且启用了完整的跟踪和访问日志以展示 Istio 的功能。

2. 集中于数据平面

我们的基准测试脚本侧重于评估 Istio 数据平面：在应用程序容器之间中介流量的Envoy 代理。为什么专注于数据平面？因为在规模上，随着大量应用程序容器的出现，数据平面的内存和CPU使用量很快就会超过 Istio 控制平面。让我们来看一个这种情况如何发生的例子

假设您运行 2000 个 Envoy 注入的 Pod，每个 Pod 每秒处理 1000 个请求。每个代理使用 50 MB 内存，并且为了配置所有这些代理，Pilot 使用 1 个 vCPU 和 1.5 GB 内存。总而言之，Istio 数据平面（所有 Envoy 代理的总和）使用 100 GB 内存，而 Pilot 使用 1.5 GB。

出于延迟原因，专注于数据平面性能也很重要。这是因为大多数应用程序请求都通过 Istio 数据平面而不是控制平面移动。有两个例外

1. 遥测报告：每个代理都会将原始遥测数据发送到 Mixer，Mixer 会将这些数据处理成指标、跟踪和其他遥测数据。原始遥测数据类似于访问日志，因此会产生成本。访问日志处理会消耗 CPU 并阻止工作线程获取下一个工作单元。在更高的吞吐量下，下一个工作单元更有可能在队列中等待工作线程获取。这可能导致 Envoy 的长尾（第 99 个百分位数）延迟。
2. 自定义策略检查：当使用自定义 Istio 策略适配器时，策略检查位于请求路径上。这意味着数据路径上的请求标头和元数据将发送到控制平面 (Mixer)，从而导致更高的请求延迟。注意：这些策略检查默认情况下处于禁用状态，因为最常见的策略用例（RBAC）完全由 Envoy 代理执行。

这两个例外都将在未来的 Istio 版本中消失，届时Mixer V2 将所有策略和遥测功能直接移动到代理中。

接下来，在规模上测试 Istio 数据平面性能时，不仅要测试每秒请求数的增加，还要针对并发连接数的增加进行测试。这是因为现实世界中的高吞吐量流量来自多个客户端。提供的脚本允许您使用任意数量的并发连接执行相同的负载测试，并在增加 RPS 的同时执行。

最后，我们的测试环境测量两个 Pod 之间的请求，而不是多个 Pod 之间的请求。客户端 Pod 是Fortio，它向服务器 Pod 发送流量。

为什么只用两个 Pod 进行测试？因为扩展吞吐量 (RPS) 和连接 (线程) 对 Envoy 的性能的影响大于增加服务注册表的大小——或者说，Kubernetes 集群中 Pod 和服务的总数。当服务注册表的大小增长时，Envoy 确实需要跟踪更多的端点，并且每个请求的查找时间确实会增加，但增加的幅度很小。如果您有很多服务，并且这个常数成为延迟问题，Istio 提供了一个Sidecar 资源，它允许您限制每个 Envoy 知道的服务。

3. 使用和不使用代理进行测量

虽然许多 Istio 功能（例如双向 TLS 身份验证）依赖于应用程序 Pod 旁边的 Envoy 代理，但您可以有选择地禁用某些网格服务的边车代理注入。当您为生产环境扩展 Istio 时，您可能希望将边车代理增量添加到您的工作负载中。

为此，测试脚本提供了三种不同的模式。这些模式分析请求通过客户端和服务器代理 (both)、仅服务器代理 (serveronly) 和两个代理都不通过 (baseline) 时 Istio 的性能。

您还可以禁用Mixer以在性能测试期间停止 Istio 的遥测，这提供了与 Mixer V2 工作完成后我们预期的性能一致的结果。Istio 还支持Envoy 原生遥测，其性能类似于禁用 Istio 的遥测。

Istio 1.2 性能

让我们看看如何使用此测试环境来分析 Istio 1.2 的数据平面性能。我们还提供了运行Linkerd 数据平面的相同性能测试的说明。目前，Linkerd 仅支持延迟基准测试。

为了测量 Istio 的边车代理延迟，我们查看了在并发连接数增加的情况下第 50、90 和 99 个百分位数，同时保持请求吞吐量 (RPS) 不变。

我们发现，在 16 个并发连接和 1000 RPS 下，当请求通过客户端和服务器代理时，Istio 比基线 (P50) 多增加了3 毫秒。（从绿色线 both 中减去粉红色线 base。）在 64 个并发连接下，Istio 比基线多增加了12 毫秒，但在禁用 Mixer (nomixer_both) 的情况下，Istio 仅增加了7 毫秒。

在第 90 个百分位数处，在 16 个并发连接下，Istio 多增加了6 毫秒；在 64 个连接下，Istio 多增加了20 毫秒。

最后，在第 99 个百分位数处，在 16 个连接下，Istio 比基线多增加了10 毫秒。在 64 个连接下，Istio 在启用 Mixer 的情况下多增加了25 毫秒，或在禁用 Mixer 的情况下多增加了10 毫秒。

对于 CPU 使用率，我们通过增加请求吞吐量 (RPS) 并保持并发连接数恒定来进行测量。我们发现 Envoy 在 3000 RPS 下启用 Mixer 时的最大 CPU 使用率为1.2 个 vCPU。在 1000 RPS 下，一个 Envoy 使用大约半个 CPU。

总结

在对 Istio 的性能进行基准测试的过程中，我们学习了一些关键经验教训

• 使用模拟生产的环境。
• 专注于数据平面流量。
• 针对基线进行测量。
• 增加并发连接数以及总吞吐量。

对于在 16 个连接上具有 1000 RPS 的网格，Istio 1.2 在第 50 个百分位数处仅比基线多增加了3 毫秒的延迟。

还可以查看Istio 性能和可扩展性指南，以获取最新的性能数据。

感谢您的阅读，并祝您基准测试愉快！