docker - 如何将 Istio 与 Docker Swarm 进行比较？

Question

阅读有关 Istio 的文档时，我提出了这个问题。

Istio 和 Docker Swarm 在哪些方面工作相同？

另外，在不同的场景下哪一个更好？

Answer 1

确实，对 Istio 和 Docker Swarm 的描述都提到了“服务网格”这个术语。

然而，Docker Swarm 中的服务网格与 Kubernetes 中的服务模型相比更具可比性，并且这两个编排器在它们各自拥有的大多数功能上都具有可比性。在这两个编排器中，服务路由只涉及网络层，并且不具备对 HTTP 协议等的可见性。

请注意，Kubernetes Ingress API 应该单独考虑，它实际上位于服务模型之上，实际上是由外部控制器实现的，例如 Traefik 或 HAProxy，实际上 Istio 带来了另一个入口控制器的实现。

虽然 Istio 比编排器（大约）高出一级，但目前它仅在 Kubernetes 上运行，但它很可能在未来支持 Docker Swarm 以及其他流行的编排器。

更具体地说，Istio 的服务网格比 Docker Swarm 提供的（以及类似地，Kubernetes 服务提供的）要先进得多，例如它支持故障注入和透明 TLS 以及许多其他功能。

Answer 2

Docker Engine swarm mode 可以很容易地为服务发布端口，以使它们可用于 swarm 之外的资源。所有节点都参与一个入口路由网格。路由网格使 swarm 中的每个节点都可以在已发布的端口上接受在 swarm 中运行的任何服务的连接，即使该节点上没有运行任何任务。路由网格将所有传入请求路由到可用节点上的已发布端口到活动容器。

Istio 是一个用于连接、管理和保护服务的开放平台。从本质上讲，它是一个开放的服务网格，我们希望开发人员和运营商不要为如何连接服务、如何考虑使它们具有弹性、如何保护它们以及如何管理运行时感到头疼。我们希望 Istio 能够为所有环境和云中的开发人员和运营商做到这一点。而且，当我说服务时，它实际上是各种服务，不一定只是微服务。它可以是任何东西，例如您正在构建 MySQL API 服务，这是您应用程序中用于支付或购物的非常小的微服务，可以使用任何给定的语言。因此，istio 采用了一种使用多语言环境的方法。您知道，无论您使用哪种语言编写服务以及部署在何处，Istio 想在您的应用程序和网络之间为您提供一个统一的底层，它可以处理服务之间的连接性和服务之间的弹性。所以弹性包括重试、故障转移、所有好东西和分布式系统保护服务。我们认为内部服务应该和外部一样安全，所以默认情况下是安全的。并且，在您的所有服务中，从 L3 到 L7 的所有指标都具有完整的可观察性和可见性。

本质上考虑层（有些人称之为 L5），它基本上是您的应用程序和网络之间的一层。而且，当您考虑它时，您基本上是在创建，我们在每个服务旁边注入代理。而且，它们位于所有服务到服务通信的数据路径中。它们都是相互连接的，并且还连接到一个公共控制平面。而且，与每个服务相邻的一组相互连接的代理通常被称为服务网格。它如此有趣的原因是，一旦您将网格视为像网络一样存在的层，您就可以在应用层将连接性、弹性、可见性等内容卸载到该层。因此，从历史上看，您可以在任一应用程序库中执行此操作，就像您在 java、python 中构建一样，或者去那里’ 每种语言都有一堆库，您可以导入这些库并将逻辑写入其中。或者，您可以执行 L3 层安全和策略，例如 IP 白名单、防火墙规则设置、VPN 网络、VPN 对等互连等。因此，我们认为服务网格是两者之间的一个空间，它可以从 L7 卸载一些东西，并提供策略驱动的合同来运营您的网络。因此，Istio 服务网格比 Docker Swarm 服务网格要好得多。

Answer 3

在许多方面，这是一个苹果与橘子的比较。Istio（目前）运行在 Kubernetes 之上， Kubernetes 是一种容器编排器，如 Docker Swarm。