<p>I am having trouble understanding what traffic is controlled by ingress and egress istio gateways.</p>
<ol>
<li>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.</li>
<li>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?</li>
</ol>

<p>Let's start with some theory. I have found few sources which describes how istio ingress gateway and egress gateway works.</p>
<h2><a href="https://istio.io/latest/docs/tasks/traffic-management/egress/egress-gateway/" rel="noreferrer">Istio documentation</a></h2>
<blockquote>
<p>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.</p>
</blockquote>
<hr />
<h2><a href="https://www.manning.com/books/istio-in-action" rel="noreferrer">Istio in action book</a></h2>
<blockquote>
<p>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 <strong>istio-ingressgateway</strong> and
<strong>istio-egressgateway</strong>.</p>
</blockquote>
<p>And here's a picture that shows it well</p>
<p><a href="https://i.stack.imgur.com/Be14u.png" rel="noreferrer"><img src="https://i.stack.imgur.com/Be14u.png" alt="enter image description here" /></a></p>
<hr />
<h2><a href="https://banzaicloud.com/" rel="noreferrer">Banzaicloud</a></h2>
<blockquote>
<p>An ingress gateway serves as the entry point for all services running within the mesh.</p>
</blockquote>
<p><a href="https://i.stack.imgur.com/iL2wK.png" rel="noreferrer"><img src="https://i.stack.imgur.com/iL2wK.png" alt="enter image description here" /></a></p>
<blockquote>
<p>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.</p>
</blockquote>
<p><a href="https://i.stack.imgur.com/sJ3aM.jpg" rel="noreferrer"><img src="https://i.stack.imgur.com/sJ3aM.jpg" alt="enter image description here" /></a></p>
<hr />
<h2>About your questions</h2>
<blockquote>
<p>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.</p>
</blockquote>
<p><a href="https://i.stack.imgur.com/j9owC.png" rel="noreferrer"><img src="https://i.stack.imgur.com/j9owC.png" alt="enter image description here" /></a></p>
<p>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.</p>
<p>[Producer Service] -&gt; ingress gateway -&gt; [envoy sidecar -&gt; Consumer Service]</p>
<p>So yes, the traffic must be routed through the ingress gateway</p>
<hr />
<blockquote>
<p>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?</p>
</blockquote>
<p>If service inside service mesh want to talk with external service we should start with configuring <a href="https://istio.io/latest/docs/tasks/traffic-management/egress/egress-control/" rel="noreferrer">egress</a> and <a href="https://istio.io/latest/docs/reference/config/networking/service-entry/" rel="noreferrer">service entry</a> for it.</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>Based on my knowledge that's how the traffic would like this.</p>
<pre><code>appA -&gt; external service outside the mesh
appB -&gt; injected service in the istio mesh
</code></pre>
<p>Let's assume you want to use <a href="https://curl.haxx.se/docs/manpage.html" rel="noreferrer">curl</a> from appA to appB</p>
<p>[app A](curl ingress-external-ip/specific path or port) -&gt; ingress gateway -&gt; [envoy sidecar -&gt; appB]</p>
<p>Let's assume you want to use <a href="https://curl.haxx.se/docs/manpage.html" rel="noreferrer">curl</a> from appB to appA</p>
<p>[appB -&gt; envoy sidecar](curl appA) -&gt; egress gateway -&gt; [appA]</p>
<hr />
<p>Let me know in the comments if you have any more questions or you want to discuss something.</p>
