Kubernetes 服务网格工具对比

本文对服务网格工具AWS App Mesh，Istio，Linkerd，Kuma，Consul Connect和Envoy Proxy的优缺点进行对比。

服务网格并不是一个新概念，它使得以容器化的方式运行在kubernetes之上的微服务平台更为流行。如果没有服务网格，则需要将每个微服务和需要与之通信的其他微服务的连接做配置（接受/发送）。服务网格完全改变了这一点。

开发人员现在可以创建一个网格，使微服务能够以可靠，安全和可控制的方式相互通信，而不必进行手动配置，也不必花费大量时间和精力来维护微服务之间的连接。 Kubernetes和服务网格是相辅相成的，主要是因为使用服务网格可以实现更复杂的容器化架构，而不会增加工作负载。

有很多方法可以将服务网格建立为Kubernetes之上的一层。在本文中，我们将比较可用于建立服务网格的一些工具，看看哪种 工具 最好。

AWS App Mesh

由于许多基于Kubernetes的应用程序和微服务现在都在Amazon Web Services环境中运行，因此很难不谈AWS App Mesh。顾名思义，AWS App Mesh是Amazon自家的服务网格，旨在为Amazon服务创建服务网格层。

作为Amazon产品，AWS App Mesh将专有技术和envoy整合作为其服务代理。 AWS App Mesh通过创建的虚拟服务在连接同一名称空间内的服务。 AWS环境中的每个微服务都可以找到该虚拟服务，并利用该服务将通信连接到至其他微服务。

AWS App Mesh与其他服务（例如EKS，Fargate和EC2）的无缝集成是其最强的优势，但是在使用App Mesh也存在一些限制。对于初学者，您不能迁移到App Mesh外部或在多云设置中使用此服务。

App Mesh还借助CloudWatch和AWS X-Ray来管理服务网格，但这意味着您无需离开仪表板就可以完全控制该层。尽管App Mesh不支持授权规则，但他支持诸如mTLS和高级负载平衡之类的安全功能。

Istio

Istio也许是Kubernetes最受欢迎的服务网格工具。它最初是为Lyft开发的，但后来成为Google和IBM合作开发的项目。考虑到Google为Kubernetes背书，那么Istio在各种部署类型中得到广泛使用就不足为奇了。

与App Mesh相似，Istio同样使用Envoy作为其服务代理，但入口控制器并不仅限于Envoy。 Istio的独特之处在于它提供了巨大的灵活性，而没有通常的复杂性。您实际上可以将Istio用于其他容器化平台，但是它与Kubernetes的无缝集成使其成为有用的工具。

例如，Istio支持网格扩展和多群集，这两个功能都是App Mesh和许多其他服务网格工具所没有的。 Istio也可以进行流量控制和负载平衡，专业的就好像它是专门为这些任务而创造的一样。它甚至支持故障注入和延迟注入。

使用Istio的唯一缺点是您可能会对它提供的功能感到不知所措（被吓到）。如果您有机会使用Istio作为服务网格，它可以帮助你简化最复杂的微服务架构。

Linkerd

当v2.x版本发布时，Linkerd已经是一种非常流行的服务网格工具。 新版本在Kubernetes社区非常受欢迎，2020年4月中旬，其稳定的2.7.1版本已经发布。它完全是作为独立的服务网格工具构建的，因此它不依赖Envoy等第三方工具进行管理。它甚至有自己的服务代理linkerd-proxy。

最近的升级还包括仪表板改进和针对金丝雀部署的流量拆分功能的可视化。这使其成为实时监视和编排金丝雀和蓝/绿部署的绝佳工具。

Linkerd在保持独立性的同时与入口控制器保持高度兼容性。实际上，Linkerd能够与您使用的任何入口控制器一起使用，这一点Linkerd极具灵活性。要使服务网格与您的应用程序集成在一起，只需要一个简单的linkerd inject命令即可。

Linkerd2同样进行了高度优化，安装它仅需60秒。如果您正在寻找一种可以使架构发挥最佳性能的服务网格工具，那么可以尝试一下。 Linkerd作为一种非侵入性的服务网格工具，部署后无需进行很多优化。开箱即用的配置足以支持复杂的微服务架构，并且预防多数的攻击行为。 Linkerd通过mTLS加密来增强应用程序安全性。

它也可以被认为是专门为Kubernetes开发的工具。它可能不支持多云和多集群网格的创建，但是当它作为服务网格层服务Kubernetes实例时，它的功能也丝毫不逊色。此外，它还可以与OpenCensus配合使用，这使得跟踪和管理非常容易。

Kuma

作为服务代理Kuma与 Envoy的结合很独特，它支持任何入口控制器。它与Consul Connect非常相似（我们将在稍后介绍这些令人耳目一新的功能）。Kuma也是列表中的最新工具，因此它也非常新颖。

不要被kuma的“年轻”所欺骗。 Kuma不仅可以投入生产，而且还具有作为功能强大的服务网格工具所期望的功能。它支持与OpenTracing兼容的所有后端，并在需要时允许您使用外部CA证书。不幸的是，该工具仍缺少某些功能。

目前，在Kuma中无法进行基于路径或基于头信息的流量拆分。还不支持流量访问控制和指标等功能。这些功能可能会在以后的更新中引入，但是就目前而言，您必须手动进行代理模板处理才能解决这些工具的不足。

尽管如此，Kuma看起来很有希望成为服务网格工具。它尚未达到其1.0.0版本（当前为0.4.0），但是该工具背后的开发人员听取了社区的意见，并乐于满足使该工具比其竞争对手更强大的要求。

Consul Connect

HashiCorp的Consul Connect是我们列表中的下一个服务网格工具。它是HashiCorp的产品，如你所愿Consul Connect可以与Envoy和其他各种服务代理替代产品一起使用。它还可以与任何入口控制器一起使用，使其成为最容易集成到现有Kubernetes集群中的一种网格工具。

Consul Connect可在任何Consul环境中无缝运行。不幸的是，它只能在Consul环境中工作。该服务网格工具虽然提供了许多方便的功能，但旨在与其他HashiCorp产品一起使用。当然HashiCorp的产品线非常丰富。

它支持从TCP到gRPC的所有内容。该工具可与Kubernetes，VM和Nomads一起使用。完全支持网格扩展，因此您可以拥有跨多个云服务和群集的环境，并且仍然同时拥有具有支持微服务的功能强大的服务网格层。

Consul Connect需要改进的一方面是监控。但是，您可以集成其他监视工具以访问日志和按路由度量。您甚至可以集成Prometheus和Grafana之类的工具以可视化监视数据。您只需要从服务代理中提取数据即可，而不需要直接从Consul Connect中提取数据。

Envoy Proxy

这些服务网格工具都与Envoy相结合实现服务代理功能。与其他边缘代理工具相比，Envoy确实具有一些优势，高级负载平衡是所有这些工具中最突出的优势。

Automating retries, zone local load balancing, 和 request shadowing使您可以配置流量负载平衡以实现最佳性能。另一方面，高可视性使Envoy成为维护功能强大网络的理想解决方案。

当然，这些工具都有一个主要目标：创建一种云架构，在该架构中，微服务可以可靠，安全的方式相互通信。好消息是，无论使用哪种工具，您都将实现这一目标。

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

• hystrix对比服务网格istio的destinationrule
• [Grid 网格布局教程]显式网格和隐式网格之间的区别
• 精彩的无服务器时代:不仅有服务网格，还有事件网格
• 服务网格重蹈ESB的覆辙？为什么需要SMI服务网格接口？ - samnewman
• 什么是服务网格？
• [译] 初识 NGINX 服务网格

本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。