Komirisetty Nageswara Rao

I'm. I have built 5 years of experience in DevOps. Our current multiple technologies and multiple projects. The main skill set is the containerization. And expecting Kubernetes and Docker. also working on multi cloud environments, Databricks, Azure, Google Cloud. Yeah. This is a high level introduction. Present, I worked with the BNC company.

Yeah. Connect to that CICD pipeline. Anyway, the basic steps are there to involve. One is first, we need to build up a source code. To building the source code, that is a dependency, which depends on the programming language. Like, for example, a coding language. Which libraries they selected, dotnet, or Java, Python. So, in present projects, we are using dotnet. So to build that, first, you can take any CICD tool like Jenkins, TeamCity, and GitHub actions or anything. First, we need to use the interpreter as dotnet. And in the interpreter, we can find the command, like a builder. There's a command line. Our pipeline probably has the one you want to use. For example, dotnetcli version. Then you can pass the inputs like, so what is our target? The file solution or file name. Like that. So first, we need to build. After building, then we need to pass the testing phases, like unit test, module test. You can run the unit test and module test phases. Once it's complete, the unit test is passed and module test has passed, now the containerization started. Now, let's containerize our application. We're coming to the containerization first. We can create one Docker image from our source code. So then we can upload it to a private container registry like ACR or any JFrog Artifactory. So we can integrate it with the pipeline. After uploading, now the actual deployment to Kubernetes will start. So, to deploy to Kubernetes, we can use the modules. For example, if we take Azure DevOps, we will request some service connection to authorize to the Kubernetes cluster. So, first, we will use the service connection to authorize to that cluster. After that, we can provide the deployment. Like, which YAML files you want to deploy, we can filter those YAML files and the locations so that all will deploy. That is the higher-level way. Okay. If you're not comfortable with the modules, we can go to the script, our old script. So we can use the kubectl or in the higher level. If our package is very complex, we can also use the Helm. By using the Helm chart, we can directly use kubectl commands to deploy into Kubernetes. After once, we can deploy into any kind of cluster. Maybe there is a kops, rkv, any kind of cluster, we can deploy. Once it is deployed, you can go and validate, like, all our configuration is coming or not. And if it's a branch, the model is, the BRAV manifestor files are branch to any different kinds, like replica search. So, in that situation, we need to restart, world parts, then the new effect will come. If you take the model as a deployment, the direct push to type is the deployment, then we don't need to restart. Then, automatically, the effects, the changes will affect. So, it's a general CSC deploy, including the Kubernetes. So, based on our exact document, we can change our flows and workflows like, the number of stages in each stage, how many steps you want to include and conditions. And after that, in the approvals, everything we can include in this pipeline.

Yeah. To exposing a Kubernetes service to the Internet, we have different options. One is the load balancer. First, at the higher level is the ingress controller. So there is a NGINX ingress controller or Istio ingress controller. Then that will take care of the exposed. So, actually, the ingress controller comes with an application load balancer, and this application load balancer will communicate with the worker nodes. And our Kubernetes cluster worker nodes throughout the application load balancer, we can communicate. And then mainly the definition, we need to mention the ingress. Like, if the particular host, the host coming from which background, like, which backend services we need to redirect. So there is a higher-level advanced setting like ingress. And okay. If it's an individual object, so, like, all single services, we don't need to go directly to the ingress level. We can simply open one load balancer. If you say we need to connect to the Internet, we can open a public load balancer. The service type actually has different types of services. Node port service and, after that, load balancer service and the cluster IP service. So, if we choose our cluster IP service and send the public IP, then we can easily access our applications from outside the world. Okay. If our worker nodes are assigned to the public IPs, then we can also use the node port. So node port types are these. But the best-recommended way is to go with the ingress. So then, it will handle hundreds of applications very easily, routing requests and where we need to go, which request is coming. All these things we can handle very easily through the ingress. If it's an individual application, we can go to any one of the methods like a load balancer service, a load balancer service, or sometimes for testing purposes, we can also make one export. That way, we can export the product, and we can also test when we are exporting, then, yeah, it will access the public Internet.

Yeah. In coming to scaling policies, we have different types of scalings like HPA, VPA, and there is a node level and port level. Coming to this question, this is a port level. So horizontal port auto scaling, HPA. I'm coming to this. If any particular application is taking more load at a particular time, we don't need to go and adjust the number of replicas in that time. So, we can create 1 HPA. So, HPA can be created based on the target metrics, like CPU utilization, memory utilization. For example, we take memory utilization. In normal hours, 2 replicas are enough to balance the complete load. But even if more customers increase, we require more resources, like more memory and more CPU. In this case, just the target metric is memory. So, I make the memory utilization percentage. For example, if I make it 70%, the memory utilization is 70%. If the load is increased to balance the target value, then automatically it will increase the number of replicas based on our minimum and maximum values. For example, I put 2 replicas. In normal hours, 2 is enough. In peak hours, if the memory resource is not sufficient, then automatically it will launch more replicas, like 3, 4, 5. To maintain the target value, it will launch, scale, and automatically scale out. Okay. If there is no load, then again it will decrease. Simply, it's a kind of load balancing in the pod level HPA.

Coming to zero downtime. Actually, the Kubernetes view already views this beautiful feature. So when we make changes to any application, then it will automatically follow our strategy, like a rolling update percentage. For example, we have an application with 3 ports. So, 3 ports are updated at a time without destroying any of them. Here, simply migrating means we first need to delete and recreate in the ender worker node in the ender cluster. So, in this case, if you follow the updating strategy, first, it will create only 1, then it will terminate 1 port. If it's successfully terminated and recreated, then only it will go to the next port. So, in this case, the remaining parts are always available. For example, in the case of 3 customers, 2 parts are available. The 2 parts will send the request. There is no downtime, zero downtime. Simply, we can call this the deployment. There's a feature provided by Kubernetes only. So, there's no downtime here in this case by following this update strategy.

Yeah. Yeah. We are coming to the infrastructure and mainly especially Kubernetes infrastructure means first, we need to create a number of master nodes. And as it's always better, we can go for high availability. So, we need more number of control plane nodes. Based on the rules, we are always choosing a hard number of nodes, like 3 nodes or 5 nodes. So first, we can take the control plane nodes we need to launch. And after launching the control plane nodes, we come to this kind of clusters. If it's an AKS, we don't need to worry about all these things. So once we launch the AKS cluster, at that time, it will do all the options, like a Kubernetes version and worker node information, how many worker nodes we require, what is the size of worker nodes, and this, and the CNI plug-in, which set of plug-ins we need to use for networking. So all these on-site ranges, everything, we can configure very easily. Okay. If we come to on-premises, that is a little bit difficult. First, we need to create master nodes and after, some tools like Kubernetes, kubectl. So, the main fundamental components are there. With the help of the kubeadm tool, we can form the cluster. We need to choose our number of nodes. Like, some of the nodes are part of the control plane nodes, some of the nodes are part of the workers. Then after, we can join. And here also, VNet and CNI plug-ins. Like, maybe it's a VNet CNI or Azure CNI. We can configure everything, and we can form the cluster. So, these all processes we can do using the Terraform. So, in the case of, especially for cloud, AWS, Azure, Google Cloud, if you want to provision the clusters in their infrastructure, we know, we can go manually to open the portal under here by using the UI. From the UI, we can select the option for provisioning. There is no need to worry. From the script, a simple Terraform script, we can create all these resources. In the Terraform, we will mention, based on the other. The first other is, first, we need to create the Kubernetes cluster. And after once, the creation of the cluster, the properties is the cluster properties. So, in these properties, we can mention all these we may need plug-ins inside the ranges, a number of our proposed, everything. Once the cluster is created, if you want to integrate this cluster to any other resources, then next thing, you can add, the integration details like your container registry. If you want to integrate our AKS cluster to ASR, then we can add one more resource integration in the Terraform also. Everything, the infrastructure as a code, everything we can then, using the Terraform, for including Kubernetes setup also.

Yeah. Coming to the far life cycle, for it has, definitely, it has a number of life cycles. The first is the initializing mode. First, the part is the need to come into the initialization. Before that, there's a pending stage. Okay. The first process is, the parties need to allocate with us, the particular local node based on the health checks and condition, everything. So if it's still not able to assign to any worker node, that condition, simply that state, we can call as a pending state. Once it's allocated to the worker node, then after, so here, again, a number of different stages is there. Okay. If it is the first process, the initialization is the first process. Once that is the initialization stage. Once the initialization is completed, everything, going to the smooth, then it will still come into the running state. Or if any errors occur, then it will come into the cache loop backup state. Then the cache loop backup state is a different reason. Maybe, like, our resources are not sufficient, after locating, and maybe any errors are there in our application. So, it will enter the crash loop back up state. So, the pending state, initialization, crash loop back up state, and a running state, and if you see it's a job, then one more stage also called completed state. Also, completed state. Finally, it's a terminating state. So these are the Kubernetes state life cycle. It will follow another policy mainly the restart policy. Based on our restart policy, I'll say it will behave like this. Like, the default restart policy is always. So if it's anything has happened, automatically, it will restart. Or if we mention only failure, look, if something has happened, that time only, it will restart the port. Like that, these are the pod life cycle policies, and we can also control using some probes, like a liveness probe, readiness probe, so and startup probe. So, if you want to take the particular action, like, if you want to restart the pod, when the pod is, an example, you want to execute the particular operation when, that will execute only, the part is, running simply live in this probe. So we can execute that condition. Like, we can also apply these probes in this part life cycle. Based on these probes, it will act. So mainly, these are the main things, the life cycle stages, the simple creation, the container creation and termination process.

Yes. Yeah. Come to the stateful set application, mainly for stateful set applications, we will use some database applications, like, to maintain persistency. And when it comes to disaster recovery and backup, disaster recovery means simply maintaining backups. So here, we are creating a persistent volume. For example, if you take any one of the database, like RavanDB. In RavanDB, all data is stored in the RavanDB server. Okay. If you store data in the internal space, internal space means the node space, there is no actual space for this. Then automatically, if the pod is deleted, we will automatically lose the entire thing. Or if the cluster is affected, we will also lose the entire thing. But if you maintain external persistent volumes, under the main thing is a storage class retention policy, the retention policy. The retention policy, we need to retain. So if we make retention policies retained, even if the cluster is completely crashed, it's not affected that the persistent volume, like, throughout the storage class. Maybe in Azure, we can take the Azure disk, or Azure file systems. In this Azure disk, even if we deleted or crashed our complete cluster, that volume won't be delayed because the volume client policies are retained. That is one case. And here, what exists. But in worst cases, maybe our user resources are also deleted. So in that case, we can also enable one more backup option, like snapshots. Taking a snapshot from that particular resource and maintaining it in a different region. And here, we can also maintain geo replication. Geo replication is also suitable for this. So, for example, if we have RavanDB. We will maintain multiple replicas for RavanDB, and the RavanDB database, simply our stateful set application. So here, one part of the replicas are in one region and the other part are in the replicas in the other region. Okay. If this region is affected, then we can recover from the other region. So that is one method. And backup, snapshot, and restore, that is the end of the method. And, here, Kubernetes also, and it means our persistent volumes retention policy option is also helpful for backing up applications. And, this is for a single application. But coming to the cluster, we have very good features for the cluster also, like etcd backups. Etcd backups and restore. Okay. If you take the regular, there are different types of etcd backups, full backups and incremental backups. If you take the full backup and incremental backup that our etcd cluster regularly, even if everything is crashed, the cluster. Also, we can retrieve. The etcd backups will help the Kubernetes object. The real data will store it on the persistent volume. So with the help of this etcd backups, our database backups, even if it's 100% crushed, we can easily recover.

Yeah, I'm coming to log in. I'm logging into the architecture. And, so we are using our Kubernetes cluster. If we use any issue, any crowd-provided Kubernetes cluster, like EKS, then we can go to the logging system they provide. For example, if you take EKS or AKS, their logging system is the Azure monitor. The Azure monitor enables the application container in size. When we enable the container insight, then you can completely monitor our logs and metrics and everything. So, that is provided by Zoom. So, internally, if our cluster or anything is affected, we can check the history of the logs and everything because it's outside of our cluster. So, that is one thing. And okay. If it is our on-premises thing, then in this case also, we can use our own tools like Prometheus. Prometheus is a very best tool, it will provide more numbers of metrics, more than all tools. So, but, okay. Prometheus for metrics. And if you can also configure Loki. Loki is for only log monitoring. It helps us with the help of this Loki, Grafana. We can provide our own system and some more log monitoring things also, the ELK. ELK starts. And yeah. Coming to this is all of our internal things and user-provided things. You can also use the external services like Dynatrace. Dynatrace also will provide very good information. In the present project, we are using the Dynatrace. It will provide all metrics very detailed. So, there is also good logging architecture. And coming to previous projects, I implemented these things, Prometheus, Grafana, Loki. So, that is also probably very detailed information. And, in Azure also, we can and, I and AWS also, we can enable the container insights, and we can directly own the cloud-provided systems. So, better the which one is better means based on our targeted cluster. Like, where our cluster is there and how we will configure. Based on that, we can definitely choose one goal amount to reduce, which will help to completely logging the information like node metrics. Any problems are there, no. We can cover the node metrics and node logs. And, we can make a product application center, cluster level, application level. We can cover always. And here and coming to debugging section, yeah, we can easily debug. If it's on-premises, we can also debug the control plane. The key point of Kubernetes is the debugging these system applications. In the cube system namespace, some of the critical applications are there, like core DNS, and after that, daemon sets. And, so, the applications within this cube proxy, within the cube system namespace, that are belong to the system critical applications. With the help of that, we can easily debug very challenging applications also in the Kubernetes.

I'm coming to sensitive information. The Kubernetes already provides the full feature, secrets. There is a call as a secret. So we can put our all sensitive information in the form of a secret. The secret is an encrypted format. The information is stored in an encrypted format. So it's completely secured, and we can easily integrate it to our applications from secrets. We can easily access our sensitive information from the secret, and we will also maintain it very securely using secrets. That is, the Kubernetes world provides this thing, secrets. And coming to actionable tools. The actionable tools also exist, like vault, key vault. So we can also maintain our sensitive information in key vault, and we can integrate key vault to our Kubernetes applications. Now, that is also an actionable service to make sensitive information secret. And the default inbuilt feature is the secret object in Kubernetes. And, yes, that is one of the two things. We can also come into security, image security, like Docker image security, which we can provide using private registries and JFrog registries. Yes. The best thing is secrets, and Kubernetes provides secrets. Yes. The external service is, we can go to vault, key vault. And yeah. If in the CICD pipeline, if we go, we will manage it from the CNE pipeline. Here also, there is a section, the credential section. In this credential section, we can store our data. That is also in entry format only.