Istio ingress and egress gateways purpose

Question

I am having trouble understanding what traffic is controlled by ingress and egress istio gateways.

For example, an application sets up listeners on an MQ queue. Is this an example of ingress or egress traffic? I thought that where the application initiates the connection, then this traffic will be directed to the egress gateway. Conversely, if the application is an endpoint, then traffic must be routed through the ingress gateway.
Let's say application A is an external service to application B. Application A makes a rest request to B. Should this request be routed through ingress? Now application B makes a rest request to A. Should traffic go through egress now?

This depends entirely on how the TCP connections are established. If Application A initiates the connection to B, it will be routed via the egress, assuming the virtual services / gateway / destination rules have been configured as such. Vice versa B -> A will go via the ingress resource into your sidecar and proxied. Default behaviour I believe, assuming Envoy is enabled on your pod. Traffic will be directed out of Egress and in through Ingress. — Dandy
to be sure: 1) application A deployed in openshift, application B work outside openshift cluster. So if app A initiates a connection (for example, send post request to 'serverB/test') to B, this request must be routed via ingress gateways. 2) application A connect to external database server (not in openshift cluster) via egress gateways? — pwflamy
@pwflamy 1) correct, 2) not exactly, AFAIK it goes through passthrough cluster, as mentioned here but you can enable egress and send the outgoing traffic through it if you want, take a look here, it should explain you everything. — Jakub
@Jakub wait, what is mean "initiate a connection"? If we run command [appA]: curl appB, does it mean that appA initiate a connection to appB ? I ask because if you follow your answer below, it turns out that my first example in comment is wrong. Or I do not understand correctly "initiate connection" (look that in my comment appA inside service mesh and appB is external service) — pwflamy
@pwflamy sorry, I missunderstood the second question and though appA is external and appB is inside the mesh. As mentioned below in my example appA is external service outside the mesh and appB is injected service in the istio mesh. — Jakub

Jakub Jakub · Accepted Answer · 2020-09-10T07:05:28

Let's start with some theory. I have found few sources which describes how istio ingress gateway and egress gateway works.

Istio documentation

Istio uses ingress and egress gateways to configure load balancers executing at the edge of a service mesh. An ingress gateway allows you to define entry points into the mesh that all incoming traffic flows through. Egress gateway is a symmetrical concept; it defines exit points from the mesh. Egress gateways allow you to apply Istio features, for example, monitoring and route rules, to traffic exiting the mesh.

Istio in action book

For our applications and services to provide anything meaningful, they’re going to need to interact with applications that live outside of our cluster. That could be existing monolith applications, off-the-shelf software, messaging queues, databases, and 3rd party partner systems. To do this, operators will need to configure Istio to allow traffic into the cluster and be very specific about what traffic is allowed to leave the cluster. The Istio components that provide this functionality are the istio-ingressgateway and istio-egressgateway.

And here's a picture that shows it well

Banzaicloud

An ingress gateway serves as the entry point for all services running within the mesh.

egress gateways are exit points from the mesh that allow us to apply Istio features. This includes applying features like monitoring and route rules to traffic that’s exiting the mesh.

About your questions

For example, an application sets up listeners on an MQ queue. Is this an example of ingress or egress traffic? I thought that where the application initiates the connection, then this traffic will be directed to the egress gateway. Conversely, if the application is an endpoint, then traffic must be routed through the ingress gateway.

I'm not familiar with message queues, but based on above picture let's assume consumers are inside the mesh, so producer services would have to go there through ingress gateway.

[Producer Service] -> ingress gateway -> [envoy sidecar -> Consumer Service]

So yes, the traffic must be routed through the ingress gateway

Let's say application A is an external service to application B. Application A makes a rest request to B. Should this request be routed through ingress? Now application B makes a rest request to A. Should traffic go through egress now?

If service inside service mesh want to talk with external service we should start with configuring egress and service entry for it.

Because all outbound traffic from an Istio-enabled pod is redirected to its sidecar proxy by default, accessibility of URLs outside of the cluster depends on the configuration of the proxy. By default, Istio configures the Envoy proxy to passthrough requests for unknown services. Although this provides a convenient way to get started with Istio, configuring stricter control is usually preferable.

Based on my knowledge that's how the traffic would like this.

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

Let's assume you want to use curl from appA to appB

[app A](curl ingress-external-ip/specific path or port) -> ingress gateway -> [envoy sidecar -> appB]

Let's assume you want to use curl from appB to appA

[appB -> envoy sidecar](curl appA) -> egress gateway -> [appA]

Let me know in the comments if you have any more questions or you want to discuss something.