Keerthik Shenoy

I'm Kirtik. I'm a cloud engineer with 3 years of experience. I changed my career with Thomson Reuters for a short period of time. I worked as a SRE for 6 months. For now, I'm working with Multifigus Mobility System as a cloud engineer for the past 1 plus years. Here, my main responsibilities as a member of the R&D team are implementing new technologies as well as automating gateway tasks. Here, my main core competencies are AWS. Almost 3 plus years, I've worked on AWS. Apart from that, in the past 1 year, I've been working with

Kubernetes cluster notice indicates it's not ready. It might be multiple issues. Maybe whatever notes are getting created that EMI does not have, like a cubelet to connect with the node. Otherwise, the node role will be mismatched or in the node role, some permissions will be missed due to that. It's not able to connect with the cluster. Also, there might be some issues in the security group. Yeah. All these are potential problems.

Yeah. If ports are going to crash loop, first, I will check the port status by describing the port. Also, we can check the port logs. While describing the port, we'll get the exact reason why it's going to crash loop. It might be an image pull error, or it might be due to a CPU or memory issue, or it might be due to nodes not being enough to start that part. Otherwise, it might be with some deployment file, such as a readiness or liveness probe, or a mismatch issue that we can troubleshoot. Apart from that, in the application, some issue might be there. We'll get it from

Yeah. To design well-architected architecture, first, we'll create a VPC with the proper public and private subnets. Whatever our Kubernetes cluster, database server, or application will be hosted in private subnets with all the proper security group roles and I am roles with minimum privileges. Also, for EKS, normally we use cluster autoscaler and for level horizontal pod autoscaler we are using. We'll use auto scaling for easy management of machines, based on metrics-based auto scaling. Also, in public subnets, we'll place the load balancer application load balancer. If we receive any traffic, we'll use the network load balancer. And we are using 53 for DNS snapping. Also, in Kubernetes, we'll take care of all the auto scaling things, everything. In this, it will also take care of all the auto scaling. Like, whenever nodes hit high, it will automatically scale up. And whenever nodes go down, it's automatically scaled down. Also, for disaster recovery, we can keep multiple kinds, like, we can keep active-active or, we can keep EBS backups or something. What active-active will be more costly. So normally, if you're in a small organization, we'll take a backup of all the EC2 instances, EBS, everything. Keep it ready for if anything went wrong, we'll be able to recreate that complete infrastructure again. Also, we can use Terraform to form this complete infrastructure, whenever it goes down or something, we can easily handle that.

Yeah, first, we go through the issue. What's actually happening in that given disclosure or something? And if it's a production issue, we have to give it high priority and make it top. Or if it's taking more time to do R&D or something, we have to give an alternative solution. Like, we have to give some backup solution for that application to avoid downtime. In that type, we'll troubleshoot. Like, we'll create the same, we'll be able to see the matter of each stage or something, and we will check on that. Once we'll get the R&D done, we'll fix that issue in production. Until then, we'll roll back or something. We'll take up an option to avoid that.

To maintain all the information up to date, normally we maintain the document. Whenever we encounter a new scenario or troubleshooting game, we create a document for that. And whenever we get new changes or updates, we keep them in proper documentation as well. I mean, for infrastructure changes, if you're using Terraform, we use a remote state file. This will contain all those details, so we can check the remote state file as well. Apart from documentation, the main thing is to keep it up to date. Also, the troubleshooting documentation must be kept up to date.

Yeah. Mainly because he mentioned 100 MBs, like 100 CPU. It can request. Also, maximum it can go to 200. But your application is CPU intensive. It can go up to a higher level of that, but we have limits here. So it's not crossing that limit because it's facing a performance issue. So we have to increase the limit. So normally, it will request for 100.

I'm not that good. However, it was in line-ups but some field I can explain. Here's closely what the process is running. Here, the process ID is 1 plus command plus user. Sorry. The user. From which user the process is running. From the root user, it's running. Apart from that, CPU percentage, how much it's using, and memory percentage, how much it's using. For the type, in what time it started, or what time it's running.

Normally, we're working with multiple cloud language connectivity between each cloud. It's one of the main challenges. We can resolve it by using side-to-side VPN. Like, you know, configuring VPN between cloud providers, and we can connect our VPCs between each other. This is the main challenge. Apart from that, in each cloud environment, the process will be different to manage or create a cluster, so we have to maintain everything up and running. Also, auto-scaling everything.

We worked on VM and Tatsu, but I welcome Rafana and Prometheus. Here, mainly, we'll check CPU usage, the usage of each part's deployment, and note memory usage, all those things. Apart from that, application-related metrics will be taken care of. Also, load count and all those things will be taken care of.