Istio 是 Kubernetes 集群中的“必须”吗？答案

【问题标题】：Is Istio a “must” in a Kubernetes cluster [closed]Istio 是 Kubernetes 集群中的“必须”吗？
【发布时间】：2020-01-04 22:13:25
【问题描述】：

我们正在尝试重新构建我们的微服务并将它们移动到 Docker 容器中。我们将使用 Kubernetes 来编排容器。我们已经对如何将不同的技术与 Kubernetes 以及其他 Istio 结合使用进行了一些调查，以使一切都变得最好:-)。

然而，我们在互联网上阅读的越多，我们就越感到困惑。我们知道 Kubernetes 有入口和“入口控制器”，据我们了解，Istio 在服务间通信方面可能更好，它解决了服务发现和断路器等挑战。但我们不知道仅使用 Kubernetes ingress 是否可以解决所有这些问题？

为什么以及何时应该（不应该）将 Istio 与 Kubernetes 结合使用？
为什么以及何时应该使用入口控制器？

谢谢

【问题讨论】：

你可以用“普通”的 Kubernetes 做你想做的事。您可以研究 Kubernetes“服务”对象以进行发现（不是入口）。 ISTIO 在 Kubernetes 之上添加了额外的路由功能和安全性。
这对于 stackoverflow 来说可能是一个过于宽泛的问题，但通常就像您已经提到的那样，如果您的集群中有大量的服务间通信和路由，那么 istio 可能比普通的更适合Kubernetes。如果您拥有最初意义上的自治微服务，它们只是在某个应用程序网关（入口控制器）后面提供服务，那么 istio 只会增加不必要的开销和复杂性。简单的服务间通信总是可以通过rabbitmq、kafka等消息队列来实现的。
谢谢；我们有两种类型的服务间通信直接和间接。我们正在考虑使用 Kafka 进行间接通信（涵盖最终一致性）。然而，对于服务之间的直接通信，我们在选择正确的技术方面存在一些困难。
@user217648 “Istio”不是必须的，但在我看来，服务网格是一种可行的方法，而且在生产方面肯定需要实施。因此，我个人最喜欢的是linkerd，因为它比 istio 更快、更易于配置并且可以满足您的一切需求。大多数项目不需要交通管理左右。看看吧！

标签： kubernetes microservices kubernetes-ingress istio

【解决方案1】：

回答问题：

如果你需要advanced network features，比如高级路由、熔断、加权部署、加密等，那么最好选择Istio。对于“更简单”的需求，你只想容器编排，你可以只坚持使用 Kubernetes。
入口控制器确定Ingress object 的行为，而Ingress object 又用于公开在集群中运行的应用程序。这意味着，每个入口控制器都有一组不同的选项/功能，通常与第 7 层操作相关。 Whenver you're exposing your applications via Ingress, you're using an ingress controller。

现在，这意味着入口控制器可以执行服务发现或断路之类的操作。不是这种情况。这些功能由Service Mesh 解决（Istio 是一种在集群内创建的产品），Ingress 对象的目标是公开并经常在集群内执行一些路由服务。

您可以将 Ingress 视为网关，允许集群中的传入连接、基于路径的路由和 SSL 终止。所以它基本上作为一个接入点运行，而 Istio 将在内部网络内运行，管理服务之间的连接而不暴露它们（尽管它可以通过 ingressgateway），并添加一组高级路由功能在内部网络中。

【讨论】：

谢谢 Yahir，是否可以在同一个 Kubernetes 集群中为不同的项目设置不同的设置？因为也许在一个项目中我们有经常互相调用的服务，但在另一个项目中，服务不需要直接而是间接地相互调用，那么我们可以使用消息代理或服务总线。或者在一个项目中我们不需要使用服务网格或消息代理，因为服务是自治的，所以在这种情况下，只有 Kubernetes 入口就足够了吗？我说的对吗？
是的。专门针对 Istio 并且由于它的设计方式，您可以将 Service Mesh 限制为特定的命名空间（通过 sidecar injection）；这样，可以在“香草”Kubernetes 版本旁边拥有一个基于 Istio 的集群。
使用 Sidecar 注入意味着我们不会将 Istio 用作入口，而是用作 Sidecar？还有更多我们可以阅读的资源吗？
Istio 是一组包含 sidecar 的功能和对象（请参阅答案中的“服务网格”链接），并且还可以包含他们自己的名为 ingressgateway 的类似入口的对象的实现，不同于入口对象（答案中的参考）。您必须使用 sidecar 来创建服务网格，此外，您可以部署基于 Istio 的入口来公开它。这些 Istio 对象可以通过命名空间注入与同一集群中的传统 k8s 对象共存。
1. Ingressgateway 用于公开在网格中运行的服务，因此如果您的功能定义也公开公开，那么可以。 2. Ingressgw 仅适用于服务网格，没有 Istio 网格的命名空间需要自己的入口 3. 不确定 Azure，但对于 Apigee，您需要以某种方式暴露您的集群以进行摄取。请注意，这可能会因使用的Apigee pattern 而有所不同

【解决方案2】：

在我看来，我的简短回答是否定的，Istio 不是 Kubernetes 集群中的“必须”。

在我参与的一个迁移项目中，已经有了集中治理/控制和可观察性。所以这个需求不包括 Istio。

但是，尽管如此，我们还是有一个概念验证来评估 Istio 的哪些功能比我们的设置更好/更差。 Local setup Docker Desktop 和 local K8s cluster 一切皆有可能。

如果您评估您拥有的微服务设置不具备 Istio 必须提供的良好互连性、治理性和可观察性，我建议您尝试使用您的几个应用程序，即使只是在本地也可以。您将看到实际的优缺点。

【讨论】：