服务网格（Service mesh）已经不是一个新鲜概念，但它实现了连接运行在 Kubernetes 作为容器化平台之上的微服务，这使得服务网格的想法更加流行。如果没有服务网格，每个微服务都需要配置以接收（或发送）连接到其他需要与之通信的微服务，但服务网格完全改变了这一状况。
与此前需要手动配置以及投入大量的时间精力来维护微服务之间的连接所不同的是，开发人员现在可以创建一个网格，使得微服务彼此通信可靠、可控以及安全。Kubernetes 和服务网格是相互作用的，主要是因为使用服务网格可以在不增加工作量的情况下，实现更复杂的容器化架构。
因此，有很多方式可以在 Kubernetes 顶层建立一个服务网格。在本文中，我们将比较一些你可以用于建立服务网格的工具，你可以分别了解到它们的优劣势进而选出最适合自己的服务网格工具。
与 AWS 环境完美适配：AWS App Mesh
官网：https://aws.amazon.com/app-mesh/
由于现在许多基于 Kubernetes 的应用程序和微服务都运行在 Amazon Web Services 环境中，所以很难不谈到 AWS App Mesh。顾名思义，AWS App Mesh 是亚马逊自己的服务网格，用于为 Amazon services 创建服务网格层。
作为亚马逊的产品，AWS App Mesh 利用结合了 Envoy 的专有技术作为其服务代理。AWS App Mesh 通过创建虚拟服务在相同的命名空间中连接服务。在你的 AWS 环境中每个微服务都可以找到虚拟服务并使用它来与其他微服务通信。
AWS App Mesh 与其他服务（例如 EKS、Fargate 和 EC2）的无缝集成是其最强的优势，但在使用 App Mesh 的过程中存在一些限制。首先，你不能将 App Mesh 迁移到外部或者在多云设置中使用这一服务。
App Mesh 还借助 CloudWatch 和 AWS X-Ray 来管理服务网格，这意味着你可以在不离开主仪表板的情况下完全控制该层。诸如支持 mTLS 和高级负载均衡的特性在 App Mesh 中也有，但是它不支持身份验证规则。
最流行的服务网格工具：Istio
官网：https://istio.io/latest/zh/
Istio 可能是最流行的 Kubernetes 服务网格工具，它最初由 Lyft 开发，但后来变成 Lyft、Google 和 IBM 联合开发。考虑到 Kubernetes 背后的公司是谷歌，那么 Istio 被广泛用于许多部署类型也并不奇怪了。
与 App Mesh 类似，Istio 也将 Envoy 用作其服务代理，但它并没有限制你把 Envoy 作为唯一的 ingress controller。Istio 的独特之处在于它提供了巨大的灵活性。你可以将 Istio 用于其他的容器化平台，但其与 Kubernetes 的无缝衔接使其发挥的作用更大。
例如，Istio 支持 mesh 扩展和多云网格，这两个特性在 App Mesh 和其他服务网格工具里都是没有的。Istio 还可以处理流量访问控制以及负载均衡，就像它是为了执行这些任务而构建的一样。它甚至支持故障注入和延迟注入。
使用 Istio 的唯一缺点是你可能会对它提供的功能感到不知所措。如果你有足够的资源使用 Istio 处理服务网格层，这个工具有可能通过其功能简化最复杂的微服务架构。
独立的服务网格工具：Linkerd
官网：https://linkerd.io/
当 Linkerd 发布 2.x 版本时，它已经是一个十分流行的服务网格工具了。新版本受到了 Kubernetes 社区的欢迎，截止到 2020 年 4 月中旬，其 2.7.1 稳定版已经出炉。它完全是作为一个独立的服务网格工具来构建的，所以它并不依赖 Envoy 等第三方工具来管理，它甚至还包含了 linkerd-proxy 作为服务代理。
最近的升级还包括 dashboard 的改进和针对金丝雀部署的流量拆分功能的可视化。这使其成为实时监控和编排金丝雀和蓝绿部署的绝佳工具。
在保持独立的同时，Linkerd 还与 Ingress controller 保持高度兼容性。实际上，Linkerd 能够与你使用的任意 Ingress controller 一起工作，使它在这方面最为灵活。一个简单的 linkerd inject 命令就可以让服务网格与你的应用程序集成。
Linkerd2 也是高度优化的，安装仅需 60 秒。如果你正在寻找可以带来最佳性能的服务网格工具，那么 Linkerd 是你可以考虑尝试的。作为一个非侵入式的服务网格工具，Linkerd 在部署之后并不需要进行大量的优化。开箱即用的配置足以支持复杂的微服务架构，并且能够防止重大工具。Linkerd 通过 mutual TLS(mTLS) 加密来增强应用程序的安全性。
Linkerd 也是一个专门为 Kubernetes 开发的工具。它可能不支持多云和多集群网格创建，但这丝毫不会减弱其作为 Kubernetes 实例的服务网格层的能力。除此之外，它也可以与 OpenCensus 配合使用，从而使跟踪和管理变得非常容易。
最年轻的服务网格工具：Kuma
官网：https://kuma.io/
Kuma 将 Envoy 作为服务代理并且支持任意 ingress controller。这与 Consul Connect 十分类似（该工具我们稍后会介绍），但 Kuma 也有自己令人耳目一新的功能。而且这些新意可能是因为 Kuma 是这个列表中最新的工具。
不要被 Kuma 年轻的年龄所欺骗了，它不仅仅已经生产就绪，而且还具备了你所期望的服务网格工具的功能。它支持所有与 OpenTracing 兼容的所有后端并且允许你在需要时使用外部 CA 证书。不过，这一工具也存在不完善的地方——有一些功能是缺失的。
目前，在 Kuma 中没有办法进行基于路径或基于请求头的流量分割。它也不支持诸如流量访问控制和指标等功能。这些功能也许会在后续版本中引入，但现在你必须得手动制作代理模板来弥补这些功能的缺失。
但是，Kuma 作为一个服务网格工具还是很有前途的，尽管目前它只是 0.4.0 版本，但其开发者十分关注社区的意见并且十分乐意满足用户的要求，从这个维度上看，这个工具无疑是极具竞争力的。
最适用于 Consul 环境的服务网格：Consul Connect
官网：https://www.consul.io/
由 HashiCorp 推出的 Consul Connect 可以与 Envoy 及其他各种服务代理一起工作，它还可以与任何 ingress controller 一起工作，这使其成为最容易集成到现有 Kubernetes 集群中的工具之一。
在任意 Consul 环境中 Consul Connect 都可以无缝衔接，但是它也只能在 Consul 环境中工作。虽然该服务网格工具提供了许多方便的功能，但它是为了能与其他 HashiCorp 产品使用而设计的。不过，这些工具的应用十分广泛。
从 TCP 到 gRPC 的一切都支持，此外这一工具还能与 Kubernetes、VM 甚至 Nomads 一起工具。网格扩展也是完全支持的，所以你可以拥有一个跨多个云服务和集群的环境，并且仍然具有一个支持微服务的功能强大的服务网格层。
Consul Connect 需要改进的一个方面是监控。然而，你也可以整合其他监控工具，以便获得日志和每个路由的指标。你甚至可以集成诸如 Prometheus 和 Grafana 等工具来可视化你的监控数据。然后你只需要从你的服务代理中提取数据即可。
Envoy Proxy
这些服务网状工具基本设计为 Envoy 作为服务代理。与其他边缘代理工具相比，Envoy 确实具有一些优势，其中高级负载均衡是最突出的优势。
自动重试、区域本地负载均衡、request shadowing 等功能可以让你配置流量负载均衡以获得最大性能。另一方面，高可观察性使得 Envoy 成为维护支持能力强大架构的网络的完美解决方案。
当然，这些工具有一个主要目标：创建一个云架构，在这个架构中，微服务可以以可靠和安全的方式彼此通信。好消息是，无论你使用哪种工具，你都能实现这个目标。
本文来自 Rancher Labs