我无法理解由入口和出口istio网关控制的流量。
答案 0 :(得分:4)
让我们从一些理论开始。我发现很少有资料描述istio入口网关和出口网关的工作原理。
Istio使用入口和出口网关来配置在服务网格边缘执行的负载平衡器。入口网关使您可以定义进入所有输入流量流经的网格的入口点。出口网关是一个对称的概念。它定义了网格的出口点。出口网关使您可以将Istio功能(例如监视和路由规则)应用于离开网状网络的流量。
要使我们的应用程序和服务提供有意义的任何内容,他们将需要 与群集外的应用程序进行交互。那可能是现有的巨石 应用程序,现成的软件,消息传递队列,数据库和第三方合作伙伴系统。 为此,运营商将需要配置Istio以允许流量进入群集,并且 具体说明允许哪些流量离开群集。 提供此功能的Istio组件是 istio-ingressgateway 和 istio-egressgateway 。
这是一张很好的图片
入口网关充当网格中运行的所有服务的入口点。
出口网关是网格的出口点,允许我们应用Istio功能。这包括将诸如监视和路由规则之类的功能应用于离开网格的流量。
例如,应用程序在MQ队列上设置侦听器。这是入口流量或出口流量的示例吗?我认为,在应用程序启动连接的地方,那么此流量将被定向到出口网关。相反,如果应用程序是端点,则必须通过入口网关路由流量。
我对消息队列不熟悉,但是根据上图,我们假设消费者位于网格内,因此生产者服务必须通过入口网关到达那里。
[生产者服务]->入口网关-> [特使车->消费者服务]
是的,流量必须通过入口网关进行路由
让我们说应用程序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 /特定路径或端口)->入口网关-> [特使边车-> appB]
假设您要使用curl从appB到appA
[appB-> envoy sidecar](curl appA)->出口网关-> [appA]
在评论中让我知道您是否还有其他问题或想要讨论的话题。