<p>We have several microservices(NodeJS based applications) which needs to communicate each other and  two of them uses Redis and PostgreSQL. Below are the name of of my microservices. Each of them has their own SCM repository and Helm Chart.Helm version is 3.0.1. We have two environments and we have two values.yaml per environments.We have also three nodes per cluster.</p>

<p>First of all, after  end user's action, UI service triggers than it goes to Backend. According to the end user request Backend services needs to communicate any of services such as Market, Auth and API.Some cases API and market microservice needs to communicate with Auth microservice as well.</p>

<ol>
<li>UI --></li>
<li>Backend</li>
<li>Market --> use postgreSQL </li>
<li>Auth  --> use Redis</li>
<li>API</li>
</ol>

<p>So my questions are,</p>

<ul>
<li><p>What should we take care to communicate microservices among each other?  Is this <code>my-svc-namespace.svc.cluster.local</code> enough to provide developers or should we specify ENV in each pod as well?</p></li>
<li><p>Our microservices is NodeJS application. How developers. will handle this in application source code? Did they use this service name if first question's answer is yes?</p></li>
<li><p>We'd like to expose our application via ingress using host per environments? I guess ingress should be only enabled for UI microservice, am I correct?</p></li>
<li><p>What is the best way to test each service can communicate each other?</p></li>
</ul>

<hr>

<pre><code>kubectl get svc --all-namespaces

NAMESPACE     NAME                                         TYPE            

database      my-postgres-postgresql-helm                  ClusterIP                      
dev           my-ui-dev                                    ClusterIP 
dev           my-backend-dev                               ClusterIP 
dev           my-auth-dev                                  ClusterIP                 
dev           my-api-dev                                   ClusterIP 
dev           my-market-dev                                ClusterIP
dev           redis-master                                 ClusterIP                       
ingress       ingress-traefik                              NodePort            
</code></pre>

<p><strong>Two ways to perform Service Discovery in K8S</strong></p>

<p>There are two ways to perform communication (service discovery) within a Kubernetes cluster.</p>

<ul>
<li><a href="https://kubernetes.io/docs/concepts/services-networking/connect-applications-service/#environment-variables" rel="nofollow noreferrer">Environment variable</a></li>
<li><a href="https://kubernetes.io/docs/concepts/services-networking/connect-applications-service/#dns" rel="nofollow noreferrer">DNS</a></li>
</ul>

<p>DNS is the simplest way to achieve service discovery within the cluster.
And it does not require any additional ENV variable setting for each pod.
As its simplest, a service within the same namespace is accessible over its service name. e.g <a href="http://my-api-dev:PORT" rel="nofollow noreferrer">http://my-api-dev:PORT</a> is accessible for all the pods within the namespace, <code>dev</code>.</p>

<p><strong>Standard Application Name and K8s Service Name</strong></p>

<p>As a practice, you can give each application a standard name, eg. <code>my-ui</code>, <code>my-backend</code>, <code>my-api</code>, etc. And use the same name to connect to the application.
That practice can be even applied testing locally from developer environment, with entry in the <code>/etc/host</code> as </p>

<pre><code>127.0.0.1 my-ui my-backend my-api
</code></pre>

<p>(Above is nothing to do with k8s, just a practice for the communication of applications with their names in local environments)</p>

<p>Also, on k8s, you may assign service name as the same application name (Try to avoid, suffix like <code>-dev</code> for service name, which reflect the environments (dev, test, prod, etc), instead use namespace or separate cluster for that). So that, target application endpoints can be configured with their service name on each application's configuration file.</p>

<p><strong>Ingress is for services with external access</strong></p>

<p>Ingress should only be enabled for services which required external accesses.</p>

<p><strong>Custom Health Check Endpoints</strong></p>

<p>Also, it is a good practice to have some custom health check that verify all the depended applications are running fine, which will also verify the communications of application are working fine.</p>
