Istio、Linkerd和Cilium的性能比较

云云众生s

发布于 2024-05-23 14:17:36

1280

发布于 2024-05-23 14:17:36

文章被收录于专栏：云云众生s

三个著名的开源服务网格 Istio、Linkerd 和 Cilium 的性能比较。

译自 Service Meshes Decoded: a performance comparison of Istio vs Linkerd vs Cilium，作者 Oleksandr。

服务网格是一个专门的基础设施层，它使用代理来促进服务或微服务之间的服务到服务通信。或者，引用 Kelsey Hightower 的话，我们可以说：

使用动态生成并分发 Envoy 代理配置和 TLS 证书，花销比在您的实际业务逻辑上开销更多计算资源。

如果您正在阅读这篇博文，我假设您已经熟悉服务网格，并且正在寻找对可用选项进行可靠比较以确定最佳选项。在这篇文章中，我们将比较三个流行的开源服务网格——

——并分享我们对其比较的经验。

为了提供一些背景信息，我的任务是比较这三个网格并准备文档，以帮助 LiveWyer 更详细地了解每个产品，比较所测试网格的优缺点。

此比较涵盖以下领域：

部署
配置
维护
性能和连接性
运营影响
合规性和标准

虽然这篇博文只比较了三个服务网格的性能，但详细的测试报告和代码库可在我们的公共 GitHub 存储库中获得。

此练习将使用我们的内部开发平台 LWDE（Livewyer 开发环境）来加快和简化环境设置过程。

环境设置

一个稳定且一致的环境对于确保所有比较测试准确且公平至关重要。我采用了以下关键原则来实现此目的：

所有产品的统一环境
一致的测试工具
相同的测试参数和负载
所有产品的类似配置和相同标准
在比较测试练习期间，版本和配置保持不变

所有测试都在单独的隔离环境中执行。这些环境包括一个已安装了测试产品的 AWS EKS 集群，以及一个单独的 VM，用于对我们的测试应用程序进行负载生成。配置了四个环境——一个用于基线，一个用于每个服务网格。这些环境完全相同，部署在同一区域和可用性区域。所有环境中的所有版本和配置都是相同的，并且在整个测试过程中保持不变。所有集群都有四种类型的 c5.large 节点，分别打上污点，以确保在所有环境中调度不可变。

在下面，您可以看到显示基础设施级别环境设置的图表：

我使用我们的 LWDE 创建了所有集群。LWDE 使得管理不同云上的集群变得容易，从而加快了多次创建和删除四个集群的速度。

在从产品设置方面使测试公平方面，我执行了以下操作：

所有产品都使用最新的稳定版本安装，并且在测试期间不可变
所有产品都使用 helm 安装，并使用文档中推荐的默认参数或参数
没有对任何产品进行优化
启用并测试了相同的功能：
- 强制 mTLS
- 使用文档推荐的方法向互联网公开服务

作为此任务的一部分，我们还创建了运营手册更新文档。此文档解释了每个产品的组成部分，包括安装说明。产品安装使用运营手册更新文档中的命令执行，这些命令被编写到 bash 脚本中以简化流程。

测试应用

要测试服务网格，需要一个具有多个微服务的应用程序。出于此原因，我们决定使用 Istio Bookinfo 应用程序。原始模板被包装到一个 helm 图表中，并使用在 LWDE 中运行的 Flux 安装到我们所有的环境中。

测试方法

本节解释了我们的测试方法。在最初运行测试时，我们面临了许多挑战，在运行最终比较测试和获取结果之前解决了这些挑战。因此，这种迭代方法提高了所捕获数据的可靠性和准确性。我在迭代和改进小节中包含了这些挑战的详细信息以及解决这些挑战的步骤。

我们的测试方法类似于互联网上可用的其他测试。我们在不同环境的测试应用程序中生成了负载，比较了延迟、QPS、时间等。我们使用的 oha 是一款负载测试工具，用于向测试应用程序生成负载。有两种类型的流量：内部和外部，或者简单地说，针对服务 IP 和 Ingress IP 运行 oha。

请参阅以下图表，了解内部和外部测试之间的区别：

内部负载测试：

外部负载测试：

注意：此处使用带有 sidecar 的服务网格作为示例

下面您可以看到用于向测试应用程序生成负载的 oha 命令：

oha $URL -c $CONCURRENT_CONNECTIONS -n $REQUESTS --disable-keepalive --disable-compression --insecure --ipv4 --no-tui

其中：

$URL 是服务的 DNS 名称
$CONCURRENT_CONNECTIONS 是并发连接数
$REQUESTS 是要发送的请求数

使用 32、64 和 128 个并发连接执行了测试，这使我们能够在保持较低迭代次数的情况下了解结果之间的差异。

我们设置发送 300,000 个请求，这使我们能够运行超过 30 分钟的测试，并查看更多统计上正确的信息（有关我们为何这样做，请参阅改进 I002 了解更多详情）

此外，为了了解全貌，我们捕获了参与测试的组件的资源使用情况，它们包含在我们的详细测试报告中。

迭代与改进

在本节中，我们将讨论我们如何迭代和改进我们的测试作为此过程的一部分。由于我们预计需要运行多次迭代测试，因此我们采用了迭代方法，分析结果并进行改进，以确保可靠的实际结果。您可以在下面找到我们改进和失败的详细信息：

改进 - I001：测试持续时间

详细信息：第一轮测试包括以有限的 QPS 运行 oha 命令 3 分钟。我们意识到 3 分钟不够，因为我们必须包括云故障，这可以在小时间范围内注意到，但在较长时间范围内得到恢复，因此测试持续时间增加到 30 分钟。

结果：测试输出考虑了瞬态网络问题。

改进 - I002：用请求数替换 QPS

详细信息：我们从 oha 命令中删除了 QPS 限制。尽管限制 QPS 是一个可靠的选择，但它需要更多轮测试，并且提供更多实验室结果，而不是实际结果。因此，我们决定使用无限数量的 QPS 来测试每个产品的最大性能，而不会使其过热。我们将 oha 命令中的 -q 参数更改为 -n，它设置应传递的请求数。

结果：新方法正确加载我们的环境，而不会猛烈冲击产品或使其过热。

改进 - I003：预热

详细信息：在第一轮测试中，我们注意到第一个测试比所有后续测试完成得更慢。事实证明，在每次测试应用程序重新启动后，我们需要对其进行一些小的预热。因此，我们添加了更多一些测试，其结果未包含在报告中。

结果：结果更一致。

改进 - I004：测试应用程序

详细信息：我们简化了测试应用程序设置。我们删除了 podinfo 测试应用程序，因为它没有显示服务网格用例，因为只有一个微服务。我们还删除了 bookinfo 测试应用程序的 HA 模式，因为它需要更多轮测试，并且不会显示结果中的显着差异。

结果：测试运行耗时更少。

改进 - I005：可用性区域

详细信息：在第一轮测试中，我们注意到即使禁用服务网格，不同环境中的结果也不同，因此我们决定最小化环境之间的差异，并将所有节点部署在同一可用性区域中。

结果：结果略有改善，但差异仍然很大。

改进 - I006：区域

详细信息：在第二轮测试之后，即使禁用服务网格，不同环境中的结果也不同，我们决定从 eu-west-2 迁移到 us-east-1，因为它是最大且最古老的 AWS 区域。