Kubernetes 服务网格比较

在讨论微服务架构和容器化时，一组经过生产验证的工具近年来吸引了大部分注意力：服务网格。

事实上，微服务架构和 Kubernetes（通常是风格化的“K8s”）已经迅速成为可扩展应用程序的标准，这使得管理服务之间的通信问题成为热门话题，而服务网格也是一个有吸引力的解决方案。 我自己在生产中使用过服务网格，特别是 Linkerd、Istio 和早期形式的 Ambassador。 但是服务网格到底是做什么的呢？ 哪个最好用？ 你怎么知道你是否应该使用一个？

要回答这些问题，有助于理解为什么要开发服务网格。 从历史上看，传统的 IT 基础设施的应用程序都是作为单体运行的。 一项服务在一台服务器上运行； 如果它需要更多容量，解决方案是通过配置更大的机器来垂直扩展它。

达到这种方法的极限后，大型科技公司迅速采用了三层架构，将负载均衡器与应用程序服务器和数据库层分开。 虽然这种架构在一定程度上保持可扩展性，但他们决定将应用程序层分解为微服务。 为了使应用程序扩展，这些服务之间的通信对于监控和保护变得至关重要。

为了实现服务间通信，这些公司开发了内部库：Twitter 的 Finagle、Netflix 的 Hystrix 和 Google 的 Stubby（2016 年成为 gRPC）。 这些库旨在解决微服务架构引发的问题：服务之间的安全性、延迟、监控和负载平衡。 但是以多种语言将大型库作为依赖项进行管理是复杂且耗时的。

最后，这种类型的库被更易于使用的轻量级代理所取代。 此类代理在外部独立于应用程序层——对应用程序可能是透明的——并且更易于更新、维护和部署。 于是，服务网格诞生了。

什么是服务网格？

服务网格是用于控制服务之间通信的软件基础设施层； 它通常由两个组件组成：

1. 数据平面，处理应用程序附近的通信。 通常，这与应用程序一起部署为一组网络代理，如前所述。
2. 控制平面，是服务网格的“大脑”。 控制平面与代理交互以推送配置、确保服务发现和集中可观察性。

服务网格围绕服务间通信具有三个主要目标：

1. 连接性
2. 安全
3. 可观察性

连接性

服务网格架构的这一方面允许服务发现和动态路由。 它还涵盖了通信弹性，例如重试、超时、断路和速率限制。

服务网格的一个主要特性是负载均衡。 由代理网状的所有服务都允许在服务之间实施负载平衡策略，例如循环、随机和最少请求。 这些策略是服务网格用来决定哪个副本将接收原始请求的策略，就像在每个服务前面都有微型负载均衡器一样。

最后，服务网格以流量转移和镜像的形式提供路由控制。

安全

在传统的微服务架构中，服务之间通过未加密的流量进行通信。 如今，未加密的内部流量在安全性方面被认为是一种不好的做法，尤其是对于公共云基础设施和零信任网络。

除了在无法直接控制硬件的情况下保护客户端数据的隐私之外，加密内部流量还增加了一个受欢迎的额外复杂性，以防系统遭到破坏。 因此，所有服务网格都使用双向 TLS (mTLS)加密进行服务间通信，即所有代理间通信。

服务网格甚至可以强制执行复杂的授权策略矩阵，根据针对特定环境和服务的策略允许或拒绝流量。

可观察性

服务网格的目标是为服务间通信带来可见性。 通过控制网络，服务网格强制实施可观察性，提供第七层指标，这反过来又允许在流量达到某个可定制的阈值时自动发出警报。

通常由 Jaeger 或 Zipkin 等第三方工具或插件支持，此类控件还允许通过注入 HTTP 跟踪标头进行跟踪。

服务网格的好处

创建服务网格是为了抵消微服务架构造成的一些操作负担。 那些在微服务架构方面有经验的人都知道，他们每天都需要做大量的工作。 充分利用微服务的潜力通常需要外部工具来处理集中式日志记录、配置管理和可扩展性机制等。 使用服务网格可以标准化这些功能，以及它们的设置和集成。

特别是服务网格可观察性提供了极其通用的调试和优化方法。 由于对服务之间交换的精细和完整的可见性，工程师（尤其是 SRE）可以更快地排除可能的错误和系统错误配置。 通过服务网格跟踪，他们可以跟踪从进入系统（在负载均衡器或外部代理）到堆栈内的私有服务的请求。 他们可以使用日志记录来映射请求并记录它在每个服务中遇到的延迟。 最终结果：详细了解系统性能。

在升级到服务的新版本的完整版本之前，流量管理提供了强大的可能性：

1. 重新路由一小部分请求。
2. 更好的是，将生产请求镜像到新版本，以通过实时流量测试其行为。
3. A/B 测试任何服务或服务组合。

服务网格简化了上述所有场景，使其更容易避免和/或减轻生产中的任何意外。

Kubernetes 服务网格比较

在许多方面，服务网格是微服务架构的终极工具集； 它们中的许多都在顶级容器编排工具之一 Kubernetes 上运行。 我们选择了今天在 Kubernetes 上运行的三个主要服务网格：Linkerd (v2)、Istio 和 Consul Connect。 我们还将讨论其他一些服务网格：Kuma、Traefik Mesh 和 AWS App Mesh。 虽然目前在使用和社区方面不太突出，但他们很有希望在这里进行审查并保持关注。

关于 Sidecar 代理的快速说明

并非所有 Kubernetes 服务网格都采用相同的架构方法，但一种常见的方法是利用 sidecar 模式。 这涉及将代理（sidecar）附加到主应用程序以拦截和调节应用程序的入站和出站网络流量。 实际上，这是在 Kubernetes 中通过每个应用程序 pod 中的辅助容器完成的，该容器将遵循应用程序容器的生命周期。

服务网格的 Sidecar 方法有两个主要优点：

• Sidecar 代理独立于运行时甚至应用程序的编程语言。
  • 这意味着在整个堆栈中，无论在何处使用，都可以轻松启用服务网格的所有功能。
• Sidecar 具有与应用程序相同级别的权限和对资源的访问权限。
  • Sidecar 可以帮助监控主应用程序使用的资源，而无需将监控集成到主应用程序代码库中。

但是 sidecar 是喜忧参半，因为它们直接影响应用程序：

• Sidecar 初始化可能会使应用程序的启动机制死锁。
• Sidecar 代理会在您的应用程序之上增加潜在的延迟。
• Sidecar 代理还增加了资源占用，这可能会在规模上花费大量资金。

鉴于这些优点和缺点，sidecar 方法经常成为服务网格社区中争论的主题。 也就是说，这里比较的六个服务网格中有四个使用 Envoy sidecar 代理，而 Linkerd 使用自己的 sidecar 实现； Traefik Mesh 在其设计中不使用边车。

Linkerd 评论

Linkerd 于 2017 年首次亮相，是市场上最古老的服务网格。 Linkerd v1 由 Buoyant（一家由两名前 Twitter 工程师创办的公司）创建，基于 Finagle 和 Netty。

Linkerd v1 被描述为领先于时代，因为它是一个完整的、可用于生产的服务网格。 同时，它在资源使用方面有点沉重。 此外，文档中的重大差距使得难以在生产中设置和运行。

有了这个，Buoyant 有机会使用完整的生产模型，从中获得经验，并应用这种智慧。 结果是 Conduit，该公司于 2018 年发布了完整的 Linkerd 重写，并在当年晚些时候更名为 Linkerd v2。 Linkerd v2 带来了一些引人注目的改进； 由于 Buoyant 对 Linkerd v1 的积极开发很久以前就停止了，我们在本文其余部分提到的“Linkerd”指的是 v2。

完全开源，Linkerd 依赖于用 Rust 编写的自制代理作为数据平面和用 Go 编写的源代码作为控制平面。

连接性

Linkerd 代理具有重试和超时功能，但在撰写本文时没有断路或延迟注入。 入口支持广泛； Linkerd 拥有与以下入口控制器的集成：

• 特拉菲克
• Nginx
• 普通教育证书
• 大使
• 格洛
• 轮廓
• 孔

Linkerd 中的服务配置文件提供增强的路由功能，提供用户指标、重试调整和超时设置，所有这些都基于每个路由。 至于负载均衡，Linkerd 提供自动代理注入、自己的仪表板和对 Grafana 的原生支持。

安全

Linkerd 中的 mTLS 支持很方便，因为它的初始设置是自动的，就像它的自动每日密钥轮换一样。

可观察性

开箱即用，Linkerd 统计数据和路由可通过 CLI 观察。 在 GUI 方面，选项包括预制的 Grafana 仪表板和本机 Linkerd 仪表板。

Linkerd 可以插入 Prometheus 的实例。

可以通过使用 OpenTelemetry（以前称为 OpenCensus）作为收集器的附加组件启用跟踪，并由 Jaeger 自己进行跟踪。

安装

Linkerd 安装是通过注入一个 sidecar 代理来完成的，这是通过在 Kubernetes 中为您的资源添加注释来完成的。 有两种方法可以解决这个问题：

1. 使用 Helm 图表。 （对于许多人来说，Helm 是 Kubernetes 资源的首选配置和模板管理器。）
2. 安装 Linkerd CLI，然后使用它将 Linkerd 安装到集群中。

第二种方法从下载并运行安装脚本开始：

 curl -sL https://run.linkerd.io/install | sh

从那里，Linkerd CLI 工具linkerd提供了一个有用的工具包，可帮助安装 Linkerd 的其余部分并与应用程序集群和控制平面进行交互。

linkerd check --pre将运行您的 Linkerd 安装所需的所有初步检查，提供清晰准确的日志，说明潜在的 Linkerd 安装可能无法正常工作的原因。 如果没有--pre ，此命令可用于安装后调试。

下一步是通过运行以下命令在集群中安装 Linkerd：

 linkerd install | kubectl apply -f -

然后，Linkerd 将安装许多不同的组件，占用的资源非常少； 因此，他们自己有一种微服务方法：

• linkerd-controller ，它提供了 CLI 和仪表板与之交互的公共 API
• linkerd-identity ，它提供了实现 mTLS 的证书颁发机构
• linkerd-proxy-injector ，它通过改变 pod 的配置来处理代理的注入
• linkerd-web ，它提供了一个仪表板，允许监控部署和 Pod，以及内部 Linkerd 组件

Linkerd 的大部分配置基于CustomResourceDefinitions (CRD)。 这被认为是开发 Kubernetes 附加软件时的最佳实践——就像在 Kubernetes 集群中持久安装插件一样。

添加分布式跟踪——由于一些常见的误解，这可能是也可能不是 Linkerd 用户实际追求的——需要使用 linkerd-collector 和 linkerd-jaeger 的另一个步骤。 为此，我们将首先创建一个配置文件：

 cat >> config.yaml << EOF tracing: enabled: true EOF

要启用跟踪，我们将运行：

 linkerd upgrade --config config.yaml | kubectl apply -f -

与任何基于 sidecar 代理的服务网格一样，您需要修改应用程序代码以启用跟踪。 其中大部分只是添加一个客户端库来传播跟踪标头； 然后需要将它包含在每个服务中。

Linkerd 的流量拆分功能通过其符合服务网格接口 (SMI) 的 API 公开，已经允许金丝雀发布。 但要使它们和流量管理自动化，您还需要像 Flagger 这样的外部工具。

Flagger 是一种渐进式交付工具，它将评估 Linkerd 所谓的“黄金”指标：“请求量、成功率和延迟分布”。 （最初，Google SRE 使用术语黄金信号并包括第四个信号——饱和度——但 Linkerd 并未涵盖它，因为这需要无法直接访问的指标，例如 CPU 和内存使用情况。）Flagger 在拆分流量时跟踪这些指标使用反馈回路； 因此，您可以实现自动化和指标感知的金丝雀版本。

在深入研究安装过程之后，很明显要让 Linkerd 服务网格运行并利用通常需要的功能，很容易最终运行至少十几个服务。 也就是说，与其他服务网格相比，它们中的更多是由 Linkerd 在安装时提供的。

Linkerd 服务网格总结

优点：

Linkerd 受益于其创建者的经验，两位前 Twitter 工程师曾在内部工具 Finagle 上工作，后来从 Linkerd v1 中学习。 作为最早的服务网格之一，Linkerd 拥有一个蓬勃发展的社区（它的 Slack 拥有超过 5,000 名用户，此外它还有一个活跃的邮件列表和 Discord 服务器）以及大量的文档和教程。 Linkerd 2.9 版的发布已经成熟，Nordstrom、eBay、Strava、Expedia 和 Subspace 等大公司采用了它就证明了这一点。 来自 Buoyant 的付费企业级支持可用于 Linkerd。

缺点：

要充分发挥 Linkerd 服务网格的潜力，有一个非常强大的学习曲线。 Linkerd 仅在 Kubernetes 容器中受支持（即，没有基于 VM 的“通用”模式）。 Linkerd sidecar 代理不是 Envoy。 虽然这确实允许 Buoyant 在他们认为合适的时候对其进行调整，但它消除了 Envoy 提供的固有可扩展性。 这也意味着 Linkerd 缺少对断路、延迟注入和速率限制的支持。 没有公开特定的 API 来轻松控制 Linkerd 控制平面。 （不过，您可以找到 gRPC API 绑定。）

自 v1 以来，Linkerd 在可用性和易于安装方面取得了长足的进步。 缺乏官方公开的 API 是一个明显的遗漏。 但多亏了经过深思熟虑的文档，Linkerd 中的开箱即用功能很容易测试。

领事连接评论

我们的下一个服务网格竞争者 Consul Connect 是一个独特的混合体。 HashiCorp 的 Consul 以其分布式架构的键值存储而闻名，该技术已经存在多年。 在 Consul 演变成一整套服务工具之后，HashiCorp 决定在其之上构建一个服务网格：Consul Connect。

确切地说，它的混合性质：

Consul Connect 数据平面基于 Envoy，它是用 C++ 编写的。 Consul Connect 的控制平面是用 Go 编写的。 这是由键值存储 Consul KV 支持的部分。

与大多数其他服务网格一样，Consul Connect 通过在应用程序 pod 中注入 sidecar 代理来工作。 在架构方面，Consul Connect 是基于代理和服务器的。 开箱即用，Consul Connect 旨在使用三或五台服务器作为指定 pod 反关联性的StatefulSet来实现高可用性 (HA)。 Pod 反亲和性是确保分布式软件系统的 Pod 不会最终位于同一节点（服务器）上的做法，从而保证在任何单个节点发生故障时的可用性。

连接性

Consul Connect 在这一领域脱颖而出的原因并不多。 它提供了任何服务网格的功能（相当多），以及用于基于路径的路由、流量转移和负载平衡的第七层功能。

安全

与其他服务网格一样，Consul Connect 提供基本的 mTLS 功能。 它还具有 Consul 和 Vault 之间的本地集成（也由 HashiCorp 提供），可用作 CA 提供程序来管理和签署集群中的证书。

可观察性

Consul Connect 采用最常见的可观察性方法，将 Envoy 合并为 sidecar 代理以提供第七层功能。 配置 Consul Connect 的 UI 以获取指标涉及更改内置配置文件并启用像 Prometheus 这样的指标提供程序。 还可以配置一些 Grafana 仪表板以显示相关的特定于服务的指标。

安装

Consul Connect 使用 Helm 图表安装到 Kubernetes 集群中：

 helm repo add hashicorp https://helm.releases.hashicorp.com

如果要启用 UI 或让 Consul Connect 模块注入其 sidecar 代理，则需要修改默认values.yaml ：

 helm install -f consul-values.yml hashicorp hashicorp/consul

要咨询成员并检查各个节点，Consul 建议exec到其中一个容器中，然后使用 CLI 工具consul 。

要提供 Consul 提供的开箱即用 Web UI，请运行kubectl port-forward service/hashicorp-consul-ui 18500:80 。

Consul Connect 服务网格总结

优点：

• Consul 得到 HashiCorp 的支持； 作为免费增值产品，还有一个带有附加功能的企业版，可提供企业级支持。 就开发团队的经验而言，Consul 是市场上最古老的工具之一。
• Consul 拥有稳固的企业社区，并且以在具有 50,000 个节点的基础设施上运行而闻名。 此外，它自 2014 年以来一直存在，使其成为相对于市场而言的成熟产品。
• 由于本机支持，Consul Connect 在 VM 内运行良好。
• 使用 Consul Connect，可以实现与顶级科技公司的服务前网格实施一样深入的应用程序集成。 这要归功于完整记录的库级 API 的公开。

缺点：

• Consul Connect 的学习曲线比其他服务网格更陡峭，并且需要更多调整才能运行可视化仪表板和指标。
• HashiCorp 的文档并不简单，让用户去挖掘和试验以正确配置它。
• 流量管理文档很难找到，并且主要包含指向 Envoy 文档的链接，其中没有特别提供有关 Consul Connect 流量管理的详细信息。
• Consul Connect 的 SMI 接口仍处于试验阶段。

对于那些寻求企业级产品的人来说，Consul Connect 可能是一个非常好的选择。 HashiCorp 以其产品质量而闻名，Consul Connect 也不例外。 与其他服务网格相比，我可以在这里看到两个强大的优势：公司对企业版的强大支持和适用于各种架构（不仅仅是 Kubernetes）的工具。

Istio 评论

2017 年 5 月，谷歌、IBM 和 Lyft 宣布推出 Istio。 当 Istio 进入服务网格工具竞赛时，它在技术领域获得了很好的曝光率。 它的作者在 1.9 版中一直根据用户反馈添加功能。

Istio 在当时承诺了超越其竞争对手的重要新功能：自动负载平衡、故障注入等等。 这为它赢得了社区的广泛关注，但正如我们将在下面详细介绍的那样，使用 Istio 绝非易事：Istio 被认为投入生产特别复杂。

从历史上看，Istio 项目在源代码更改方面经常出现反弹。 一旦为控制平面采用微服务架构，Istio 现在（从 1.5 版开始）又回到了单体架构。 Istio 回归集中化的理由是，微服务很难让运维人员监控，代码库过于冗余，而且项目已经达到组织成熟度——不再需要许多小团队在孤岛中工作。

然而，在此过程中，Istio 因拥有最多的开放 GitHub 问题之一而臭名昭著。 在撰写本文时，该数量约为 800 个未解决问题和约 12,000 个已关闭问题。 虽然问题计数可能具有欺骗性，但在这种情况下，它们确实代表了以前损坏的功能和失控的资源使用方面的有意义的改进。

连接性

与 Consul Connect 和 Linkerd 相比，Istio 在流量管理方面非常强大。 这要归功于提供了广泛的子功能：请求路由、故障注入、流量转移、请求超时、断路以及控制服务网格的入口和出口流量。 虚拟服务和目标规则的概念使其在流量管理方面非常完整。

然而，所有这些可能性都伴随着学习曲线，以及对 Kubernetes 集群上这些新资源的管理。

安全

Istio 拥有一整套与安全相关的工具，主要有两个方面：身份验证和授权。 Istio 可以在不同的范围内实施不同级别的策略：特定于工作负载、命名空间范围或网格范围。 所有此类安全资源都通过 Istio CRD 进行管理，例如AuthorizationPolicy或PeerAuthentication 。

除了标准的 mTLS 支持之外，Istio 还可以配置为接受或拒绝未加密的流量。

可观察性

在这里，Istio 非常先进，开箱即用，有多种遥测技术提供对服务网格的深入洞察。 指标基于四个黄金信号（延迟、流量、错误，在某种程度上，饱和度）。

值得注意的是，Istio 为控制平面本身提供了指标。 它还提供分布式跟踪和访问日志，具有与 Jaeger、Lightstep 和 Zipkin 的明确兼容性以启用跟踪。

没有原生仪表板，但有官方支持 Kiali 管理控制台。

安装

安装就像按照官方步骤一样简单。 Istio 也作为 beta 功能原生集成到 GKE 中，但 GKE 使用 Istio 1.4.X，较旧的微服务版本，而不是最新的单体版本。

原生安装从下载最新版本开始：

 curl -L https://istio.io/downloadIstio | sh -

在cd进入新创建的istio-*文件夹后，您可以将其添加到您的路径中，以便您可以使用istioctl实用工具：

 export PATH=$PWD/bin:$PATH

从那里，您可以通过istioctl将 Istio 安装到您的 Kubernetes 集群：

 istioctl install

这将使用default配置文件安装 Istio。 istioctl配置文件允许您创建不同的安装配置并在必要时在它们之间切换。 但是即使在单配置的场景下，你也可以通过修改一些 CRD 来深度定制 Istio 的安装。

Istio 资源将更难管理，因为您需要管理多种 CRD——至少VirtualService 、 DestinationRule和Gateway以确保流量管理到位。

• VirtualService资源是声明服务和应用于请求的不同路由规则的配置。
• DestinationRule资源用于对特定于目标的流量策略进行分组和实施。
• 创建Gateway资源来管理入站和出站服务网格流量（即，额外的 Envoy 代理，但在边缘运行而不是作为边车。）

语义细节超出了本次审查的范围，但让我们看一个快速示例，展示其中的每一个一起工作。 假设我们有一个电子商务网站，其中包含一项名为products的服务。 我们的VirtualService可能如下所示：

 apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: products-route namespace: ecommerce spec: hosts: - products # interpreted as products.ecommerce.svc.cluster.local http: - match: - uri: prefix: "/listv1" - uri: prefix: "/catalog" rewrite: uri: "/listproducts" route: - destination: host: products # interpreted as products.ecommerce.svc.cluster.local subset: v2 - route: - destination: host: products # interpreted asproducts.ecommerce.svc.cluster.local subset: v1

相应的DestinationRule可以是：

 apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: products spec: host: products trafficPolicy: loadBalancer: simple: RANDOM # or LEAST_CONN or ROUND_ROBIN subsets: - name: v1 labels: version: v1 - name: v2 labels: version: v2 - name: v3 labels: version: v3

最后，我们的Gateway ：

 apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: cert-manager-gateway namespace: istio-system spec: selector: istio: ingressgateway servers: - port: number: 80 name: http protocol: HTTP hosts: - "*"

有了这三个文件，Istio 安装就可以处理基本流量了。

Istio 服务网格总结

优点：

• 在不同的服务网格中，Istio 是撰写本文时拥有最大在线社区的服务网格。 Stack Overflow 的结果是其主要竞争对手的 10 倍以上，它是网络上最受关注的服务网格； 它的 GitHub 贡献者同样比 Linkerd 高出一个数量级。
• Istio 同时支持 Kubernetes 和 VM 模式； 后者在 1.9 版中处于测试阶段。

缺点：

• Istio 不是免费的，从两个方面来说：
  • 在阅读文档、设置文档、使其正常工作和维护文档所需的时间方面，它的要求很高。 根据基础设施规模和服务数量，Istio 将需要数周到数月的全职工作才能完全发挥作用并集成到生产中。
  • 它还增加了大量的资源开销：Envoy 容器每秒每 1,000 个请求 (RPS) 将需要 350 个毫核 (mCPU)。 甚至控制平面本身也会消耗资源。 （以前，资源使用情况很难预测，但经过一些努力， istiod已稳定在使用 1 个 vCPU 和 1.5 GB 内存左右。）
• 与 Linkerd 不同，它没有本地管理仪表板。
• Istio 需要使用自己的入口网关。
• Istio 控制平面仅在 Kubernetes 容器中受支持（即，与 Istio 的数据平面不同，没有 VM 模式）。

Istio 是科技巨头携手创建开源项目以应对他们都面临的挑战的一个很好的例子。 Istio 项目作为一个整体花费了一些时间来构建自身（回顾微服务到单体架构的转变）并解决其许多初始问题。 今天，Istio 完全可以满足人们对服务网格的期望，并且可以大大扩展。 但所有这些可能性都伴随着对知识、工作时间和计算资源的苛刻要求，以支持其在生产环境中的使用。

隈研吾快速回顾

由 Kong 创建然后开源的 Kuma 在 2020 年底达到了 1.0。在某种程度上，它是为了应对第一个服务网格相当重且难以操作的情况而创建的。

它的功能列表表明它非常模块化； Kuma 背后的想法是将其导向与已经在 Kubernetes 或其他基础设施上运行的应用程序的集成。

• 在流量管理领域，Kuma 提供了常见的服务网格功能，例如故障注入和断路。
• 除了服务间 mTLS 加密之外，数据平面和控制平面之间的交换通过数据平面代理令牌在 Kuma 中得到保护。
• 在 Kuma 中，可观察性是通过围绕指标、跟踪和日志记录的不同流量策略定义的。
• 由于 Kuma 自己的 DNS 解析器在控制平面的端口 5653 上运行，服务发现可以通过 Kuma 获得。
• Kuma 非常强调多网格功能：您可以轻松地将多个 Kubernetes 集群或 VM 环境组合成一个具有多区域部署类型的通用 Kuma 集群。
• Kuma 为现有的 Kong 用户轻松与 Kong Gateway 集成。

Kuma 的通用（非 Kubernetes）版本需要 PostgreSQL 作为依赖项，而 Kong 的 CTO 一直特别反对支持 SMI。 但 Kuma 从一开始就基于多云和多集群部署的理念而开发，其仪表板反映了这一点。

虽然 Kuma 在服务网格领域还很年轻，到目前为止还很少有生产使用的案例，但它是一个有趣且有前途的竞争者。

Traefik Mesh 快速回顾

Traefik Mesh（由 Traefik Labs 开发）最初名为 Maesh，是服务网格工具竞赛中的另一个新人。 项目使命是通过使其易于使用和配置来使服务网格民主化； 开发人员使用经过深思熟虑的 Traefik Proxy 的经验使他们处于实现这一目标的首要位置。

• Traefik Mesh 中的流量管理功能包括断路和速率限制。
• 在可观察性方面，Traefik Mesh 具有原生 OpenTracing 支持和开箱即用的指标（标准安装自动包括 Prometheus 和 Grafana），从而节省了设置时间。
• 为了安全——除了 mTLS——规范是符合 SMI 的，Traefik Mesh 允许通过访问控制微调流量权限。

Traefik Mesh 需要在集群上安装 CoreDNS。 （虽然 Azure 自 1.12 起默认使用 CoreDNS，但 GKE 在撰写本文时默认使用 kube-dns，这意味着在这种情况下涉及一个重要的额外步骤。）它还缺乏多集群功能。

也就是说，Traefik Mesh 在我们的服务网格比较中是独一无二的，因为它不使用边车注入。 相反，它作为 DaemonSet 部署在所有节点上，充当服务之间的代理，使其具有非侵入性。 总体而言，Traefik Mesh 易于安装和使用。

AWS App Mesh 快速回顾

在云提供商的世界中，AWS 是第一个实现可插入 Kubernetes（或特别是 EKS）以及其他服务的本机服务网格的公司。 AWS App Mesh 于 2018 年 11 月发布，从那时起 AWS 一直在对其进行迭代。 AWS App Mesh 的主要优势在于已有的 AWS 生态系统和市场地位； AWS 背后的大型社区将继续推动其使用和可用性。

• AWS App Mesh 中的流量管理包括常见功能之上的断路。
• 由于 AWS App Mesh 由 AWS 托管，因此它是一项完全托管的服务，这意味着不必担心资源使用或控制平面的可用性。
• AWS App Mesh 中的可观察性可以通过 Prometheus 或 AWS X-Ray 完成。

The project is not open source, doesn't support SMI, and there's not much info online about HA standards for the control plane. AWS App Mesh is more complex to set up than other Kubernetes-native service meshes and has very little community online (24 answers on Stack Overflow, 400 stars on GitHub) but that's because users are meant to benefit from AWS support.

AWS App Mesh has native integration with AWS, starting with EKS and extending to other AWS services like ECS (Fargate) and EC2. Unlike Traefik Mesh, it has multicluster support. Plus, like most service meshes, it's based on injecting Envoy, the battle-tested sidecar proxy.

Kubernetes Service Mesh Comparison Tables

The six Kubernetes service mesh options presented here have a few things in common:

• Protocol support : They all work with HTTP, HTTP/2, gRPC, TCP, and WebSockets.
• They all have basic security in the form of mTLS between proxies by default.
• Service meshes, by design, provide some form of load balancing .
• These six, at least, also include a request retrying option among their traffic management features.
• Lastly, service discovery is a core feature of any service mesh.

But there are certainly differences worth highlighting when it comes to service mesh infrastructure, traffic management, observability, deployment, and other aspects.

基础设施

交通管理

可观察性

* OpenCensus and OpenTracing merged into OpenTelemetry in 2019, but you might find Linkerd articles referring to OpenCensus, as well as Istio and Traefik Mesh articles referring to OpenTracing.

部署

Other Service Mesh Considerations

Should We Use a Kubernetes Service Mesh?

Now that we have seen what service meshes are, how they work, and the multitude of differences between them, we can ask: Do we need a service mesh?

That's the big question for SREs and cloud engineers these past few years. Indeed, microservices bring operational challenges in network communication that a service mesh can solve. But service meshes, for the most part, bring their own challenges when it comes to installation and operation.

One problem we can see emerging in many projects is that with service meshes, there is a gap between the proof-of-concept stage and the production stage. That is, it's unfortunately rare for companies to achieve staging environments that are identical to production in every aspect; with service meshes involving crucial infrastructure, scale- and edge-related effects can bring deployment surprises.

Service meshes are still under heavy development and improvement. This could actually be attractive for teams with high deployment velocities—those who have mastered “the art of staying state-of-the-art” and can closely follow the development cycle of cloud-native tools.

For others, though, the pace of service mesh evolution could be more of a pitfall. It would be easy enough to set up a service mesh but then forget about the need to maintain it. Security patches may go unapplied or, even if remembered, may carry with them unplanned issues in the form of deprecated features or a modified set of dependencies.

There's also a notable cost in terms of manpower to set up a service mesh in production. It would be a sensible goal for any team to evaluate this and understand if the benefits from a service mesh would outweigh the initial setup time. Service meshes are hard, no matter what the “easy” demo installations show.

In short, service meshes can solve some of the problems typical to projects deployed at scale but may introduce others, so be prepared to invest time and energy. In a hypothetical infrastructure involving 25 microservices and load of five queries per second, I would recommend having at least one person (preferably two) dedicated for at least a month to preparing a proof of concept and validating key aspects before thinking about running it in production. Once it's set up, anticipate the need for frequent upgrades—they will impact a core component of your infrastructure, namely network communications.

Kubernetes Service Meshes: A (Complex) Evolution in Scalable App Architecture

We've seen what service meshes are: a suite of tooling to answer new challenges introduced by microservices architecture. Through traffic management, observability, service discovery, and enhanced security, service meshes can reveal deep insights into app infrastructure.

There are multiple actors on the market, sometimes promoted by GAFAM et al., that have in some cases open-sourced or promoted their own internal tooling. Despite two different implementation types, service meshes will always have a control plane—the brain of the system—and a data plane, made of proxies that will intercept the requests of your application.

Reviewing the three biggest service meshes (Linkerd, Consul Connect, and Istio) we have seen the different strategies they've chosen to implement and the advantages they bring. Linkerd, being the oldest service mesh on the market, benefits from its creators' experience at Twitter. HashiCorp, for its part, offers the enterprise-ready Consul Connect, backed by a high level of expertise and support. Istio, which initially garnered ample attention online, has evolved into a mature project, delivering a feature-complete platform in the end.

But these actors are far from being the only ones, and some less-talked-about service meshes have emerged: Kuma, Traefik Mesh, and AWS App Mesh, among others. Kuma, from Kong, was created with the idea of making the service mesh idea “simple” and pluggable into any system, not just Kubernetes. Traefik Mesh benefited from experience with the preexisting Traefik Proxy and made the rare decision to eschew sidecar proxies. Last but not least, AWS decided to develop its own version of the service mesh, but one that relies on the dependable Envoy sidecar proxy.

In practice, service meshes are still hard to implement. Although service mesh benefits are compelling, their impact, critically, cuts both ways: Failure of a service mesh could render your microservices unable to communicate with each other, possibly bringing down your entire stack. A notorious example of this: Incompatibility between a Linkerd version and a Kubernetes version created a complete production outage at Monzo, an online bank.

Nonetheless, the whole industry is structuring itself around Kubernetes and initiatives like the Microsoft-spearheaded SMI, a standard interface for service meshes on Kubernetes. Among numerous other projects, the Cloud Native Computing Foundation (CNCF) has the Envoy-based Open Service Mesh (OSM) initiative, which was also originally introduced by Microsoft. The service mesh ecosystem remains abuzz, and I predict a champion emerging in the coming years, the same way Kubernetes became the de facto container orchestration tool.