Istio 入口和出口网关的用途答案

【问题标题】：Istio ingress and egress gateways purposeIstio 入口和出口网关的用途
【发布时间】：2020-12-27 15:26:51
【问题描述】：

我无法理解入口和出口 istio 网关控制的流量。

例如，应用程序在 MQ 队列上设置侦听器。这是入口或出口流量的示例吗？我认为应用程序在哪里启动连接，然后这个流量将被定向到出口网关。相反，如果应用程序是端点，则流量必须通过入口网关路由。
假设应用程序 A 是应用程序 B 的外部服务。应用程序 A 向 B 发出休息请求。此请求是否应该通过入口路由？现在应用 B 向 A 发出休息请求。流量现在应该通过出口吗？

【问题讨论】：

这完全取决于 TCP 连接是如何建立的。如果应用程序 A 发起到 B 的连接，它将通过出口路由，假设虚拟服务/网关/目标规则已配置为这样。反之亦然 B -> A 将通过入口资源进入您的 Sidecar 并被代理。我相信默认行为，假设 Envoy 在您的 pod 上启用。流量将被引导出 Egress 并通过 Ingress 进入。
确定：1）应用程序A部署在openshift中，应用程序B在openshift集群之外工作。因此，如果应用 A 向 B 发起连接（例如，向 'serverB/test' 发送 post 请求），则该请求必须通过入口网关进行路由。 2）应用程序A通过出口网关连接到外部数据库服务器（不在openshift集群中）？
@pwflamy 1) 正确，2) 不完全正确，AFAIK 它通过直通集群，如上所述 here 但您可以启用出口并通过它发送传出流量，看看here，它应该可以解释一切。
@Jakub 等等，“启动连接”是什么意思？如果我们运行命令[appA]: curl appB，是否意味着 appA 启动了与 appB 的连接？我问是因为如果您按照下面的答案进行操作，事实证明我在评论中的第一个示例是错误的。或者我没有正确理解“启动连接”（在我的评论 appA 里面的服务网格和 appB 是外部服务）
@pwflamy 抱歉，我误解了第二个问题，虽然 appA 是外部的，而 appB 是在网格内部。正如下面在我的示例中提到的，appA 是网格之外的外部服务，而 appB 是 istio 网格中的注入服务。

标签： kubernetes openshift istio

【解决方案1】：

让我们从一些理论开始。我发现很少有资源描述了 istio 入口网关和出口网关的工作原理。

Istio documentation

Istio 使用入口和出口网关来配置在服务网格边缘执行的负载均衡器。入口网关允许您定义所有传入流量流过的网格的入口点。出口网关是一个对称的概念；它定义了网格的出口点。出口网关允许您将 Istio 功能（例如监控和路由规则）应用于离开网格的流量。

Istio in action book

为了让我们的应用程序和服务能够提供任何有意义的东西，它们需要与位于我们集群之外的应用程序交互。那可能是现有的单体应用程序、现成的软件、消息队列、数据库和第 3 方合作伙伴系统。为此，运营商需要配置 Istio 以允许流量进入集群并且非常具体关于允许哪些流量离开集群。提供此功能的 Istio 组件是 istio-ingressgateway 和 istio-egressgateway。

这里有一张图片很好地展示了它

Banzaicloud

入口网关充当网格中运行的所有服务的入口点。

出口网关是网格的出口点，允许我们应用 Istio 功能。这包括将监控和路由规则等功能应用于离开网格的流量。

关于您的问题

例如，应用程序在 MQ 队列上设置侦听器。这是入口或出口流量的示例吗？我认为应用程序在哪里启动连接，然后这个流量将被定向到出口网关。相反，如果应用程序是端点，则流量必须通过入口网关路由。

我不熟悉消息队列，但根据上图假设消费者在网格内，因此生产者服务必须通过入口网关到达那里。

[生产者服务] -> 入口网关 -> [envoy sidecar -> 消费者服务]

所以是的，流量必须通过入口网关路由

假设应用程序 A 是应用程序 B 的外部服务。应用程序 A 向 B 发出休息请求。该请求是否应该通过入口路由？现在应用 B 向 A 发出休息请求。流量现在应该通过出口吗？

如果服务网格内的服务想要与外部服务通信，我们应该从配置egress 和service entry 开始。

因为默认情况下，来自启用 Istio 的 pod 的所有出站流量都被重定向到其 sidecar 代理，所以集群外 URL 的可访问性取决于代理的配置。默认情况下，Istio 将 Envoy 代理配置为传递未知服务的请求。虽然这为开始使用 Istio 提供了一种便捷的方式，但通常最好配置更严格的控制。

据我所知，流量会是这样的。

appA -> external service outside the mesh
appB -> injected service in the istio mesh

假设您想从 appA 到 appB 使用 curl

[app A](curl ingress-external-ip/特定路径或端口) -> ingress gateway -> [envoy sidecar -> appB]

假设您想从 appB 到 appA 使用 curl

[appB -> envoy sidecar](curl appA) -> 出口网关 -> [appA]

如果您还有任何问题或想讨论某些事情，请在 cmets 中告诉我。

【讨论】：