Akhil shaganti

I have total 6.5 years of experience working in the IT industry. Out of which, the last 4 years, I'm working as a DevOps engineer here. So the past 2 years, I worked for a company called Milestone Technologies, where I worked for 2 different clients. And currently, I'm supporting the Moët company, Moët Technologies, and I'm supporting the Google client. So I work primarily with all the DevOps tools. So I got an opportunity to work as a build release engineer along with the main infrastructure and troubleshooting and monitoring purposes. So as part of my experience, I have the privilege of working with the tools like Jenkins for CICD operations, Git and GitHub for source code management. Then I've used Ansible for making sure the configuration management is taking place properly. And our servers are based out of a well-known AWS cloud environment. So it's based out of the North Virginia region. So I used Ansible to make sure to automate things to create software, to create users, and maintain configuration management for all those servers. And I also used Terraform extensively to build up the infrastructure, meeting the state of the application, even in 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 migrating some traditional applications towards the Kubernetes environment and making sure reducing cost 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 using Python, I have created an auto-scaling thing in Docker because Docker doesn't support auto-scaling by default. So with using Python, I was able to create the auto-scaling feature in Python using Python and Docker. So that is one use case. And I have experience monitoring from this in a Grafana dashboard. So these are the different tool sets that I've worked in my experience. And currently, I'm supporting the Google project, and I'm currently the main POC for a project where we are using Terraform. And there are some internal tools of Google, like something called Rapid, which is exactly an alternative to the tools that we use in the outside market, like Jenkins. So Rapid is exactly an alternative to Jenkins. So I'm trying to automate Jenkins along with Terraform in order to bring up a new tool called Irvin. So the main intention is 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 state. So why can't we have an application where if we write the code, it creates the application, it creates the infrastructure, and also creates the CICD operation all at once. So that is the intention of our tool. So I'm currently working on that, trying to automate the Rapid tool along with Terraform using remote backends and module concepts 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, 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 Kubernetes. We have got node port, load balancer, headless, and cluster IP. So out of this, which one would be suitable for our use case? So if at all we are trying to build communication with bots outside, but if you want to send traffic in and out of the cluster to have public-facing servers to communicate with them, then we should be using something like node port or load balancer. But if you want applications to internally talk with each other, then cluster IP is more than sufficient. And if you are using 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 a stateful setting. Headless is sufficient. And 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 setup like Azure Kubernetes, AKS or EKS or GKE, Google 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 in order to maintain the load balancing. We can use that IP address generated by the managed Kubernetes setup. That IP address can be used, and that itself is sufficient to route traffic to the necessary port. These ports would be interacting with each other based on the service definition file that we have written, and it tries to check which service definition file has to go. And from there, it tries to see which node selector terms select our match label. Based on that, it tries to go and verify that and tell it to traffic. And in between, we have the ingress controller with having the information about path-based routing or host-based routing. So in that way, setting up the steps in a proper way, identifying which type of service object we need may place a very important role. Only then, if we have a proper ingress controller written with path-based or host-based routing along with the right service object dimension, like load balancer or node port. And then mentioning the node selector terms correctly in the manifest file of the service object, make sure the right traffic in and out can be transferred without any issues. So these are the few things I very keenly observe and consider before I am trying to set up any network policies in the Kubernetes microservice service architecture. That's my answer.

I'm really sorry. I have never had an experience or did not get any opportunity to work on the Kubernetes grid. But, if I have to speak about how Kubernetes tries to have the important components and how they interact. I would say the main important components would be, first of all, on the main cluster master, we would have a container runtime. We have a kube API server. We have a managed controller. We have a managed controller and the kube scheduler and HCD. The main purpose of HCD is to have a key-value based database, which stores information about the right different nodes, different what all ports deployed on different environments. Everything is maintained. It has a key-value kind of database, also known as key-value based storage. Replication, like a managed controller or manager, and like the kube controller. The kube controller and the kube scheduler. They make sure the kube 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 any that are down? If it is down, immediately turn it up. That is its purpose. So it always verifies the HCD and tries to work on that. And the kube scheduler's main purpose is to verify where exactly there is more space where a node which node can accommodate another port. So based on that, it tries to schedule the like the ports on that thing. And the kube API server is the first thing which verifies whether they need a Kube SQL command that has run, 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 the container runtime is, of course, its docker, basically, so which provides the containerization platform. And on the 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 kube, configure the kube 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 provides the traffic, so it integrates, makes sure that the service object is properly communicating with the port. So it makes sure that the ports of the same architecture are placed nearby, on based on nearby nodes or on single nodes so that communication happens more smoothly and the service object is properly able to communicate with the port that is created. That's the main purpose of the kube proxy. It is a real-time thing that makes sure traffic in and out is transferring to the port to the outside world and vice versa. So these are the different 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. Of course, 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 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 be implemented in a Kubernetes cluster to prevent unauthorized access. First of all, the main thing is having the right level of access. So, whenever in Kubernetes, we set up an environment, we have to make sure the security groups only allow traffic from the node's sources that need to communicate. We should open ports only for those applications, not for everything. This is the first level of security. Only known traffic from the node's sources will be coming to our cluster. The second thing is ensuring the right level of permission is given to each person. We should not give all QCL commands to everyone. Instead, we should provide modular permissions. For example, our developer would have a specific set of confirmations, and the main admin would have specific commands. A space-specific level of permission is given to run only a few commands. If we define which level of permission is given to each person, the level of security can be definitely improved. Regular monitoring and regular log observation are also needed to prevent any suspicious activity in the cluster environment. We must ensure that all cluster information is always up to date with the latest updates so that we're not missing any security-related aspects. Next, if there are any situations that occur, we should immediately take necessary steps. We should define proper steps beforehand, such as what to do if any unwanted or suspicious activity takes place. If some situation occurs, we will be prepared to take the necessary steps and quickly identify the person or suspicious activity by observing the logs and then restrict it. Once everything is cleared out, we can spin up the server back to normal and carry on the activities.

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. However, in general, how to make sure that a live application running on a normal environment with 0 downtime can be achieved. So, two things to be remembered are whether it's a stateful application or a stateless application. If it's a stateful application, its state is very important. For example, some examples of stateful applications are databases where the data has to be preserved. For those cases, we'll go with a stateful application. But if it's not a stateful application, it's like a web server or an app server that just tries to perform an operation and show it to us or maintain its logic without any data to be stored and preserved. So in those cases, we either go with a deployment or a horizontal port autoscaler. When we take the horizontal port autoscaler and deploy it, the server will be up and running. And if more load comes up as it's a live application running, as and when there is more traffic coming up and there is a need for it would automatically scale up, and it would maintain that the traffic is properly served without any downtime to any of the application. Similar to the stateful setup situation, horizontal port autoscaler can also be implemented. Also, if there are any updates happening, even then using the rolling update concept, we would be able to patch new updates to the Kubernetes environment one after the other. All the services won't go down at the moment. Only one port goes down, it tries to update the latest changes, and it starts serving the traffic. Then there is the second one that goes down again, it tries to update the latest changes, patches updates, and then it comes up, and the third one goes down. This process happens to the entire cluster, and all the ports will be going to the same process, and there would be 0 downtime for any of the customers who are trying to access the application. Moreover, there are 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's ready or not to at least provide the traffic or serve the traffic, it's verifying whether it's available or not. All these things can be done by the liveness and readiness probe, which we can configure using the YAML files. Also, if we want our node to have one port running at any cost, then we can deploy it using the DaemonSet concept. So, there are multiple ways based on the type of application, like the 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 a stateful set, we can go for a daemon set, we can go with the deployment file, and also for a horizontal pod autoscaler.

What strategies would you employ to ensure your downtime deployment when transitioning from Tanzu to AKS? Again, same thing. I did not work on Tanzu environment, and I did not work on EKS. I worked on EKS environment, but that is very similar. That is one of AWS apps, and this is Azure service. The thing is, like, whenever we are trying to migrate anything, we make sure we show that there is no downtime. So how can we do that? By going blue and green deployment strategy. So what we do is we try to configure everything on this existing 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 one after the other in the format of 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 one, and 10% traffic is on the latest one. So even if we find a slight issue with the change, we roll back the services, and we try to serve with the old one. But if everything is going smoothly with 0%, 10%, 15% as we increment the number of traffic, the amount of traffic moving to the latest server or the environment increases. And if it's stable, we slowly continue the process to complete the transition and complete the whole process, even maintaining this until it's up and running. We just monitor for hours or days or weeks based on the need based on the importance of the application. Even if there's a slightest change, we immediately roll back and bring back the services back to normal than the old one. So we make sure that traffic is properly migrated. Load balancing is properly measured and properly set in place so that the 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 one after the other, ports would be migrating without any issue. One is moved, turned up, ready to serve. Once the liveness probe verifies that it is ready and the readiness probe and liveness probe confirm, only then it starts updating, and it starts taking the traffic. Then the second one will be going in the process of going down, updating there. So this process completely completes smoothly without any issues when we configure the environment properly with the blue green type of deployment strategy. Yeah. That's my answer. Thank you.

What do you need to consider when creating a persistent volume claim in Kubernetes? Okay. What do we consider when creating a persistent volume claim in Kubernetes? Okay. A persistent volume claim tries to take the amount of storage from the persistent volume. So first of all, a persistent volume is the amount of volume that is essential for the pod to run. And a 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 application? Sometimes applications go out of control, like, where or if it's not responding or if it needs more volume, it tries to start pulling up the volume. So for that reason, we should provide a limit. So using the resources, we would make sure that we update the proper requests and limits. So requests are the minimum amount of volume that is essential for the pod to run. That is the default to be provided, and limits are the maximum that a pod can have. When we define requests and limits within the resource section of that container or that persistent 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, like, how much persistent volume is available, and what are the different types of applications that we are trying to deploy using that available persistent volume. Based on that, we try to create the persistent volume with this requests and limits concept.

Helm charts are like the package manager of Kubernetes. So similar to for Windows, we have got Choco installed, and for a Mac, we've got Homebrew. For Linux, Debian based, we have got apt module. And for Red Hat based, we have got yum. It's a package manager that makes sure the latest level of package along with dependencies are properly available. Instead of manually installing one application after the other, a package manager makes sure for running one application, it has got all the different dependencies along with the main thing. For example, in my organization, I have used helm controller to create the Prometheus and Grafana application. When we create a Prometheus and Grafana environment, we make sure that first we install their server. Based on that, we install the basic Linux environment. Then we install a Kubernet setup, and that Prometheus server, we could try to install. We separately install the Grafana software. Then, on the Prometheus application, we try to 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 of them are having the proper, like, are they communicating or not? Are they at the same level of version or not? If because one above version or one below version won't help it out, we have to search in Google. We have to verify, read the official documentation in order to come up with the right versions that we have to use and then set up the environment. However, using the Helm chart, there are artifact hub.io. We have got a bit name repository. They are very beautiful repositories, like, we have got a package for, so I've read that. I have just installed the repository first in our cluster, updated the repository, and then tried to install the helm install. And that provides Grafana specific, 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, we have to change the values as per our need. We have to modify the values.yml file, and it is not open for the outside application. So it is based out of cluster IP. We have to patch, like, cube CTL patch command, SVC, and then manage making sure, like, the colon type there from cluster IP, we've modified to load balancer. Once that is done, the services would be open, and we would be able to run the Prometheus Grafana environment. The Grafana environment is already configured to communicate with Prometheus. So properly verifying which, like, 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. 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, then 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.yml and then deploy it to make sure you use it properly. That's my answer for this Helm chart's benefit. Thank you.

Would you handle disaster recovery and backup strategies for stateful applications running on Kubernetes in Azure? Yes, I would handle disaster recovery and backup strategies for stateful applications running on Kubernetes in Azure. One thing is, stateful applications are very much important because they hold the data. They hold the database or any database kind of an environment. So the data has to be preserved. So for stateful applications, we make sure it has the right amount of persistent volume and the persistent volume is properly configured. 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 working because it has to capture the right real-time analysis and provide us if there is a small increase in load also. It has to be immediately provided to us based on that. We can be prepared to create additional volume and protect that. And we also have to make sure that backup incremental backups always happen on a regular and internal basis so that the data is always preserved. And if something goes down, unfortunately, even after our setup, we can immediately pull up the information for the backup data and we can bring that service back as quickly as possible. And we also have to make sure that in the Kubernetes environment, backups have to be properly updated. The application has to have a proper deployment in a separate node, not on any other. So we can use the taint and toleration concept. So we can deploy this application on one of the servers on a specific node. And after that, we can taint it. So no other pod can be created on that node, especially for the net database. And only if you're creating the database, you can use a toleration concept to create the report on that particular node. This makes sure that node is specifically dedicated for this stateful application. And it makes sure that there is no unwanted clutter from other pods disturbing the main database. Having a dedicated node, having proper regular incremental backups, making sure there is a right amount of volume available for this particular application, or the stateful application. So, in a nutshell, make sure that we are foolproof to have the proper application on a stable base. But if even if there is something that happens using the backup, we can bring back the services on a better note, and we can get back the services as quickly as possible. These are some of the things that I have used in my previous organization. That's all. Thank you.

The advantages of implementing a service mesh in a Kubernetes environment. And the consideration of choosing a service mesh, I'm not sure. I'm not a service mesh expert, but I've used service objects like that in a node. In that, we have mentioned node port, load balancer, and cluster IP, and also we have used headless services. So the main purpose is that the default one which comes up is the cluster IP. And node port and load balancer, we use when we want to have the port communicate with the outside world, out of the Kubernetes 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 one as cluster IP. And for stateful applications, like where a database is kind of

How do you approach performance testing for deployments? Given a chance, how does it influence capacity planning? Now, do you approach performance testing for deployments? Okay. How does it influence the test deployment? Okay. So, basically, performance testing can be done using different testers like JMeter, load tester. So, these different applications add a significant amount of load on the deployed application, making it verify how strong the application can withstand, how much load it can withstand. So, coming to the Kubernetes point of view, we try to create a horizontal port auto scaler, and we also have request and limits concepts that we define based on the persistent volume that we have defined for the cluster. So, based on the limits, when we apply that particular load on the different port, it tries to verify whether it's trying to go even above the limit that we have mentioned. So, is it within that application, or is it going out of that reach? If it's going out, then we try to again improve it and again verify. Again, we try to apply the JMeter or like apply the load from the JMeter or load tester and all. Again, we see whether it's coming within that request and limit range that we have defined for the persistent volumes or persistent volume. So, if it's going out, then fine. If it's not going out, then how much volume is needed? And we try to keep different use cases from different like one application trying to speak with one at one port. The other service is trying to add load. Other applications are trying to access the database. So, in that way, we try to create different environments trying to access through the Kubernetes cluster at the same time. Continuously load has been provided, and we verify whether the limits, 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 able to scale, 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 giving us slow responses, we try to improve the more amount of limit so that as we know, request and limit are the two thresholds that we define. Like, request is a minimum amount of persistent volume that we have to provide to the pod, and limit is what it cannot exceed. So, maintaining that request and limit concept, we would be making sure when the load is added, whether our application is able to properly 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. And also, we try to segregate it very properly with the namespaces, each application in a different namespace so that proper 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 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's 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 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.