-
Notifications
You must be signed in to change notification settings - Fork 1
YAML Files
Building the YAML files for running services on Kubernetes was the most challenging task.
Since the API-gateway is hosted on a server it should be accessible on a port. So its YAML is supposed to have a Node port. So it was deployed as a service that could be accessible to the public on the Nodeport and a deployment that made respective pods for the same.
The user-management was also built in a similar fashion as the API-gateway.
The user-interface was also built in a similar fashion as the API-gateway.
Data retrieval isn't a service meant to be accessed publicly. It's just a background service which helps with sending and receiving data. So it is deployed in pods alone and not as a service.
The model-execution was also built in a similar fashion as the data-retrieval.
The post-processing was also built in a similar fashion as the data-retrieval.
Session management has server and database running as deployment. Besides, the server is running a replica set and database service.
All these services mentioned are made to run by the file and there's cross-correlation among them, meaning when a microservice is deployed as a deployment it automatically generates pods for it and removing the deployment alone terminates the pod. Termination of the pod can take time when you try to redeploy the service but it doesn't clash with that.
For example, data-retrieval is running as deployment and there are pods allocated for it. So if we just delete its pods the pods are regenerated by the deployment and if you want to restart the service you need to remove its generator which is the deployment itself. Similarly, if you have a replica set and you want to remove its service. You need to remove the replica set, not the service to restart it. Otherwise, the replica set will keep on regenerating the service and its respective pods again and again.