性能比拼: Linkerd vs. Istio

本内容是对知名性能评测博主 Anton Putra Linkerd vs. Istio (Rust vs. C++) performance benchmark performance benchmark") 内容的翻译与整理, 有适当删减, 相关指标和结论以原作为准

在本内容中，我们将对比 Kubernetes 服务网格中的 Istio 和 Linkerd。

相关代码详见 github

我们将运行几个测试，稍后我会解释测试内容。

首先，我们会从客户端角度测量每个请求的延迟。

然后，我们只会测量 sidecar 的 CPU 使用情况。

Istio 使用基于 C++ 的 Envoy 代理每个请求。而 Linkerd 最初也使用 Envoy，但后来放弃了它，转而采用了一个基于 Rust 编写的自研代理。

在这个视频中，我们将看看 Linkerd 的这个决策是否正确。

我们还会测量服务接收到的每秒请求数。

那么，服务网格是如何工作的呢？

假设你有一个客户端，也部署在 Kubernetes 中，它需要访问集群中的另一个应用程序。它不会直接发起调用。请求会被运行在相同 Pod 中的 sidecar 拦截，然后转发到另一个 sidecar，最后才到达目标服务。

由于请求是通过 sidecar 路由的，因此我们可以实现动态路由、熔断等功能。

此外，大多数服务网格（包括 Linkerd 和 Istio）都自动使用 mTLS 对流量进行加密。

Go 编写的客户端会暴露 Prometheus 指标来测量延迟，而我们使用 cadvisor 抓取 sidecar 的 CPU 使用情况。

我会在我的 homelab 上运行这些测试，该环境基于 AMD EPYC 处理器，使用 VMware hypervisor 搭建。

如你所见，我有一个 Kubernetes 控制平面节点和 5 个工作节点。

在测试过程中，我使用亲和性（affinity）和容忍度（tolerations）将所有应用分布到各自专属的节点上，以避免相互干扰。

现在开始第一个测试，我们将在大约 15 分钟时间内并行运行两个客户端和两个应用程序。

在第二个测试中，当客户端向 service-a 发送请求时，它会将请求转发至 service-b，然后 service-b 再将响应返回给 service-a，最后再返回给客户端。

在这种情况下，请求会被三个 sidecar 拦截，这将更明显地展示出 Envoy 和 Linkerd 的代理在 CPU 使用率和延迟（尤其重要）方面的差异。

因为如果你有上百个微服务，每个 sidecar 都会带来额外的延迟。

如果你想复现这个测试环境，我已经编写了 Terraform 脚本，使用 Helm Charts 安装了 Linkerd 和 Istio 两个服务网格。链接会放在视频描述中。

我还提供了一个使用 Go 编写的客户端，用于暴露 Prometheus 指标，并使用 Prometheus Operator 进行抓取。你也可以在代码中找到相关内容。

要注入 sidecar，你可以使用命名空间标签。不过我更倾向于使用注解将 sidecar 注入到单个 Pod，例如 Linkerd 的注解格式如下。

默认情况下，Linkerd 不会为 sidecar 设置资源限制，因此我们需要手动设置 requests 和 limits。

Istio 也是一样：可以使用标签注入 sidecar，并通过注解为其设置 requests 和 limits。

为了运行测试，我使用了 Kubernetes 的 Job，并在 command 部分指定了目标。

在测试中，我们会从 1 个并发请求开始，每秒递增，直到达到 1000。

现在开始第一个测试。

在空闲状态下，你可以看到 Istio 的 proxy（也就是 Envoy）在静止时的 CPU 使用量稍高于 Linkerd 的 proxy。

提醒一下，我们只测量 proxy 容器的 CPU 使用率，不包括应用容器本身。

当我开始测试时，客户端侧也会出现几个新的 sidecar，如图示所示。

在左上角，你可以看到每个服务（Istio 和 Linkerd）的每秒请求数。

右上角是延迟的百分位数图表，其中显示的是 p99，也就是 99% 的请求在此时间内完成。

通常我们会测量 p50、p90 和 p99。

在运行测试时你会注意到，Istio 的 sidecar 的 CPU 使用率明显高于 Linkerd。

在延迟图中也呈现出类似的趋势。

Istio 的服务网格延迟略高于 Linkerd。

另外请注意，由于 Istio 和 Linkerd 都使用 mTLS，sidecar 需要对每一个请求进行加密和解密。

让我们等待测试结束，我会展示最终结果。

好了，这是完整的延迟图。蓝色线代表 Istio，红色线代表 Linkerd。

随着负载增加，二者的差距也随之拉大。

我认为这在一定程度上是由于 Envoy 的较高 CPU 使用率造成的。

因此，如果你能保持 CPU 使用率较低，无论使用哪一个服务网格都可以。

现在来看 sidecar 的 CPU 使用率：图中前两条线是 Istio 的 sidecar，底部两条是 Linkerd 的客户端和应用。

好了，这是第一个测试的结果。

接下来我们进行第二个测试，向每个服务网格中增加一个微服务。

布局相同：展示每秒请求数、延迟和 CPU 使用率。

如图所示，现在我们有两个额外的 sidecar。

再等 10 秒钟。

随着更多 sidecar 的加入，延迟明显增加，几乎是原来的两倍。

因此，如果你有成百上千个微服务，并且希望尽可能降低延迟，你可能需要考虑使用 Linkerd。

我知道 Istio 拥有更大的社区和可能更多的功能，但你需要根据自己的使用场景进行选择。

同样地，CPU 使用情况也是如此。

Istio 的 proxy 的 CPU 使用率显著更高。