服务网格大比拼：Istio、Linkerd、Linkerd2和Consul

本文比较适合Kubernetes的每个服务网格，并确定获胜者。

Linkerd

我在DC / OS上广泛使用了Linkerd并且非常喜欢它。然而，时代已经发生变化，并且有一些基本问题导致这对Kubernetes来说完全是死路一条。

Linkerd是用JVM语言编写的，这意味着每个节点代理程序的占用空间为110mb +内存。当你每个主机只运行一个节点代理时，这不是太糟糕，但是世界正在转向每个pod代理边车，我想每个人都意识到这属于太多的开销。

Linkerd也不代理TCP请求，也不支持websockets。

应付大规模访问时，Linkerd拥有绝对惊人的流量控制它也是支持连接集群外部的两个服务网格之一。

Linkerd2

Linkerd2使用Golang和Rust完全重写了Linkerd，专门用于Kubernetes。不幸的是，与每次重写一样，你从功能和稳定性的角度看需要再次从头开始，会继续领教到一些经验教训。

迁移到Rust的数据平板代理侧面应该有助于缓解一些错误，还解决内存问题。它现在还支持所有主要协议，这是向前迈出的一大步。

与其他服务网格设计相比，一个有趣的区别是数据平版和控制平版服务之间的紧密默认耦合。

从功能角度来看还无法和Istio竞争。比如服务网格基本上需要的组件：分布式跟踪。 这仍处于Linkerd2的规划阶段。

我很难猜测Linkerd2需要多长时间才能从稳定性和功能成熟度角度赶上Istio。这可能需要数年时间。

话虽如此，如果你尝试使用Linkerd2并对功能集感到满意，那么这对未来来说似乎是一项很好的投资。许多人讨厌Istio的高度复杂性，所以我认为随着时间的推移，如果它仍然很简单，这可能会成为最引人注目的选择。

Consul

Consul的最新版本现在提供了“ connect ”功能，可以在现有群集上启用。与大多数Hashicorp工具一样，Consul是一个包含数据和控制平版的 Go 二进制文件。主要的独特卖点似乎是你可以在Kubernetes上启用跨服务的连接，并将它们加入到运行Consul的外部vm服务上。这可能对一些组织有吸引力。但是，根据我过去所做的工作，我并不认为这是一个很大的优势。通常我们让遗留系统自然死亡，然后处理新项目或将内容迁移到Kubernetes。

Consul确实具有轻微的架构优势，因为它作为一个完整的网状网络运行，没有集中控制平版服务，理论上这是一种性能瓶颈。

layer4和layer7之间也有一个整齐的分离。我认为这种分离可能使Consul服务网格设计变得简单，同时仍允许分割数据层。如果你需要更多第7层功能，你现在可以使用Envoy切换默认数据层代理。

但是，默认代理功能非常缺乏。要获得跟踪支持，或者许多更高级的第7层功能，你需要将代理换成像Envoy这样的东西。这在网上没有很好的记录。

另一个值得关注的部分是控制平版配置。在这一层配置Istio是非常复杂的，我看到Consul有一个简单的“服务访问图”功能。

Hashicorp在博客上发表了关于区分安全领域的文章。Consul ACL提供主机安全性是一个非常好的功能。特别是如果你想以安全的方式从集群外部的Kubernetes内部连接pod。代理缓存，特别是对于auth，显然使通信性能优异。

就像Linkerd2一样，这是值得关注的。Consul connect仅在几周前发布，因此网上的指南并不多。如果你已经对Hashicorp工具链进行了高度投资，那么我将对此进行试用，并了解如何使用Envoy替换默认代理。

Istio

Istio稳定且功能丰富。在撰写本文时，Istio拥有11.5k Github明星，244位贡献者，并得到Lyft，Google和IBM的支持。Istio开创了许多其他服务网格模拟的想法。

其中一个突出的特点是自动侧车注入，它与Helm图表的效果非常好。

当然有些负面因素与模块化、插件能力和最终的复杂性有关。你可以切换Istio组件并将其与其他系统集成。这一切都是以陡峭的学习曲线为代价的，并且有足够的空间来踏坑。

但是，令人惊讶的是，如果你坚持使用默认值，你可以非常快速地启动并运行Istio。在笔记本电脑上使用minikube，helm和Istio配置测试实例的工作时间不到5分钟。在线还有数千篇关于如何配置其他集成的文章。这与其他服务网格形成鲜明对比。

获胜者：Istio

Istio可能是目前最好的服务网格，但复杂性很高，与Kubernetes本身复杂性相比，却并不是很高。它拥有最多的功能，并在几个月前推出了第1版和生产版。它还得到了谷歌和大型社区的支持，推出了很酷的博客和集成。