G Kesava

I'm a full-time DevOps engineer. Mostly, I've concentrated on Azure and AWS cloud platforms. And I'm trying to enhance my skills in AWS DevOps and Azure. Coming to the CAC report. GitHub actions and Jenkins, which they will see, is all. Currently, we're dealing with the.NET application framework, Microsoft-based development into the Kubernetes environment. So, I'm more into Kubernetes, Docker, AWS different services, and Azure services, as well as various enhancements with AWS services. I have much experience building the CAC pipeline from scratch to end with automation included.

So, there's a Kubernetes object called the Horizontal Pod Autoscaler, With that, using that Kubernetes object, I'll configure the Kubernetes object accordingly, and also, I will mention the required resources, request and limits in the deployment so that auto scaling occurs based on the request and limits and the percentage of the threshold given in the horizontal autoscaler. Minimum and maximum, that should be mentioned there. And also, the roles and role bindings should be created for the auto scaling to occur properly. So, all this configuration will be done in the deployment, this, Kubernetes manifest files. These, the other deployment and horizontal pod autoscaler files can be separate, pre-maintained, or they can be clubbed into the same file based on the maintainable day of the project.

So what I'll say kill in Kubernetes is there are different states of words. So running status and the EMS pullback or can be UNESCO back up status or crash through backup status. Or it is still not started at pending status where it may take a long time to get into the start status. So the updates of the port will be rolling updates, which means once we deploy this replica of the port, it will wait for the other port to be in the running state, and the existing port will be terminated only after the other port gets running.

So I will deploy my application in two regions. One is supposedly used with version 1 and he has used version 2. So that deployment, whenever the upgrade happens to one of the regions with two of the applications, by using the load balancer, I will send the load balancer to redirect the traffic to another region, which will become the green deployment. At that time, the environment which is stable will become the blue.

So data form, we're introducing an automation tool. The integration means for Kubernetes, so we need to create the Azure case using Terraform. The required prerequisite for the Azure API is the way VPCs and subnets should be created. Before going into the APIs, I will create the VPCs and the corresponding resources in Terraform. Whatever resources are created, I will use those VPC IDs to use in that Kubernetes Terraform template. This can be managed in separate modules for the reuse purpose. Yeah.

The name is this is logical. The name is this is logical differentiation between the resources or in the queue. But it is supposed, for example, if you want to have access to in Kubernetes, not only to the respective ports or respective resources. So, we will differentiate those resources, and we will create those resources in different namespaces so that this set of people will have only access to this namespace so that the access can be restricted. So for some dev problem, we can create a namespace with specific names. This is just an example of where we can use the namespace for a customer.

Then based on web headshots, for the Kubernetes deployments or any Kubernetes objects, we have to follow. We need to create more net a lot of managed files. So, the end source will club all the required managed files, and just it's like a package of whatever the resources, the Kubernetes objects we need for the successful Kubernetes deployments. This is used for this purpose. And managing dependencies in the YAML file, we can change the values in the YAML file for the required dependencies and make modifications, any modifications custom from charts to prepare. I'll just start the MLK file can be configured accordingly. And by using that file, we can modify it. We can deploy our customized Helm charts.

So first and foremost thing is, we can use different namespaces for different sets of teams. And also, we can have network policies assigned to the port so that the port between ports accesses the other port only with a set of network policies and rules. And also, clusters outside the cluster should be able to access Kubernetes only with the specified IAM roles and service accounts. And thus, using service accounts for this purpose is very much helpful for following the security measures. Role-based access controls should also be implemented to prevent unauthorized access. Yeah. These are the list of things that we can look into.

So the steps for applications. First, you need to submit your resume and cover letter through our website. Next, our team will review your application to make sure you meet the minimum qualifications for the position. If you pass the initial review, we will invite you to take a skills assessment test to evaluate your technical skills. After that, we will schedule an interview with our hiring manager to discuss your experience and fit for the role. Finally, we will make an offer to the selected candidate and begin the onboarding process.

It's going to be a challenge anyway, so the Kubernetes cluster. We have a Kubernetes cluster. So, at present, I'm using Prometheus and Grafana, and also Datadog for the QV cluster. So, why miss out? I can explain regarding the Datadog implementation. The Datadog will capture real-time logs of the Kubernetes cluster, and it also has a version for application performance and monitoring too. And you can also have synthetic testing with the data log. Also, any HTTP errors, we can monitor those regarding an application. We can monitor that.

So application performance is here as I have said in the previous one. So the third letter will be best for it, for the application also, because it gives very detailed information, even with millions of application logs, it views them seamlessly. So based on the latency between the flowing of the logs and the application performance, we can decide on our infrastructure planning.