本文翻译自 Mathew Duggan^[1] 的文章 K8s Service Meshes: The Bill Comes Due^[2]。本文既包含作者的个人观点，也涵盖了客观事实的描述。大家保持批判性思维，审慎阅读。

文章讨论了 Kubernetes（K8s）服务网格技术的最新发展，重点分析了四种主要的服务网格解决方案：Linkerd、Cilium、Istio 和 Consul Connect，以及云提供商服务网格的概况。每种技术都有其独特之处，包括架构设计、易用性、功能以及与 Kubernetes 的集成方式。

此外，文章还探讨了这些技术的定价模型，指出免费服务网格时代的结束，以及企业在选择服务网格解决方案时需要考虑的成本因素。随着服务网格技术的发展，企业需要仔细评估各种选项，以找到最适合其特定需求和预算的解决方案。

以下是原文的翻译。

当你开始使用 Kubernetes 时，你将获得的第一个建议之一是安装服务网格。当然，这是在你需要安装的其他 900 项事务之上。对于那些不知情的人来说，当你开始使用时，k8s 中的一切默认对外开放，并且服务之间的流量不进行加密。由于服务间流量加密和控制哪些服务可以与哪些服务通信需要类似 JWT 和客户端证书的东西，即使这越来越成为任何技术栈的要求，团队通常也不热衷于承担这项工作。

基础设施团队通常可以比公司中的每个应用团队更快地实现功能，因此这种问题往往由他们解决。服务网格因为它们是实现强制加密和精细的服务对服务访问控制的简便方式而爆炸性地增长了人气。你还可以获得更好的监控和一些酷炫的功能，如断路器和请求重试，这些都是“免费”的。随着 k8s 部署的规模扩大，并开始跨越多个云提供商或云提供商和数据中心，这从“有则更好”变成了运营要求。

什么是服务网格？

服务网格让你轻松做到几件事情：

•因为它有一个代理了解成功/失败/往返时间/请求数量，所以可以轻松获取所有服务到服务请求的指标•知道所有请求都通过自动旋转进行加密•选项以确保仅接受加密请求，因此你可以在与其他事物相同的 VPC 中拥有 k8s 而无需进行防火墙规则设置•在路由/服务/命名空间级别轻松设置网络隔离（适用于 k8s 托管平台或客户隔离）•自动重试、全局超时限制、断路器以及设计更加健壮的应用程序的所有功能，而无需工作•降低变更失败率。有了坐在那里持有和重试请求的代理，小的波动不再对客户端注册。现在如果你正确设置了 k8s，它们本来就不应该注册，但这是另一层冗余。

这为采用它们的地方提供了很大的价值，因为它们是注入现有应用的边车，所需的工作量最小。大部分时间它们“只是工作”，并且不需要很多知识就能继续工作。

然而，现在是 2024 年，以前免费的东西不再免费了。来自风险投资者的免费资金列车已经结束，账单已经到期。越来越多地，部署生产应用程序到 k8s 的要求将会带来一笔你在为 k8s 迁移预算时需要考虑的税费，并决定它是否值得。自 2023 年 12 月以来，服务网格领域发生了重大变化，现在是对正在发生的事情进行快速概览的好时机。

注意： 在人们跳过来批评我之前，我不是说这些团队不应该得到报酬。如果你的工具为企业提供了真正的好处，要求它们对此做出实质性贡献并不不合理。我只是希望人们能对服务网格行业的现状保持更新，并能相应地进行规划。

Linkerd

我个人最喜欢的服务网格之一，Linkerd 是设计中最易于理解和使用的。它由控制平面和数据平面组成，并包括了监控选项。其架构如下所示：

近期，Linkerd 宣布了对其发布流程的改变，我认为这是解决“为你的工作获得报酬”问题的一种新颖方法。对于那些不知道的人来说，Linkerd 一直维护着一个“稳定版”和一个“边缘版”软件，以及一个企业产品。从 Linkerd 2.15.0 版本开始，他们将不再发布稳定版本。相反，稳定版的概念将被整合到他们的 Buoyant Enterprise for Linkerd 选项中。你可以在这里阅读博客文章。^[3]

重要的是，与某些产品不同，Linkerd 并不仅仅是将特定的边缘版发布作为企业版。有些功能可能会出现在边缘版中，但永远不会进入企业版，稳定版也不是一个静态的目标（稳定分支也有补丁发布），因此这实际上是三个不同的产品。因此，你不能通过将你的组织锁定在与稳定版/企业版匹配的特定边缘版发布中来进行变通。

定价

Buoyant 定下了每个集群每月 2000 美元的价格，这对我来说出乎意料之高。这令人惊讶的原因是，k8s 的模型越来越倾向于更多的集群但集群内较少内容，而不是老式的单一大集群，其中整个公司都在一个集群中。这种定价与该目标背道而驰，削弱了服务网格概念的一些价值。

如果 Linkerd 团队的想法是组织将坚持使用较少、较大的集群，那么对我来说使用 Linkerd 就没那么有意义了。拥有大量集群时，我不想考虑 IP 地址范围或任何东西到西部的网络设计，但如果我只有像 2-3 个完全独立的集群，那么我可以通过相对基础的防火墙规则、k8s 网络策略和对应用程序进行一些小改动来加密连接，获得与 Linkerd 类似的体验。Linkerd 仍然有其价值，但当我之前显然可以自己托管整个系统时，每个集群的定价就显得奇怪了。

每个站点每月 2000 美元的费用对我来说是有意义的，以获得企业版的访问权。但当 Buoyant 没有在他们这边提供仪表板或指标时，每个集群每月 2000 美元的费用似乎是他们凭空挑选的一个数字。每增加一个集群，他们没有任何额外成本，这纯粹是利润。这感觉既奇怪又不好。如果我托管和部署一切，而你提供给我的唯一支持是让我发帖到论坛，你是如何计算出无论大小我都应该每个集群支付你的？

现在你可以继续使用 Linkerd，但你需要切换到边缘版。根据我的测试经验，边缘版是 _ 可以接受的 _。它大多数时候都是生产就绪的，但有时候你会开始使用某些功能，然后它们会消失。我不认为这对大多数组织大部分时间来说都很重要，因为你不太可能不断推出服务网格升级。你会选择一个边缘版，测试它，部署它，然后等到你被迫升级或你看到一个你喜欢的功能。

你也不能只买一个许可证，你需要在 2024 年 3 月 21 日之前预定与他们的通话来购买许可证，并且有折扣可用。我不知道你怎么想，但需要同时购买许可证和预定通话购买许可证的想法同样令人沮丧。也许只让我用公司卡直接购买，或者与云提供商合作，让我通过他们支付给你。

Cilium

Cilium 是服务网格领域的新宠。它消除了边车容器，消除了服务网格设计中的一个主要故障源。你仍然可以获得加密、负载均衡等功能，但由于它使用 eBPF 并直接注入到内核中，你去除了整个栈中的那部分元素。

SDN = 软件定义网络

你也可以从 Cilium 中获得很多。它是自己的 CNI，在我的测试中表现出惊人的性能。它与所有主要云提供商兼容，为你提供极其精确的网络安全和可观察性。你还可以用 cilium 替换 Kube-proxy。这是它在普通 k8s 集群中与 Kube-proxy 一起工作的方式：

实际上 Kube-proxy 与操作系统过滤层（通常是 iptables）一起工作，允许网络通信到你的 pods。这有点简化了，但你得到了想法。

通过 BPF Kube-proxy 替换，我们在该设计中移除了很多部分。

这只是 Cilium 所做的一小部分。它已经发展出了卓越的声誉，如果你完全采用这个栈，你可以用一个在提供商间工作的通用栈替换几乎所有云提供商特定的 k8s 部分，以更低的成本和更高的性能。

Cilium 中查看服务关系的 UI 是世界级的

一个野生的 Cisco 出现了

Cisco 最近在 2023 年 12 月收购了 Isovalent，显然是为了参与 eBPF 领域，也可能是为了增强他们对 Splunk 的收购。Cilium 提供指标和追踪以及生成出色的流量日志，Splunk 为你摄取它们。如果你在使用 Linkerd 并考虑转移到 Cilium 以避免支付费用，你应该知道，随着 Cisco 的收购，最终你将被期望支付费用。

你最终将被期望支付，并且根据我多年订购 Cisco 许可证和硬件的经验，我的 _ 猜测 _ 是你将被期望支付很多。因此，在考虑 Cilium 或迁移到 Cilium 时要考虑到这一点。我会冒险预测，到 2024 年底，Cilium 将被定价为一款高端多云产品，许多功能之前需要企业许可证。我还会预测，到 2024 年底，对于大多数组织来说，Linkerd 将成为桌面上最便宜的选项。

考虑 Splunk 的昂贵程度，并将其外推到服务网格许可证中，我怀疑你会在同一范围内。

Istio

Istio，我最不喜欢的服务网格。从概念上讲，Istio 和 Linkerd 分享许多相同的想法。两个平台现在都使用了双部分架构：控制平面和数据平面。控制平面通过向数据平面中的代理发出配置更新来管理数据平面。控制平面还提供安全功能，如 mTLS 加密和身份验证。

Istio 使用 Envoy 代理，而不是像 Linkerd 那样自己滚动，倾向于覆盖比 Linkerd 更多的可能场景。这里有一个功能比较：

来源^[4]

Istio 的主要区别在于它支持 VMs，运行自己的 Ingress Controller，并且设置任何其他选项的复杂性是 10 倍。Istio 在 k8s 基础设施人员中成名，成为栈中任何其他部分引起的问题最多的原因。现在许多问题可以通过对配置进行微小修改来解决（结构上 Istio 没有任何问题），但由于服务网格故障可能意味着“整个集群死亡”，这很棘手。

现实是 Istio 是免费和开源的，但你以其他方式支付。Istio 有这么多组件和自定义资源，它们可以以令人惊讶和可怕的方式相互作用，你需要你的团队中有一个 Istio 专家。否则，任何尝试创建自助服务生态系统都会导致大量的停机时间和眼泪。你将花费大量时间在 Istio 中追踪性能问题、奇怪的网络连接问题或只是奇怪的反向代理行为。

一些早期的 Envoy 作为边车的性能投诉已经得到解决，但我仍然听说当组织扩大到每秒一定数量的请求时会遇到问题（比我以前听到的要少）。对我来说，Istio 的成本超过了服务网格的价值。尤其是因为 Linkerd 已经赶上了大多数流量管理的东西，比如断路器。

Consul Connect

我们将要讨论的下一个服务网格是 Consul Connect。如果 Istio 设置非常复杂，而 Linkerd 是最容易但可调整的旋钮最少，Consul 则正好居中。在可观察性方面，它有一个很好的故事，并且在性能方面与 Linkerd 相当，优于 Istio。

Consul 也非常明显地设计为由大公司部署，具有只适用于最大组织的稳定性和跨数据中心设计的功能。然而，根据我进行的聊天，使用过它的人似乎真的很喜欢它。使用 Terraform 与 Consul 以及其 Consul-Terraform-Sync 功能获取有关服务的信息并在网络级别与这些服务交互的能力是巨大的，尤其是对于管理成千上万个节点的团队，或者在需要严格强制隔离的 pods（如 SaaS 产品，其中客户应用服务器不能相互作用）。

定价

Consul 从每小时 0.027 美元开始，但实际上你的价格会比这更高。它基于你运行的实例数量和集群数量上升。它也不在 GCP 上提供，只在 AWS 和 Azure 上提供。你也没有得到支持，看起来需要升级你的套餐才能提问。

我对 Hashicorp 的看法很低，但人们报告说使用 Consul 取得了很多成功，所以如果你正在考虑转移，这个选择非常有意义。

云提供商服务网格

GCP 作为其 GKE 企业版的一部分提供了基于 Istio 的 Anthos，价格为每个集群每小时 0.10 美元。它附带了许多其他功能，但在我的测试中，运行 Istio 的方式更容易。基本上是没有烦人部分的 Istio。AWS App Mesh 仍然使用 Envoy，但具有相当不同的架构。然而，它不需要额外成本，这很好。

App Mesh

AWS App Mesh 对于那些并非全力以赴 k8s 的组织也很棒。你可以用它桥接像 ECS 和传统 EC2 这样的系统，这意味着它是混合组或 k8s 仅方法不是很合适的组的超级灵活工具。

Azure 使用现在已经弃用的 Open Service Mesh。尽管如此，根据 Google 搜索，它仍然是他们推荐的解决方案。链接^[5]

Azure 的精英团队再次以他们对细节的关注给我留下了深刻印象。Azure 现在有一个托管的 Istio 插件处于预览阶段，可以推测他们最终会做一些类似于 GKE 与 Anthos 的事情。你可以在这里看到。^[6]

你需要做什么

因此，免费服务网格的时代即将结束。AWS 决定使用它作为留在其平台上的激励，Linkerd 正在向你收费，Cilium 将在某个时候向你收费，Consul 现在离免费已经很远了。GKE 和 Azure 似乎都在押注 Istio，他们将复杂性转移到他们的栈中，这是有道理的。这反映了这些网格对于可观察性和韧性的价值，随着组织过渡到微服务，尤其是分割堆栈，其中你通过在多个地方运行事物来保留与你的云提供商谈判的能力。

基础设施团队将需要仔细选择他们想要使用的技术。这是云锁定与预算或复杂性成本之间灵活性的仔细平衡。在包中没有明确的赢家，这在六个月前不是真的，当时的推荐就是 Linkerd 或 Cilium。如果你被锁定在 Linkerd 或 Cilium 中，现在可能是开始讨论前进策略的时候了。要么准备好账单，承诺使用更多内部测试运行 Edge，或者为将来可能更高的账单做好准备。

欢迎加入云原生社区或向社区投稿，点击阅读原文了解更多。

引用链接

[1] Mathew Duggan: https://matduggan.com/author/mathew/
[2] K8s Service Meshes: The Bill Comes Due: https://matduggan.com/k8s-service-meshes/
[3] 你可以在这里阅读博客文章。: https://linkerd.io/2024/02/21/announcing-linkerd-2.15/
[4] 来源: https://imesh.ai/blog/istio-vs-linkerd-the-best-service-mesh-for-2023/
[5] 链接: https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&cad=rja&uact=8&ved=2ahUKEwiuxPjy9siEAxV2SfEDHYtAB0AQFnoECEEQAQ&url=https%3A%2F%2Flearn.microsoft.com%2Fen-us%2Fazure%2Faks%2Fopen-service-mesh-integrations&usg=AOvVaw0wGhzZfvWvaZYibMqt_-Z_&opi=89978449
[6] 你可以在这里看到。: https://learn.microsoft.com/en-us/azure/aks/istio-deploy-addon