阅读有关Istio的文档我带来了这些问题。
Istio和Docker Swarm的工作原理是什么？
另外，在不同场景中哪一个更好？
答案 0 :(得分：5)
确实，Istio和Docker Swarm的描述都引用了术语“服务网格”。
然而，Docker Swarm中的服务网格与Kubernetes中的服务模型更具可比性，并且两个协调器通常与它们各自具有的大多数功能相当。在两个协调器的服务路由中，仅接触网络层，并且不具有对例如网络层的可见性。 HTTP协议。
请注意，Kubernetes Ingress API应该单独考虑，它实际上位于服务模型之上，并且实际上是由外部控制器实现的，例如， Traefik或HAProxy，实际上Istio带来了入口控制器的另一种实现。
虽然Istio比协调器高出约（等级）一级，但现在它仅在Kubernetes上运行，但它很可能在未来支持Docker Swarm以及其他流行的协调者。
更具体地说，Istio的服务网格比Docker Swarm提供的更先进（并且，通过类比，Kubernetes Services提供的服务），例如，它可以实现故障注入和透明TLS，以及许多其他功能。
答案 1 :(得分：2)
Docker Engine群集模式可以轻松发布服务端口，使其可供群组外的资源使用。所有节点都参与入口路由网格。路由网格使群集中的每个节点都能够接受已发布端口上的连接，以便在群集中运行任何服务，即使节点上没有任何任务正在运行。路由网格将所有传入请求路由到可用节点上的已发布端口到活动容器。
Istio是一个连接，管理和保护服务的开放平台。从本质上讲，它是一个开放的服务网格，我们希望开发人员和运营商不要担心如何连接服务，如何考虑使其具有弹性，如何保护它们以及如何管理运行时。我们希望Istio能够为所有环境和云中的开发人员和运营商做到这一点。而且，当我说services时，其真正的各种服务不一定只是微观。它可能就像您正在构建MySQL API服务，在您的应用程序中以任何给定语言进行支付或购物的非常小的微服务。因此，istio采用了一种处理polygot环境的方法。您知道，无论您在哪种语言中编写服务以及在何处部署，Istio都希望在您的应用程序和网络之间为您提供统一的基础，这可以处理服务之间的连接，服务之间的弹性。因此，弹性包括诸如重试，故障转移，所有好东西和分布式系统保护服务之类的东西。我们认为，内部服务应该像外部一样安全，所以默认情况下是安全的。并且，在所有服务中，从L3到L7的指标都具有完全可观察性和可见性。
基本上考虑层（有些人称之为L5），它基本上是应用程序和网络之间的一层。而且，当你考虑它时，你基本上是在创建，我们正在为每个服务注入一个代理。而且，这些都在所有服务到服务通信的数据路径中。它们都是互连的，并且还连接到公共控制平面。并且，生活在每个服务旁边的相互连接的代理集通常被称为Service Mesh它之所以如此有趣的原因是，一旦您将网格视为像网络一样存在的层，您就可以，在应用层卸载诸如连接，弹性，对该层的可见性之类的事情。因此，从历史上看，您可以在任一应用程序库中执行此操作，就好像您使用java，python构建一样，或者在每种语言中使用这些库，您可以导入并将逻辑写入其中。或者你可以做L3层安全和策略，如IP白名单，防火墙规则设置，VPN网络，VPN对等等。因此，我们认为服务网格是两者之间的空间，可以从L7卸载一些东西，并提供策略驱动的合同来操作您的网络。因此，Istio服务网格比Docker Swarm服务网格要好得多。
答案 2 :(得分：1)
在很多方面都是苹果与橘子的比较。 Istio（当前）在 Kubernetes之上运行，这是一个像Docker Swarm这样的容器协调器。