Migration from Kubernetes to EKS
Client is online renting platform where in people can rent out furniture, electronics, fitness equipment and many more such products. The goal was to migrate the existing architecture from a managed Kubernetes environment to EKS cluster (managed by AWS) with minimal downtime, making sure that SLAs are met, and cost is optimized. From a very high-level overview of the infrastructure we found out that there a was a production cluster which was running 24×7 with different application workloads. Testing application connectivity with new setup, maintaining persistency in data of MySQL and Redis and finally the most important thing optimizing the cost was our biggest challenge.
We built a strategy where we would first layout the architecture of the infrastructure of the workloads that were running, then checking the communications between the applications and finding out the dependencies of applications. Next up we provisioned the EKS cluster using EKSCTL utility with m5x.large as our worker node size. We began to install few necessary components such as metric server and cluster autoscaler.
Provisioning of the workloads was our next step ; to ensure that each node is used to its optimal capacity a Horizontal Pod Autoscaler was implemented so that during rush hours pods were scaled automatically , backups of MySQL and redis were also restored at the time when there was very less traffic. As our data was restored in PersistentVolumes it was time to deploy the actual customer facing workload.
Finally, to save cost we added an ALB Ingress Controller which used path-based routing. An Ingress resources was created in which all the routes were added, we also performed SSL termination at the ingress level which itself populated the necessities to ALB. This acted as a major cost saver as we were paying for only one ALB and not multiples load balancers on top of each deployment.
As everything was up and running, we chose a time when we could failover over DNS and bring up the new infrastructure which was running on EKS.
We tremendously reduced the cost when compared to previous infra as earlier there was Load Balancer running on top of each deployment. Also, by using HPA the node utilization was proper because of which the cluster autoscaler was also working optimally.