Microservice structure using helm and kubernetes

1
votes

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.

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.

  1. UI -->
  2. Backend
  3. Market --> use postgreSQL
  4. Auth --> use Redis
  5. API

So my questions are,

  • What should we take care to communicate microservices among each other? Is this my-svc-namespace.svc.cluster.local enough to provide developers or should we specify ENV in each pod as well?

  • 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?

  • 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?

  • What is the best way to test each service can communicate each other?

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
1
kuberneteskubernetes-helm

1 Answers

1
votes

Two ways to perform Service Discovery in K8S

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

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 http://my-api-dev:PORT is accessible for all the pods within the namespace, dev.

Standard Application Name and K8s Service Name

As a practice, you can give each application a standard name, eg. my-ui, my-backend, my-api, 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 /etc/host as 

127.0.0.1 my-ui my-backend my-api

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

Also, on k8s, you may assign service name as the same application name (Try to avoid, suffix like -dev 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.

Ingress is for services with external access

Ingress should only be enabled for services which required external accesses.

Custom Health Check Endpoints

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.