Linkerd、Consul、Istio、Kuma、Traefik、AWS App服务网格全方位对比

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

确实，微服务架构和Kubernetes（通常是K8S）已迅速成为可伸缩应用程序的规范，这使得管理服务之间的通信问题成为热门话题，并且服务网格成为一种有吸引力的解决方案。我本人在生产中使用了服务网格，特别是Linkerd，Istio和早期的Ambassador形式。但是，服务网格的作用到底是什么？最好使用哪一个？您怎么知道是否应该使用那一个？

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

由于达到了这种方法的局限性，大型科技公司迅速采用了三层架构，将负载均衡器与应用程序服务器和数据库层分开。尽管该体系结构仍具有一定的可伸缩性，但他们决定将应用程序层分解为微服务。为了扩展应用程序，这些服务之间的通信对于监控和保护变得至关重要。

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

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

什么是服务网格？

服务网格是用于控制服务之间的通信的软件基础结构层。它通常由两个部分组成：

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

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

连接性
安全
可观察性

连接性

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

服务网格的主要特征是负载平衡。通过代理划分网格的所有服务都允许在服务之间实施负载平衡策略，例如轮询，随机请求和最少请求。这些策略是服务网格用来决定哪个副本将接收原始请求的策略，就像您在每个服务前面都装有很小的负载平衡器一样。

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

安全

在传统的微服务体系结构中，服务之间使用未加密的流量进行通信。如今，就安全性而言，未加密的内部流量被认为是一种不良做法，尤其是对于公有云基础架构和零信任网络而言。

除了在无法直接控制硬件的情况下保护客户端数据的私密性之外，对内部流量进行加密还会在系统出现漏洞的情况下增加一层额外的复杂性。因此，所有服务网格都使用相互TLS（mTLS）加密进行服务间通信，即所有代理间通信。

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

可观察性

服务网格的目标是使服务间通信具有可见性。通过控制网络，服务网格可增强可观察性，提供七层度量，从而在流量达到某些可自定义阈值时自动发出警报。

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

服务网格的好处

创建服务网格是为了抵消微服务体系结构所带来的一些运营负担。那些具有微服务架构经验的人知道，他们每天需要花费大量的工作来进行操作。要充分利用微服务的潜力，通常需要外部工具来处理集中式日志记录，配置管理和可伸缩性机制等。使用服务网格可标准化这些功能及其设置和集成。

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

流量管理提供了强大的可能性，然后才能逐步发布服务的新版本：

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

服务网格简化了上述所有场景，从而更容易避免或减轻生产中的任何意外情况。

Kubernetes服务网格比较

在许多方面，服务网格是微服务体系结构的终极工具集。他们中的许多人都在顶级容器编排工具之一Kubernetes上运行。我们选择了当今在Kubernetes上运行的三个主要服务网格：Linkerd（v2），Istio和Consul Connect。我们还将讨论其他一些服务网格：Kuma，Traefik Mesh和AWS App Mesh。尽管目前在使用和社区方面不那么突出，但他们有足够的希望在这里进行评论并保持常规状态。

关于Sidecar代理的快速说明

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

服务网格的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，这是Linkerd的完整重写，于2018年发布，并于当年晚些时候重命名了Linkerd v2。Linkerd v2带来了一些引人注目的改进。由于Buoyant很早就停止了对Linkerd v1的积极开发，因此本文其余部分中对Linkerd的提及均指v2。

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

连接性

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

Traefik
Nginx
GCE
Ambassador
Gloo
Contour
Kong

Linkerd中的服务配置文件提供增强的路由功能，为每个路由提供用户指标，重试调整和超时设置。至于负载均衡，Linkerd提供自动代理注入，其自己的仪表板以及对Grafana的本地支持。

安全

Linkerd中的mTLS支持非常方便，因为它的初始设置是自动的，并且它的每日自动密钥轮换也是自动的。

可观察性

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

Linkerd可以插入Prometheus实例。

可以通过使用OpenTelemetry（以前称为OpenCensus）作为收集器的插件来启用跟踪，而Jaeger可以自己进行跟踪。

安装

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

使用helm。（对于许多人来说，Helm是Kubernetes资源的首选配置和模板管理器。）
安装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的流量拆分功能通过其符合Service Mesh Interface（SMI）的API公开，已经允许发布canary版本。但是要使它们自动化和流量管理，您还需要外部工具，例如Flagger。

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

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

Linkerd服务网格摘要

优点：

Linkerd受益于其创建者的经验，两位曾在内部工具Finagle上工作的前Twitter工程师，后来从Linkerd v1中学习。作为最早的服务网格之一，Linkerd拥有一个蒸蒸日上的社区（其Slack有5,000多个用户，还有一个活动的邮件列表和Discord服务器）以及大量的文档和教程。Linkerd的2.9版已经很成熟，这一点已被Nordstrom，eBay，Strava，Expedia和Subspace等大公司采用。对于Linkerd，Buoyant提供了有偿的企业级支持。

缺点：

要使用Linkerd服务网格发挥其全部潜能，有一条相当强的学习曲线。Linkerd仅在Kubernetes容器中受支持（即，没有基于VM的“通用”模式）。Linkerd Sidecar代理不是Envoy。尽管这确实使Buoyant可以按照自己的意愿进行调整，但它消除了Envoy提供的固有可扩展性。这也意味着Linkerd缺少对断路，延迟注入和速率限制的支持。没有公开任何特定的API来轻松控制Linkerd控制平面。（不过，您可以找到gRPC API绑定。）

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

Consul

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

确切地说，它具有混合性：

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

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

连接性

没有什么可以使Consul Connect在这一领域脱颖而出。它提供的任何服务网做什么（这是相当多的），加上层七个特征为基于路径的路由、故障切换和负载均衡。

安全

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

可观察性

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

安装

使用Helm图表将Consul Connect安装到Kubernetes集群中：helm repo add hashicorp https://helm.releases.hashicorp.com

values.yaml如果要启用UI或使Consul Connect模块注入其sidecar代理，则需要修改默认值：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 Connect由HashiCorp支持；作为免费增值产品，还有一个具有附加功能的企业版，可提供企业级支持。就开发团队的经验而言，Consul是市场上最古老的工具之一。
Consul Connect拥有坚实的企业社区，并且众所周知，它可以在具有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问题之一而声名狼藉。截至撰写本文时，bug的未结数量约为800个，已结bug的数量约为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资源将很难管理，你将需要管理CRDs-的几种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倍，它是Web上最受关注的服务网格。
它在GitHub贡献者同样超出了Linkerd。Istio支持Kubernetes和VM模式。后者是1.9版的beta版。

缺点：

Istio并非免费，有两种含义：

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

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

Kuma快速评论

由Kong创建并开放源代码，Kuma在2020年末达到1.0。在某种程度上，它是响应于第一个服务网格相当沉重且难以操作而创建的。

它的功能列表表明它是非常模块化的。Kuma背后的想法是将其定位为与已经在Kubernetes或其他基础架构上运行的应用程序集成。

在流量管理领域，Kuma提供了常见的服务网格功能，例如故障注入和断路。
除了服务间mTLS加密之外，还可以通过数据平面代理令牌在Kuma中保护数据平面和控制平面之间的交换。
在Kuma中，通过围绕度量标准，跟踪和日志记录的不同流量策略定义了可观察性。
由于Kuma在控制平面的端口5653上运行了自己的DNS解析器，因此可以通过Kuma进行服务发现。
Kuma十分强调多网格功能：您可以轻松地将多个Kubernetes群集或VM环境结合到具有其多区域部署类型的常见Kuma群集中。
对于现有的Kong用户，Kuma可以轻松地与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。（虽然从1.12开始，Azure默认使用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托管，因此它是一项完全托管的服务，这意味着不必担心资源使用或控制平面可用性。
可以通过Prometheus或AWS X-Ray实现AWS App Mesh中的可观察性。

该项目不是开源的，不支持SMI，并且在线上没有太多有关控制平面的HA标准的信息。AWS App Mesh的设置比其他Kubernetes本地服务网格更复杂，并且在线社区很少（Stack Overflow上有24个答案，GitHub上有400个星），但这是因为用户必须从AWS支持中受益。

AWS App Mesh与AWS进行了本机集成，从EKS开始，并扩展到其他AWS服务，例如ECS（Fargate）和EC2。与Traefik Mesh不同，它具有多集群支持。另外，像大多数服务网格一样，它是基于Envoy注入的，该Envoy是经过大量测试的Sidecar代理。

Kubernetes服务网格比较表

这里介绍的六个Kubernetes服务网格选项有一些共同点：

协议支持：它们都可与HTTP，HTTP / 2，gRPC，TCP和WebSockets一起使用。
默认情况下，它们在代理之间均具有mTLS形式的基本安全性。
通过设计，服务网格可提供某种形式的负载平衡。
至少这六个工具在其流量管理功能中还至少包括一个请求重试选项。
最后，服务发现是任何服务网格的核心功能。

但是，在服务网格基础结构，流量管理，可观察性，部署和其他方面，肯定有一些值得强调的差异。

基础设施

流量管理

可观察性

OpenCensus和OpenTracing在2019年合并为OpenTelemetry，但您可能会发现Linkerd文章涉及OpenCensus，以及Istio和Traefik Mesh文章涉及OpenTracing。

部署方式

注意事项

我们应该使用Kubernetes服务网格吗？

现在，我们已经了解了什么是服务网格，它们如何工作以及它们之间的众多差异，我们可以问：我们是否需要服务网格？

这是过去几年中SRE和云工程师面临的一个大问题。实际上，微服务给服务网格可以解决的网络通信带来了运营挑战。但是，在安装和操作方面，服务网格在大多数情况下会带来自身的挑战。

我们可以看到，在许多项目中出现的一个问题是，服务网格在概念验证阶段和生产阶段之间存在差距。也就是说，对于公司而言，实现在各个方面都与生产相同的过渡环境是非常罕见的。由于服务网格涉及关键基础架构，因此与规模和边缘相关的影响可能会带来部署方面的意外。

服务网格仍在大力发展和改进。对于部署频率较高的团队来说，这实际上可能是有吸引力的，这些团队已经掌握了保持最新版本并可以密切关注云原生工具的开发周期。

但是，对于其他人而言，服务网格演进的速度可能更是一个陷阱。设置服务网格将很容易，但如果随后没有及时维护它。安全补丁可能无法应用，或者即使被记住，也可能以不推荐使用的功能或经过修改的依赖项集的形式带来计划外的问题。

就在生产中建立服务网格的人力而言，这也是一笔可观的成本。任何团队评估此信息并了解服务网格的好处是否会超过初始设置时间，将是一个明智的目标。无论“简易”演示安装显示了什么，服务网格都是很难的。

简而言之，服务网格可以解决大规模部署项目中常见的一些问题，但可能会引入其他问题，因此要准备投入时间和精力。在一个假设的基础结构中，该基础结构涉及25个微服务，并且每秒要处理5个查询，我建议至少有一个人（最好是两个人）专门工作至少一个月，以准备概念证明并验证关键方面，然后再考虑在生产环境中运行它。设置完成后，请预测是否需要频繁升级-它们将影响基础架构的核心组件，即网络通信。

Kubernetes服务网格：可扩展应用程序架构中的（复杂）演进

我们已经了解了什么是服务网格：一套工具，可以应对微服务架构引入的新挑战。通过流量管理，可观察性，服务发现和增强的安全性，服务网格可以揭示对应用程序基础架构的深入了解。

市场上有多个参与者，有时是由GAFAM等组织提倡的，在某些情况下，它们是开源的或促进了他们自己的内部工具。尽管有两种不同的实现类型，但是服务网格将始终具有由代理构成的控制平面（系统的大脑）和数据平面，这些代理将拦截您的应用程序的请求。

回顾三个最大的服务网格（Linkerd，Consul Connect和Istio），我们看到了他们选择实施的不同策略以及它们带来的优势。Linkerd是市场上最古老的服务网格，得益于其在Twitter上的创建者经验。就HashiCorp而言，它提供企业级的Consul Connect，并具有高水平的专业知识和支持。Istio最初在网络上引起了足够的关注，但现在已经发展成为一个成熟的项目，最终提供了功能完善的平台。

但是，这些角色远非仅有这些角色，而是出现了一些鲜为人知的服务网格：Kuma，Traefik Mesh和AWS App Mesh等。来自Kong的Kuma的创建是为了使服务网格的想法“简单”并且可插入任何系统中，而不仅仅是Kubernetes。Traefik Mesh得益于已有的Traefik Proxy的经验，并做出了避免使用边车代理的罕见决定。最后但并非最不重要的一点是，AWS决定开发自己的版本的服务网格，但是它依赖可靠的Envoy Sidecar代理。

实际上，服务网格仍然很难实现。尽管服务网格的好处引人注目，但它们的影响却在两个方面都截然不同：服务网格的失败可能使您的微服务无法相互通信，从而可能破坏整个堆栈。一个臭名昭著的例子是：Linkerd版本和Kubernetes版本之间的不兼容性在在线银行Monzo造成了全面的生产中断。

尽管如此，整个行业都在围绕Kubernetes和诸如Microsoft带头的SMI之类的计划进行结构调整，SMI是Kubernetes上服务网格的标准接口。在众多其他项目中，Cloud Native Computing Foundation（CNCF）拥有基于Envoy的开放服务网格（OSM）计划，该计划最初也是由Microsoft引入的。服务网格生态系统仍然很热闹，我预测在未来几年会出现一个冠军，就像Kubernetes成为事实上的容器编排工具一样。