性能比拼: Linkerd vs. Istio
本内容是对知名性能评测博主 Anton Putra Linkerd vs. Istio (Rust vs. C++) 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 使用率显著更高。