Rishabh Khandelwal

For straightforward services, we use a persistent storage system and create a storage class in Kubernetes, which will persist all the persistent data in Kubernetes and maintain data consistency. The basic requirement here is defining a storage class and setting up the persistent volumes and behind the persistent volume claims for every or all the required services, which are required for the persistent data.

So while migrating from ECS to GKE, first, we can ensure that the stateful application is always up. And the consideration here is that if we have some virtual machines running in ACS, and during migration, not all machines can be stopped at the same time to provide a sudden downtime in the application, which will lead to downtime for the application. So we can just decrease the number of instances, or compute nodes, gradually, and while increasing the number of nodes in GKE, so that when the application goes down in ECS, the same parts and the same application will be starting up in the GKE console side, so there is no downtime in the application during this migration.

Container resource limits. Here, we define the container's resource limits for memory and CPUs that the container is using. So, some using sidecar ports or some sidecar ports, we can continuously monitor the resource limits in an application, which will predict or define the uses of the current container. And based on this data, you can set resource limits for that container so that we can get optimum performance based on cost and which can lead to cost savings as well.

The message processing in the rabbit time queue, we can ensure that the data is incoming on one side. And while accessing it, the data should be properly accessible to the customer, and it's accessible in parallel to multiple users. This allows for different parallelism setups, which can reduce latency.

Setting up those auto scaling in GCP, we can grab the data and the metrics to monitor CPU and RAM utilization. And according to those utilization, the load balancing methods can be implemented. And, CPU, RAM, and disk storage are the three basic things where the metrics can be obtained, and the rescaling can be adjusted based on it.

The second task in that is debugging and variable engine installation is not, which tends to be a potential failure, and can lead to the failure of the complete playbook code.

So in this container, I can see that the memory is limited to 512 megabytes, and the CPU is limited to 200 or 2 CPUs. So once the request or once the utilization of this port exceeds these limits, then it can lead to potential failure of this port. And because beyond that, if this container is utilizing some higher resources beyond these limits, then it will tend to failure of the board.

For interservice communication in STO, the first thing to consider is that all the services need to be of the cluster IP service type. There is no need to use the node port or any other load balancer service type while using Steel. And the second thing would be to set up the NGINX ingress endpoint, so that it points to only one endpoint.