最佳实践：Service Mesh 基准性能测试

服务网格为应用部署增加了很多功能，包括流量策略、可观测性和安全通信。但是，无论是时间（增加的延迟）还是资源（CPU 周期），向环境中添加服务网格都是有代价的。要就服务网格是否适合您的情况做出明智的决定，评估应用与服务网格一起部署时的性能非常重要。

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

总体而言，我们发现 Istio sidecar 代理的延迟取决于并发连接数。以每秒 1000 个请求（RPS）的速度，通过 16 个连接，Istio 延迟在 50% 时增加 3 毫秒，在 99% 时增加 10 毫秒。

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

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

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

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

Istio 的 demo 安装不适合进行性能测试，因为它被设计为部署在小型试用群集中，并且具有完整的跟踪和访问日志，可显示 Istio 的功能。

2. 专注于数据平面

我们的基准测试脚本专注于评估 Istio 数据平面：Envoy 代理，可在应用容器之间进行流量调度。为什么要关注数据平面？因为在大规模使用大量应用容器时，数据平面的 内存 和 CPU 使用率很快就会超过 Istio 控制平面。让我们看一个具体的例子：

假设您运行了 2,000 个注入 Envoy 的 pod，每个 pod 每秒处理 1,000 个请求。每个代理使用 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 策略适配器时，策略检查位于请求路径上。这意味着数据路径上的请求 header 和 metadata 将被发送到控制平面（Mixer），从而导致更高的请求延迟。注意： 这些策略检查默认情况下处于禁用状态，因为最常见的策略用例（RBAC）完全由 Envoy 代理执行。

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

接下来，在大规模测试 Istio 的数据平面性能时，不仅要以每秒递增的请求进行测试，而且还要以越来越多的 并发 连接进行测试，这一点很重要。这是因为现实世界中的高吞吐量流量来自多个客户端。我们提供了脚本允许您以递增的 RPS 对任意数量的并发连接执行相同的负载测试。

最后，我们的测试环境可以测量两个 pod 之间少量的请求。客户端 pod 是 Fortio，它将流量发送到服务端 pod。

为什么只用两个 pod 测试？因为增加吞吐量（RPS）和连接（线程）对 Envoy 的性能的影响比增加服务注册表的总大小（或 Kubernetes 集群中 Pod 和服务的总数）更大。当服务注册表的大小增加时，Envoy 必须跟踪更多的端点，并且每个请求的查找时间确实增加了，但是增加了一个很小的常数。如果您有许多服务，并且此常数成为延迟问题，则 Istio 提供 Sidecar 资源，它使您可以限制每个 Envoy 知道的服务。

3. 有/无 度量的代理

尽管 Istio 的许多特性，例如双向 TLS 身份验证，都依赖于应用 pod 的 Envoy 代理，但是您可以选择性地禁用一些网格服务的 sidecar 代理注入。在扩展 Istio 以进行生产时，您可能需要将 sidecar 代理增量添加到工作负载中。

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

您还可以在性能测试期间禁用 Mixer 以停止 Istio 的遥测，这将得到与 Mixer V2 工作完成时我们期望的性能相符的结果。Istio 还支持 Envoy 本地遥测，其功能类似于禁用 Istio 的遥测。

Istio 1.2 性能

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

为了衡量 Istio sidecar 的代理延迟，我们考虑在 50%、90% 和 99% 时不断增加并发连接数量，从而保持了请求吞吐量（RPS）不变。

我们发现，通过 16 个并发连接和 1000 RPS，当请求同时通过客户端和服务器代理传输时，Istio 会在基线（P50）上增加 3ms。（从绿色线 both 中减去粉红色线 base）在 64 个并发连接上，Istio 在基线上增加了 12ms，但是禁用 Mixer（nomixer_both）后，Istio 仅增加了 7ms。

在 90% 时，有 16 个并发连接，Istio 增加 6ms；在 64 个连接的情况下，Istio 增加了 20ms。

最后，在具有 16 个连接的 99% 时，Istio 在基线之上增加了 10ms。在 64 个连接处，Istio 使用 Mixer 增加 25ms，不使用 Mixer 则增加 10ms。

对于 CPU 使用率，我们以不断增加的请求吞吐量（RPS）和恒定数量的并发连接进行了测量。我们发现启用了 Mixer 的 Envoy 在 3000 RPS 时的最大 CPU 使用率是 1.2 vCPU。在 1000 RPS 时，一个 Envoy 大约使用了 50% 的 CPU。

总结

在对 Istio 的性能进行基准测试的过程中，我们吸取了一些重要的经验教训：

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

对于在 16 个连接上具有 1000 RPS 的网格，Istio 1.2 仅在 50% 的基础上增加了 3 毫秒 的基准延迟。

另外，请查阅 Istio 性能和可伸缩性指南获取最新的性能数据。感谢您的阅读，祝您基准测试愉快！