<p>I have a number of <strong>restful services</strong> within our system</p>
<ul>
<li>Some are our <strong>within</strong> the kubernetes <strong>cluster</strong></li>
<li><strong>Others</strong> are on <strong>legacy</strong> infrasture and are <strong>hosted on VM's</strong></li>
</ul>
<p>Many of our <strong>restful services</strong> make <strong>synchronous calls</strong> to each other (so not asynchronously using message queues)</p>
<p>We also have a number of UI's (fat clients or web apps) that make use of these services</p>
<p>We might define a simple k8s manifest file like this</p>
<ol>
<li>Pod</li>
<li>Service</li>
<li>Ingress</li>
</ol>
<pre><code>apiVersion: v1
kind: Pod
metadata:
  name: &quot;orderManager&quot;
spec:
  containers:
    - name: &quot;orderManager&quot;
      image: &quot;gitlab-prem.com:5050/image-repo/orderManager:orderManager_1.10.22&quot;
---
apiVersion: v1
kind: Service
metadata:
  name: &quot;orderManager-service&quot;
spec:
  type: NodePort
  selector:
    app: &quot;orderManager&quot;
  ports:
    - protocol: TCP
      port: 50588
      targetPort: 50588
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: orderManager-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
    - http:
        paths:
          - path: /orders
            pathType: Prefix
            backend:
              service:
                name: &quot;orderManager-service&quot;
                port:
                  number: 50588
</code></pre>
<p>I am really not sure what the best way for <strong>restful services</strong> on the cluster to talk to each other.</p>
<ul>
<li>It seems like there is only one good route for callers outside the cluster which is use the url built by the ingress rule</li>
<li>Two options within the cluster</li>
</ul>
<p>This might illustrate it further with an example</p>
<div class="s-table-container">
<table class="s-table">
<thead>
<tr>
<th style="text-align: left;">Caller</th>
<th style="text-align: center;">Receiver</th>
<th style="text-align: center;">Example Url</th>
<th style="text-align: right;"></th>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align: left;">UI</td>
<td style="text-align: center;">On Cluster</td>
<td style="text-align: center;">http://clusterip/orders</td>
<td style="text-align: right;">The UI would use the cluster ip and the ingress rule to reach the order manager</td>
</tr>
<tr>
<td style="text-align: left;">Service off cluster</td>
<td style="text-align: center;">On Cluster</td>
<td style="text-align: center;">http://clusterip/orders</td>
<td style="text-align: right;">Just like the UI</td>
</tr>
<tr>
<td style="text-align: left;">On Cluster</td>
<td style="text-align: center;">On Cluster</td>
<td style="text-align: center;">http://clusterip/orders</td>
<td style="text-align: right;">Could use ingress rule like the above approach</td>
</tr>
<tr>
<td style="text-align: left;">On Cluster</td>
<td style="text-align: center;">On Cluster</td>
<td style="text-align: center;">http://orderManager-service:50588/</td>
<td style="text-align: right;">Could use the service name and port directly</td>
</tr>
</tbody>
</table>
</div>
<p><em>I write <strong>cluster ip</strong> a few times above but in real life we put something top so there is a friendly name like http://mycluster/orders</em></p>
<p>So when <strong>caller</strong> and <strong>reciever</strong> are <strong>both on cluster</strong> is it either</p>
<ul>
<li><strong>Use</strong> the <strong>ingress rule</strong> which is also used by services and apps outside the cluster</li>
<li><strong>Use</strong> the <strong>nodeport service name</strong> which is used in the ingress rule</li>
<li>Or perhaps something else!</li>
</ul>
<p><strong>One benefit</strong> of using <strong>nodeport service name</strong> is that you do not have to change your base URL.</p>
<ul>
<li>The <strong>ingress</strong> rule <strong>appends</strong> an <strong>extra elements</strong> to the route (in the above case <em>orders</em>)</li>
<li>When I move a restful service from legacy to k8s cluster it will increase the complexity</li>
</ul>

<p>It depends on whether you want requests to be routed through your ingress controller or not.</p>
<p>Requests sent to the full URL configured in your Ingress resource will be processed by your ingress controller. The controller itself — NGINX in this case — will proxy the request to the Service. The request will then be routed to a Pod.</p>
<p>Sending the request directly to the Service’s URL simply skips your ingress controller. The request is directly routed to a Pod.</p>
<p>The trade offs between the two options depend on your setup.</p>
<p>Sending requests through your ingress controller will increase request latency and resource consumption. If your ingress controller does nothing other than route requests, I would recommend sending requests directly to the Service.</p>
<p>However, if you use your ingress controller for other purposes, like authentication, monitoring, logging, or tracing, then you may prefer that the controller process internal requests.</p>
<p>For example, on some of my clusters I use the NGINX ingress controller to measure request latency and track HTTP response statuses. I route requests between apps running in the same cluster through the ingress controller in order to have that information available. I pay the cost of increased latency and resource usage in order to have improved observability.</p>
<p>Whether the trade offs are worth it in your case depends on you. If your ingress controller does nothing more that basic routing, then my recommendation is to skip it entirely. If it does more, then you need to weigh the pros and cons of routing requests through it.</p>
