<p>I have a doubt regarding how to structure my dockerized stack, simplified in two containers to get help here:</p>

<ul>
<li>static: NGINX serving static resources (JS/HTML).</li>
<li>rest: express.js backend for the REST Api.</li>
</ul>

<p>Without Kubernetes, just docker-compose on a node, <em>rest</em> is simply listening on a different port and, from Javascript, the requests go to <em>same_host:rest_port</em>, no problem here.</p>

<p>With Kubernetes, I understand that I need to use the service name from Kubernetes, something like "rest" (to make transparent the service itself), but that name would only be visible from the docker container serving the static resources.</p>

<p>My question: do I need to forward traffic from NGINX to the REST Api? Does Kubernetes expose a public service name usable from Javascript, for example?</p>

<p>Thank you.</p>

<blockquote>
  <p>With Kubernetes, I understand that I need to use the service name from
  Kubernetes, something like "rest" (to make transparent the service
  itself), but that name would only be visible from the docker container
  serving the static resources.</p>
</blockquote>

<p>Your understanding is correct. <a href="https://stackoverflow.com/a/47029021/6785908">As long as you have a kube-dns add-on running in your cluster</a>, your service name as Domain name is resolvable <strong>with in the same kubernetes cluster and namespace</strong>. In other words, as you said, "rest" will work only with in the kubernetes cluster.</p>

<blockquote>
  <p>My question: do I need to forward traffic from NGINX to the REST Api?
  Does Kubernetes expose a public service name usable from Javascript,
  for example?</p>
</blockquote>

<p>This is one way to achieve this. </p>

<p><strong>Advantage</strong> of this approach is, you will avoid all the Same Origin Policy/CORS headaches, your microservice (express) authentication details will be abstracted out from user's browser. (This is not necessarily an advantage).</p>

<p><strong>Disadvantage</strong> of this approach is, your backend microservice (express) will have a tight coupling with front end (or vice-versa depending on how you look at it), This will make the scaling of backend <strong>dependent</strong> on front end. Your Backend is not exposed. So, if you have another consumer (let's just say an android app) it will not be able to access your service.</p>

<h1>Another Solution</h1>

<p>Create an ingress (and use an ingress controller in your cluster) and expose your Microservice(Express). </p>
