Akhil shaganti

Okay. I have total 6.5 years of experience working into IT industry. Out of which, the last 4 years, I'm working for, uh, uh, like, working as a DevOps engineer, uh, here. So the past, uh, 2 years, I worked for a company called, uh, Milestone Technologies, where I work for 2 different clients. And currently, I'm supporting the Moet company, Moet Technologies, and I'm supporting the Google client. So I work, uh, primarily with all the DevOps tools. So I got an opportunity to work as a build release, uh, engineer along with the main infrastructure and troubleshooting and monitoring purpose. So as part of as part of my experience, I have, uh, I had a privilege of working with the tools like, uh, Jenkins for CICD operations, Git and GitHub for, uh, source code management. Then I've used Ansible for, uh, making sure the configuration management is taking place properly. And our servers are based out of a w, uh, like, uh, app AWS, uh, cloud environment. So it's based out of North Virginia region. So I used Ansible to make sure to automate the things to create softwares, to create users, and maintain configuration management for all those, uh, uh, servers. And I also used Terraform extensively to build up the infrastructure, meeting the state of the application, even in the disaster situations, making sure that the services are like, I can spin up the infrastructure as quickly as possible. And I've used Docker and Kubernetes very extensively to create containers and, uh, migrating some traditional applications towards Kubernetes environment and making sure, um, reducing cost cutting thing can happen. And I've used Python where automation is needed. So I used Python to automate Jenkins and also Docker. And there is a use case where, uh, using Python, I have created auto scaling thing, uh, in doc in Dockerspam because Dockerspam doesn't support auto scaling by default. So with using Python, I was able to create the auto scaling feature, um, in, uh, in in Python using Python and Docker. So that is 1 use case. And and I have experience monitoring on from this in Grafana dashboard. So these are the different tool sets that I've worked, uh, in my, uh, experience. And currently, I'm supporting the Google project, and I'm currently a main POC for a project where we are using Terraform. And there are some internal tools of Google, like something called Rapid and. So these tools are exactly as a, uh, like, alternate to the tools that we use in the outside market like Jenkins. So rapid is exactly an alternate to Jenkins. So I'm trying to automate the Jenkins along with Terraform in order to bring up a new, uh, like, tool called as Irvin. So the main intention is, uh, when we write a CICD pipeline, it makes sure the CICD operation happens smoothly. And Terraform is used to create the infrastructure and maintain the infrastructure of state. So why can't we have an application where if we write the code, it it creates the application, it creates the infrast sorry. Instead of updating, it creates the infrastructure and also create the CICD operation all at once. So that is the intention of our tool. So I'm currently working on that, uh, trying to automate the, uh, like, rapid tool along with Terraform using remote back ends and module concept in Terraform. I'm currently working on that. So that's all about me. Thank you.

What considerations are important when you configure network policy in Kubernetes from microservice architecture? So, um, according to me, first of all, we have to understand the use case, what we are trying to build up. For example, there are 4 different service objects in, uh, Kubernetes. Like, we have got node port, load balancer, uh, headless, and, uh, like, uh, cluster IP. So out of this, which 1 would be suiting our our use case? So if at all we are trying to, uh, like, build communication with bots with the outside, but if you want to, like, send send traffic in and out of the cluster to have the public facing, uh, servers to communicate with them, then we should be using something like, uh, node port or load balance. But if you want applications to internally talk with each other, then cluster IC is more than sufficient. And if you are using, uh, uh, the service object in order to make sure the database kind of thing where stateful applications data is maintained and preserved and data should be communicating. And communication should happen between the different bots and deployed in stateful setting. Headless is sufficient. And, uh, but whenever you're talking with the outside world, then only we need load balanced or node port. And when we are using any managed to set up uh, Azure Kubernetes, AKS or EKS or GKE, Google, uh, Kubernetes engine. So in those situations, load balancing is the best option because load balancing provides a specific IP address, and that IP address can be used, uh, for us, uh, in order to make sure, uh, to maintain the load balancing. So we can use that into the, uh, the, uh, load balancer, whichever load balancer we are, uh, having. So we can use that this IP address generated by the managed Kubernetes setup. That IP address can be used, and that itself is sufficient to, uh, route traffic to the necessary port. So these ports would be interacting with each other based on the service definition file that we have, uh, have written, and it tries to check which, uh, like, service definition file has to go. And from there, it tries to see, uh, which, uh, node selector terms, like, select our match label. Based on that, it tries to go and verify that and tell it to traffic. And in between, however, we have the ingress controller with having the information about path based routing or host host with routing. So in that way, setting up the steps in a proper way, identifying which, uh, type of service object we need may, uh, place a very important role. Only then, if we have a proper English controller written with pass based or host based routing along with the right, uh, the service object dimension, like load balancer or node port. And then men men correctly mentioning the, uh, node selector terms, uh, in the, uh, manifest file of the service object, make sure the right traffic in and out can be transferred without any Huddl. So these are the few things I very keenly observe and consider before I am trying to set up any network, uh, policies in the Kubernetes microservice service architecture. That's my answer. Thank you.

Uh, I'm I'm I'm really sorry. I have never had an experience or did not get any opportunity to work on the Kubernetes grid. But, uh, if I have to speak about how Kubernetes, uh, tries to, uh, like, uh, have the important components and how they interact. I would say the main important components would be, uh, first of all, on the, uh, main, uh, cluster main master, we would have a container runtime. We have cube API server. We have managed controller. We have managed controller and, uh, cube scheduler and HCD. So the main purpose of HCD is to main it has a key value based database, which stores the information about the right, uh, different nodes, different what all ports deployed on different environments. Everything is maintained. It has a key value kind of database. Key value based storage. So replication, uh, like, a managed controller or manager and, uh, like, cube, uh, controller. Cube controller and cube scheduler. They make sure cube controller makes sure that it tries to always verify how many what is the desired state and what is the actual state? Are the number of ports that are defined are properly maintained or not? Are there anything that's been down? If it is down, immediately turn it up. So that is its purpose. So it always mean verifies the HCD and tries to work on that. And kube scheduler main purpose is to verify where exactly there is more space where a note which node can accommodate another port. So based on that, it tries to schedule the, uh, like, the ports on that thing. And kube API server is the first thing which verifies whether they need Kube SQL command that has run, uh, the person who is running, he has the right access to run that command or not. Everything, it verifies. It's an API server. Once it confirms, only then the application like, the command will be executed. And container run time is, of course, its docker, basically, so which provides the containerization platform. And on the, uh, slave machines, the different things that run are kubelet, kube proxy, and, again, container runtime. Container runtime is, again, docker because it has to be in sync to understand the commands. And kubelet's main purpose is to it takes the command from the cube, uh, con configure the cube scheduler and control manager. And based on that, it actually creates the ports on different environments and pushes them here and there whenever it's needed. Its main purpose is to work on real time creating a port and maintaining the state of it. And kube proxy's main purpose is to make sure it it provides the traffic so it integrate it make sure that the service object is properly communicating with the port. So it make sure that the ports of the same architecture are placed nearby, uh, on based on nearby nodes or on single nodes so that communication happens more smoothly and service object is properly able to communicate with the port that is created. That's the main purpose of q proxy. It is a real time thing that make sure traffic in and out is transferring to the port to the outside world and vice versa. So these are the different, uh, objects that are available on the master and the slave architecture. So most probably, I believe, Tanzu, Kubernetes also might have the similar thing because it is a Kubernetes environment. Uh, of of course. But cube but it has a specific name, Tanzu, so there could be something more it could do and much more better features, but I'm really not aware. But, uh, I will learn it out if needed. Thank you. That's all my answer about this.

Can you detail the security measures you've implemented in a Kubernetes cluster to prevent unauthorized access? Yes. Security measures would implement in Kubernetes cluster to prevent unauthorized access. Okay. First of all, uh, the main thing comes up is having the right level of access. So whenever in Kubernetes, when we have set up an environment, we have to make sure the security groups, like, only, uh, like, whichever application has to communicate, we should open the ports only for those application, not for everything. So first level of security is achieved. So only the known traffic from the node's sources will be coming to our cluster. Second thing is, uh, like, we would make sure that right level of permission is given to each person. So, like, all QCL commands are not open for everyone. So we should make sure that we provide modular permissions. Like, our developer would have a specific kind of confirmations, and, uh, main admin, kube units, uh, main admin has a specific, uh, uh, like, commands. A space specific level of, uh, permission is given to run only a few commands. So in that way, if we define which level of permission is given to each person, then the level of security can be definitely improved. And regular monitoring is needed and regular logs are observation is needed so that we do not have any kind of or not any suspicious activity going on in the cluster environment. We are we have to make sure that all the cluster information is all always up to date with the latest, uh, updates so that, uh, we're not not meeting missing out any security related, uh, aspects. Uh, next, again, uh, like, if there are any situations which happens, then immediately necessary steps, there should be a proper, uh, like, uh, steps to be defined. Like, if any unwanted activity or suspicious activity has taken place, what is the next, uh, level of action? So we should document that beforehand itself. We were creating a cluster so that if some situation occurs, uh, anytime, we will be prepared to take the necessary steps step by step and quickly, uh, make sure that the person or the, uh, like, the suspicious activity can be immediately identified by observing the logs and all. And immediately, it can be restricted. And once everything is cleared out, everything auditing and everything is cleared out, then we can spin up the server back to normal situation and, uh, carry on the activities. So these are the things that I can remember at the moment. Thank you.

Could you explain the process for running a live application, running a Tanzu Kubernetes with 0 downtime? Again, as I said, I'm not aware of the Tanzu Kubernetes environment. Never worked on that before. But, uh, in general, how to make sure that live application running on normal environment with 0 around time. So this can be achieved. So, uh, 2 things to be remembered is whether it is a a stateful application or a stateless application. If it's a stateful application, it needs it kind of where we it would be, like, the state of the application is very important. So it is example, uh, some of the example of stateful applications are, like, databases where the data has to be preserved. So for those case situations, we'll go with the stateful application. We'll try to create a stateful. But if at all, it's not a stateful application. It is like a web server or a app server. It's try just trying to prove like, it's trying to do an operation and just, uh, show it to us or maintain just logic of it. Doesn't have any data to be stored and preserved. So in those cases, we either go with deployment or as or horizontal port autoscaler. So when we take the horizontal port autoscaler and try to make sure, uh, that, uh, we deploy it, then definitely the server will be up and running. And if the more load comes up as it is a live application running, so as and when there is a more traffic coming up and there is need for it, automatically, it would be able to scale up, and it maintains that the traffic is properly served without any downtime to any of the application. So that can be maintained. And similar to the stateful setup situation also. So for for horizontal port autoscaler can be implemented. And, also, if there are any updates happening, the if there are any updates from RM. Even then using the rolling update concept, we would be able to patch new updates to the Kubernetes environment 1 after the other. All the services won't go down at the moment. Only 1 first port goes down. It tries to update the latest changes, and it starts running the it starts serving the traffic. Then there is second 1 that, uh, goes down again. It tries to update the latest changes, patches updates, and then it comes up, and third 1 goes down. So this process happens to the entire cluster, and all the ports will be, uh, going to the same process, and there would be 0 downtime for any of the, uh, customers who are trying to access the application. And moreover, there are, like, probes, the readiness probe and liveness probe, which also make sure that if at all the server is up and running or not. If it's up and running only, then it tries to provide the traffic. Or if it is whether it's ready or not to at least provide the traffic or serve the traffic, maintain it's verifying whether it's available or not. All these things can be done by the liveliness and the readiness probe, which we can configure using the YAML files. And, also, uh, if we want our node to like, each node or each, uh, minion would should have a 1 port running at any cost, then we can deploy it using the DaemonSet concept also. So there are multiple ways based on the type of application, like like of type of the live application that we are deploying and the kind of traffic that we can expect. Based on that, we can either take stateful set. We can go for daemon set. We can go with the deployment file, uh, and also for well, horizontal pod autoscaler. So these are the different ways in which we can, uh, like, deploy a live application running on a Kubernetes environment without that run downtime. Uh, that's all about my answer. Thank you.

What strategies would you employ to ensure your downtime deployment when transitioning from Tanzu to AKS? Again, same thing. Uh, I did not work on, uh, Tanzu environment, and I did not work on EKS. I worked on EKS environment, but that is very similar. That is 1 of AWS app, uh, service, and this is Azure service. The thing is, like, whenever we are trying to migrate anything, we make sure we, uh, like, we show that there is no downtime. So how can we do that? By going blue and, uh, blue green deployment strategy. So what we do is we try to configure everything, uh, like, on this, uh, existing crust cluster. So when we are trying to migrate here, we make sure that these services also have the same level of basic dependencies that are needed for running of this application. And then slowly, we migrate 1 after the other in the format of, like, 0%, 10%, 25, 50, 75, and 100. So incrementally, we try to push the changes. And both of them will be parallel at some time, like, when 10% traffic is there. 90% will be on the original 1, and 10% traffic is on the latest 1. So even if we find slight of the change, we roll bring back the services, and we try to serve with the old 1. But if it's everything is going on with 0%, 10%, 15 as we increment the number of traffic, uh, the amount of traffic moving to the increasing the amount of traffic that go into the latest, uh, server or the environment. And if it's going stable, we slowly continue the process in order to complete the transition and complete the whole process and even maintain this until this is up and running. And we just monitor for hours or days or, like, weeks based on the need based on the importance of the application. Even if the slightest change, we immediately roll back and bring back the services back to normal than the old 1. So we make sure that traffic is properly migrated. Load balancing is, um, properly, uh, measured and properly set in place so that blue green deployment strategy is very much successful, and the migration smoothly occurs without facing any downtime to the users. And as there is also an advantage of rolling updates, even, uh, like, 1 after the other, uh, ports would be migrating without any issue. Like, 1 is, uh, like, moved, turned up, ready to serve. Once the liveness probe ensure, uh, verifies that it is ready and, uh, readiness probe and liveness probe confirms, only then it starts, uh, updating it starts taking the traffic. Then the second 1 will be going in the process of going down, updating there. So this process completely completes smoothly without any issues when, uh, we, uh, configure the environment properly with the blue green type of deployment strategy. Yeah. Uh, that's my answer. Thank you.

What do you need to consider when creating a persistent volume claim in Cuemath? Okay. Uh, what do we consider, uh, when creating a persistent volume claim in Kubernetes? Okay. Persistent volume claim tries to take the amount of storage from the persistent volume. So first of all, persistent volume is amount of volume that is essential for the pause to run. And persistent volume claim is the amount of volume that we are taking from that reserved volume in order to make sure that our application runs very smoothly. So for the first consideration would be how much persistent volume do we have, and what are the applications that we want to run using that persistent volume? Based on that, how much volume that we would like to consider for this, uh, application? Sometimes applications goes out of control, like, where or if it's not responding or if it needs more volume, it tries to start pulling up the, uh, the volume. So for that reason, we should, like, provide a limit. So using the resources, uh, com or component, we would make sure that we update the proper requests and limits. So only requests are, like, the minimum amount of volume that is essential for that port to run. So, basically, that is by default to be provided, and limits are the maximum that a port can have. So when we define that limits of requests and limits within the resource section of that container or that, uh, personal volume claim, then it makes sure that only that much volume is utilized. And within that, it tries to run the application. And this consideration of how much request has to be updated, how much limits have to be updated are completely dependent on how much volume is already there, how much persistent volume is claimed, uh, like, how much persistent volume is available, and what are the different types of applications that we are trying to deploy using, uh, that available persistent volume. Based on that, we try to create the persistent volume with this request and limits concept. I think that's my answer from for this question. Thank you.

What are the benefits of using Helm charts in Kubernetes, and how would you manage dependencies in Helm charts? Yeah. Uh, Helm charts are like the package manager of Kubernetes. So similar to, like, for Windows, we have got Choco installed, and for a Mac, we've got Homebrew. For, uh, like, Linux, Debian based, we have got, uh, uh, like, app module. Uh, and for, like, uh, Red Hat based, we have got. So it's a package manager. Package manager make sure the latest level of package along with dependencies are properly available. So instead of manually installing 1 after the other application, uh, package manager make sure for running a 1 application, it has got all the different dependencies along with the, uh, main thing. So for example, in my organization, I have used helm controller to create the Prometheus and Grafana, uh, application. So if we, uh, in general, create a Prometheus and Grafana environment, we make sure that first we install their server. Based on that, we install the basic Linux environment. 1 environment always we install. Based on that, we would try to install a a Kubernet setup, and that Prometheus, uh, server, we could try to install. We separately separately install the Grafana software. Then, again, on Prometheus application, we try configure each and every node information. We try to query there, and we have to set up the communication between the Prometheus and Grafana application. We have to configure the Grafana environment. And then we have to make sure all all of them are, uh, having the proper, uh, uh, like, are they communicating or not? Are they at the same, uh, level of, uh, version or not? If because 1 above version or 1 below version won't, uh, help it out. We have to search in Google. We have to verify, read the official documentations in order to come up with the right versions that we have to use and then set up the environment. However, using the Helm chat, there are, like, artifact hub dot I o. We have got, like, in a bit name repository. They are very beautiful, um, like, the repository like, we have got a package for, um, So I've read that. I have just installed, like, installed the repository first in our cluster, update the repository, and then try to install the helm install. And that provision Grafana specific, uh, like, image. Based on that package manager information, it has got all the setup, and the dependencies already included in the environment. So once that is installed but the only thing is it is of like, we have to change the values as per our need. We have to modify the values dot yml file, and, uh, the it is not open for the outside application. So it is based out of cluster IP. So we have 2 patch, like, cube CTL patch command, SVC, and then, uh, mange making sure, like, the colon type there from cluster IP, we've modified 2 load balancer. Once that is done, the services would be open, and, uh, like, we would be able to run the, uh, Prometheus Grafana environment, and Grafana environment is already configured to communicate with Prometheus. So properly verifying which, uh, like, uh, theme or template that we would need to understand. So we will be going for Kubernetes. So when we select, it clearly shows the information about what are the different nodes available. Are there any ports that are restarting the number amount of time they are restarted? What are the different names that is available? Everything can be clearly monitored from there. So the main benefit of using the Helm charts in Kubernetes is to make sure all the files or if you want to install something there, everything, the dependencies, uh, then, uh, the applications, the versions, everything is preconfigured and provided in a specific package kind of environment. We just want to install it and ready to use it. But make sure as per your needs and your project needs, we have to modify the values dot yml and then deploy it to make sure you you use it properly. That's my answer for this help chart's benefit. Thank you.

Would you handle disaster recovery and backup strategies for stateful applications running on Kubernetes in Azure? See, 1 thing is, like, uh, stateful applications are very much important because it it holds the data. It holds the database or any database kind of an environment. So the data has to be preserved. So we make sure for the stateful applications, we make sure that it is properly having the right amount of persistent volume persistent volume change. So it has got the right amount of volume properly reserved for it to run. And we have to make sure the DaemonSet running on that is properly, uh, working because it has to capture the right, uh, uh, real time, uh, like, analysis and provide us if there is a small hinge of load also. It has to be immediately provided to us based on that. We can be, uh, prepared to, uh, create like, to prepare to, uh, make sure that we can add some kind of volume and protect that. And, also, we have to make sure that backup incremental backup has always has to happen on a regular and internal basis so that the data is always preserved. And if at all something goes, uh, down, unfortunately, even after our setup, we can immediately pull up the information for the backup data's backup, and we can bring that service as normal as quickly as possible. And we also have to make sure, uh, that, uh, uh, like, in the Kubernetes environment, uh, like, backup has to be properly updated. Uh, application has to, uh, have on yes. The application should be properly deployed in a separate node, not on any other. So we can use the tint and toleration concept. So we can deploy this, uh, application on 1 of the server on a specific node. And after that, we can tint it. So no other port can be created on that applicate on that mode, especially for the net database. So, uh, and only if you're creating the database, you can use a toleration concept to create the the, like, report on that particular node. So it make sure that node is specifically, uh, dedicated for this, uh, this stateful application. And it, uh, like, uh, it, uh, make sure that there is no unwanted clutter from other ports disturbing the main database. Having, uh, a dedicated node, having proper, uh, like, uh, making sure that, uh, proper regularly we provide by incremental backups, making sure there is a right amount of volume, acquisition volume available for this particular application, or the stateful cell stateful state application. So on the note, make sure that we are foolproof to have, uh, making sure we have the proper, uh, application on a stable base. But if even if there is something happens using the backup, we can bring back the services on a better note, and, uh, we can get back the services as quickly as possible. These are some of the things that I have used in my previous org. That's all. Thank you.

The advantages of implementing a service mesh in a Kubernetes environment. And the consideration of choosing 1. Service mesh, I'm not sure. I'm I'm, like, I'm not a service mesh, but I've used a service object files like that node. In that, we have mentioned node port, load balancer, class tripe, and, and also we have used, headless service. So the main purpose is, like, the default 1 which comes up is the cluster IP. And note port and load balancer, we use when we want to have the the port communicate with the outside well, out of the QMaths environment. So for that, we use node port and load balancer. But for internal applications to communicate with each other, then we do not, encourage, load balancing, but we'll go with the default 1 as cluster ID. And for stateful applications, like, where database is kind of

How do you approach performance testing for deployments? In given a chance, how does it influence capacity planning? Now do you approach performance testing? Deployments. Okay. How does it influence the test deployment? Okay. So, basically, uh, performance testing can be done using different testers like j tester, uh, load tester. So these different applications, uh, add significant amount of load on the deployed application. It makes and it verifies how strong the application can withstand, how much load it can it withstand. So coming to Kubernetes point of view, we tries to, uh, create a horizontal port auto scaler, And we also have, um, request and limits concept that we define based on the persistent volume that we have defined for the cluster. So based on the limits, when we apply that applicate apply that particular load on the, uh, different port, it tries to verify whether is it trying to go even above the limit that we have mentioned. So is it within that application, or is it going within out of that reach? If it's going, then we try to again improve it and again verify. Again, try to apply the JMeter or, uh, like, uh, apply the load from the JMeter or load tester and all. Again, we see whether it's coming or going within that request and limit range that we have defined for the persistent volumes or persistent volume. So if it's going, then fine. If it's not going, then how much volume how much more is needed? And we try to keep different use cases from different like, 1 application trying to, uh, speak with 1 at 1 port. The other service is trying to add load. Other application is trying to access the database. So in that way, we try to create different environments trying to access, uh, trying to access through the Kubernetes cluster at the same time. Continuously load has been provided and verify whether the limits, uh, request and limits that we have provided and the horizontal port autoscaler, whether it's able to scale up to that necessary need or not. If it's, uh, if it's going to, uh, like, even it's scaling, and is it able to serve the right traffic without downtime or not? If it's yes, then our service is working fine. But if it's going down or it's not able to give the efficient way of providing the traffic, and if it's going down or giving us slow responses, we try to improve the more amount of limit so that as we know, request and limit are the the 2, uh, like, thresholds that we define. Like, request is a minimum amount of persistent volume that we have to provide to the, uh, pod, and limit is what it cannot extend. So maintaining that request and limit concept, we would be making sure when the load is added, whether our application is able to properly for horizontally or, like, auto scale and provide application support or not. If it's able to, it's fine. But if it is not, then we try to improve it up. And, also, we try to segregate it very properly with the namespaces, each application a different namespace so that properly limits can be applied. And the main application or the main deployment is properly having the necessary resources in order to make sure it doesn't go down. And, also, it tries, uh, it tries to provide the output of the application without any downtime or delay or any lagging. So these are all we monitor. And, again, if it's a database, we go with stateful set. And if it is, uh, applications, we go for deployment or horizontal and sometimes daemon set as well. Based on the requirement, we go with different types of applications, And we use, again, uh, JMeter load tester to add load. And based on that, we try to verify the testing on the deployment environment in the Kubernetes. That's all my answer. Thank you.