Istio 是 Kubernetes 集群中的“必须”吗
Is Istio a “must” in a Kubernetes cluster
我们正在尝试重新构建我们的微服务并将它们移动到 Docker 容器中。我们将使用 Kubernetes 来编排容器。我们已经对我们应该如何将不同的技术与 Kubernetes 以及 Istio 结合使用进行了一些调查，以获得最好的一切:-)。
然而，我们在网上看得越多，就越感到困惑。我们知道 Kubernetes 有入口和“入口控制器”，据我们了解，Istio 在服务间通信方面可能更好，它解决了服务发现和断路器挑战等问题。但我们不知道仅使用 Kubernetes ingress 是否可以解决所有这些问题？
- 为什么以及何时应该（不应该）将 Istio 与 Kubernetes 一起使用？
- 为什么以及何时应该使用入口控制器？
谢谢
解决问题：
如果你需要advanced network features，比如高级路由、熔断、加权部署、加密等，那么最好选择Istio。对于“更简单”的需求，如果你只想容器编排，你可以只坚持使用 Kubernetes。
Ingress 控制器决定 Ingress object, which in turn is used to expose the applications running within the cluster. This means that, each ingress controller has a different set of options/features, generally tied to layer 7 operations. Whenver you're exposing your applications via Ingress, you're using an ingress controller.
现在，这意味着入口控制器可以做服务发现或断路之类的事情。不是这种情况。这些功能由 Service Mesh（Istio 是一种在集群内创建一个产品）解决，Ingress 对象的目标是公开并经常在集群内路由服务。
您可以将 Ingress 视为网关，允许集群中的传入连接、基于路径的路由和 SSL 终止。所以它基本上是 运行 作为一个访问点，而 Istio 将 运行 在 内部网络中，管理服务之间的连接而不暴露它们（尽管它可以通过ingressgateway），并在内部网络中添加一组高级路由功能。
我认为我的简短回答是否定的，Istio 不是 Kubernetes 集群中的 "must"。
在我工作过的一个迁移项目中，已经有了中心化的governance/control和可观察性。所以要求不包括 Istio。
但是，尽管如此，我们还是进行了概念验证，以评估 Istio 与我们的设置相比具有哪些功能 better/worse。 Local setup of everything is possible with a Docker Desktop and a local K8s cluster.
如果您评估您拥有的微服务设置没有 Istio 必须提供的良好的互连性、治理和可观察性，我建议您尝试使用您的几个应用程序，即使只是本地。您将看到实际的优缺点。
我们正在尝试重新构建我们的微服务并将它们移动到 Docker 容器中。我们将使用 Kubernetes 来编排容器。我们已经对我们应该如何将不同的技术与 Kubernetes 以及 Istio 结合使用进行了一些调查，以获得最好的一切:-)。
然而，我们在网上看得越多，就越感到困惑。我们知道 Kubernetes 有入口和“入口控制器”，据我们了解，Istio 在服务间通信方面可能更好，它解决了服务发现和断路器挑战等问题。但我们不知道仅使用 Kubernetes ingress 是否可以解决所有这些问题？
- 为什么以及何时应该（不应该）将 Istio 与 Kubernetes 一起使用？
- 为什么以及何时应该使用入口控制器？
谢谢
解决问题：
如果你需要advanced network features，比如高级路由、熔断、加权部署、加密等，那么最好选择Istio。对于“更简单”的需求，如果你只想容器编排，你可以只坚持使用 Kubernetes。
Ingress 控制器决定 Ingress object, which in turn is used to expose the applications running within the cluster. This means that, each ingress controller has a different set of options/features, generally tied to layer 7 operations. Whenver you're exposing your applications via Ingress, you're using an ingress controller.
的行为
现在，这意味着入口控制器可以做服务发现或断路之类的事情。不是这种情况。这些功能由 Service Mesh（Istio 是一种在集群内创建一个产品）解决，Ingress 对象的目标是公开并经常在集群内路由服务。
您可以将 Ingress 视为网关，允许集群中的传入连接、基于路径的路由和 SSL 终止。所以它基本上是 运行 作为一个访问点，而 Istio 将 运行 在 内部网络中，管理服务之间的连接而不暴露它们（尽管它可以通过ingressgateway），并在内部网络中添加一组高级路由功能。
我认为我的简短回答是否定的，Istio 不是 Kubernetes 集群中的 "must"。
在我工作过的一个迁移项目中，已经有了中心化的governance/control和可观察性。所以要求不包括 Istio。
但是，尽管如此，我们还是进行了概念验证，以评估 Istio 与我们的设置相比具有哪些功能 better/worse。 Local setup of everything is possible with a Docker Desktop and a local K8s cluster.
如果您评估您拥有的微服务设置没有 Istio 必须提供的良好的互连性、治理和可观察性，我建议您尝试使用您的几个应用程序，即使只是本地。您将看到实际的优缺点。