 Hey everyone, this is Ohm and happy to share that I am speaking at Open Source Summit Latin America 2022 about the Kubernetes operators and how it is used for the deployment and management of the application in container con. Let's have some small intro about me. I am Ohm from India a software engineer at JFraw from RND team. I am also certified Kubernetes administrator and I am core contributor and member of CNCF incubating project Litmus Cures. I am a sporty guy, I am an international related chess player, so feel free to ping me for chess after this talk. When I don't contribute in Open Source, I work for the JFraw and I am happy to share that one of 10 from attendees have a chance to grab the JFraw t-shirt. So scan this QR code and register yourselves and winners will be contacted through email post event. So let's come back to our talk. Let's think about the era, how era is changing, how we used to install our applications, how we used to deploy our applications in earlier era when physical servers was there and now how we are deploying our applications in today's era in containerized form. So we have changed a lot, right? So earlier days like physical servers then we came to VMs, now we have containerized. So let's talk more about this. Are you ready? Let's fasten your seat belts and let's come. So what are the containers basically? Container is a unit where we package our code and all dependencies for our code and we keep it or we push it to some registry. So it's more on the unit where we keep all our required files to run our application and there are platforms also like Docker which is used for the shipping and running our applications. So we have containers now, we have platforms to run it, to ship it. Now let's talk about more like to next thing which is orchestration. What is orchestration? Our container orchestration is automation of much of the operational efforts required to run our containerized workloads and services. It's more on the automation configuration on top of the containers. So we can see there are n number of tools we have now like Kubernetes which is a core CNC graduate project. We have also the Docker swarm, mesos and many others. So Kubernetes, everyone is aware of the Kubernetes and it's one of the booming topic like it's one of the booming technology in today's era. So let's talk more about it and like next thing. So let's see this picture. What do you think from this? There are a few hands, there is a ship, there is a crane and small boxes like we can call it as containers, right? So they are arranging that containers, they're putting it in some crane and crane is shipping it to big ship and ship is moving around. So let's think like in Kubernetes where now Kubernetes boxes they get as a containers that crane is like scheduler, ship can be, we can think of the nodes now. And it's more on like application installation, right? The way that the containers are orchestrated like the configured and how the flow is going on is it sounds good, right? So taking one step next that how Kubernetes create or modify our instances of the boards that holds the standardized application, it holding and taking it to next thing. So there are many ways to do this, to make it install, to make it modify. So for that we can have some manifest where we can pass this actual configuration metadata specs for this application. So there are a couple of ways through which pass or we can install to make it install. So earlier days, let's think about that. Yeah, earlier we used to have some YAML file, right? Even if we can see some we have now also we have the YAML files which we we add some specs, some configurations in that like board spec or deployment spec or stateful set spec. We add that and we just apply it or we created that and once it get applied it creates some resources like boards or deployment stateful set, right? So this is one way to install this. If someone says that I have a simple application with one port, one service or some with some volumes and all. So yeah, it's very easy and very straightforward to use the YAML files to install that application. Now someone says that I need some customization on that. I need some manifest on the top of that so that I can patch that configuration into single YAML and it can be get installed. It's more complex from YAML files, but yeah, it's requirement basis like they can use the customized thing. Now someone wants to have their own configurations in that. We don't want to directly take things and apply it to the manifest like so they want some configurations on the top of that so that that and once application get installed, they wanted to do some upgrade and all with that configuration. They can go like you may say like, yeah, Helm is the good thing. Helm is the best option to use that. Yes, but still we have many issues. It's more on like the requirement perspective. It's more on the requirement perspective, but still if some upgrade case came up where the DB schema changes. Let's take example that DB schema changes and we need to upgrade the version of that and in the new version there is some breaking change. We cannot go for the YAML customized or the Helm thing. There we need some operations should be get done with the configuration. So there where the operators comes in the picture which solves actually the complex problems. Might be there is migration, upgrade thing, some breaking changes there. Operator will easily handle that because operator has the reconciliation loop where we can write our own logic. What we wanted to write to get the upgrade things. So using that we can have the more control over the word installation and management of the application. So in this topic, like let's move. So in this topic, like we will more talking about the controllers, operators, Kubernetes operators, how we deploy it and deep dive into the capabilities of the Kubernetes controllers. So are you ready? The Kubernetes operator, which is a controller application specific controller that can help us to package, deploy and manage a Kubernetes application, which is extending the Kubernetes APIs and enabling it to configure our applications application resources using some of the structured and proper way. Let's let's take example that we have a stateful set, right? What's the use of actual stateful set response? What is the responsibility of the stateful set resource to run the stateful application, right? So same that like the same way using the operator, we are going to create our own resource. So if we do the kubectl get stateful set, we can get the stateful set objects. So now we have like own, own resource where we can define our own kind on the specific that under space of stateful, stateful set example. So we can do now kubectl get our own kind name. So there it will reach out our own resources. It will have we will have own custom resource definition as well, where which holds all definition and once which creates the API for our own resource. So let's talk more about this now. So some of the use cases of our operator is like we can deploy and manage our applications with very seamlessly. It's very good at having flexibility and it actually improves the consistency. We can automate as per our need as we discussed like that. It actually helps the upgrade cases and much edge cases where actually the helm and every other installation where it fails, the operator can solve that. And it has having many capabilities and many features which can we can actually use for the operators and to build our operator for our installation. It's it's it's been always a sound that it operators sounds bit complex. There is a noise but earlier what used to happen everything was like it's more like to write writing everything from scratch is a right different thing. Now we are so lucky and thanks for the many frameworks which actually abstract the internal working of the controllers and which provides us some functions where we have to just write our own functionalities inside that. So that is where we call it as a recon seller which frameworks provides us where we have to define like we define our own functionalities on if the application is not installed. And we can write the logic of our first installation logic. If already application is installed we can write our own upgrade logic for that. So it's more on like whatever we want we can we have the complete flow control over there. In demo we will see we will see the code exactly where the recon seller comes and where the CRD CR and we'll talk more about that. So this is more on that. So there are frameworks like there are some frameworks which actually provides us the HDK for the operator like operator framework which is also incursive incubating project. We have the Q builder Kubernetes operator framework. One more on one more thing that cube builder also getting integrated like integrated with the operator framework. There are a couple of Pias code much there. We will see what could be there is adding the point. Let's talk more about the flow of the operator now. So one side let's take the desired state one side let's assume that the user is sitting and other size the let's think about the cluster we have some application installed right. The current state is there. So let's see let's take example of the state full set in state full set what we do we add some configurations in the YAML file and we apply that YAML file some pores come up right. So same way some internal configuration is that which takes the configuration for the YAML and updating actually and creating some pores with whatever the state full set features have like suppose persistent volume claim template has provided on the top. It will take that and it will create volume volume amount like and will actually use that volume and other features also other specs also whatever it is there. So same way in when in operator also we write our own logic own reconcile logic where this operator reconcile comes where user applies their changes in the manifest custom resource. Just think like example as a state full set resource where we update and we apply it creates a pod even if we next time we update some image tag or if some some if we update that state full set with the new console. We have a new configuration and we apply that it actually takes the new parts comes up with the new configuration right. So same way in operator also in our resource also we have a custom resource where we keep we have kind their own kind we have their own specifications which we define in our operator. So this specifications we have to pass and we have to apply that that once we apply that our reconcile loop will run and it will update our current state. If it is a fresh install it will create if it is already installed it will update that. So it's similar to other Kubernetes resources we are creating one more resource in the Kubernetes with our own requirement with our own feature with our own kind. So when let's talk about the reconcile loop how it is called and when it is called so reconciliation basically in operator internally what it is doing. So once the user applies our custom resource that custom resource get specs get updated into the ETCD database and we have the watchers on the event if some event occur in the ETCD database or watchers observes and it reconciles the loop. There are multiple ways where reconciliation happens if there is some error throughout the reconcile loop occur it reconciles again. If some desired state change or some also the existing resource where we set our owner reference which is owns if they even if there is some change some failure occur in the current existing application it reconciles or if something changing our resource like our kind resource. Then also it reconciles on changing the desired state and also there are some default values also after that it reconciles its default is train our in some case it might be different if some options are set. So this is the reconcile loop where we get that there are operator SDK we are more talking about the operator SDK thing we have taken that as example while demo also. Operator SDK has the like levels different levels where they support for the Helm Ansible and Golang Helm support the basic installation Helm operator. Support the basic installation and the seamless upgrade where Ansible and go actually supports the all five stages of the operator SDK of the wherein first we have just the basic installation. In second we have the seamless upgrades in third we have the life cycle of our application even if the backup failure recovery and these features comes in the picture. In fourth level we have the deep insights on the basis of the matrix we text and which is some some resource example as a resource got exhausted we for support we scale it as a horizontal or we perform we do some operations. It can be any type of operation and fifth one is the autopilot thing where like it's horizontal vertical auto configuration auto tuning abnormal detection scheduling tuning and many more comes in the picture. There is one question around like we have customers and we is it possible to is it running on every distribution because someone uses the Azure Kubernetes engine someone uses the GKE KS and many other way. So is it running out yeah it's operating to get set up wherever the Kubernetes run operator will run there let's have the demo time now. Are you excited. We just have the GitHub link up. We have created like work on the portato head operator portato head is the CNC projects to understand the microservices so I have written their operator on the top of that. So this is the CRD which is the actual holding custom resource definition actual holding the definition of our CR which we mentioned which we define that definition in V1 alpha one. This is the default generator templates like default generator files directory and all where we have to update and some directories I have created so V1 alpha one API. So here we have to define our type what all things we have to take in our kind like our resource. So we have like specs status in status we are currently I have mentioned this many things. So this is the place where we actually write our specs type and we we run some commands like make generate which actually creates the deep copy update that which which helps during the runtime. Which which validates like the types what we have written and there are we after that we run the make manifest command which actually updates our CRD which is under this conflict CRD basis. So once we run the make manifest command this manifest get updated suppose some tag we have added in the types.go with some flag with the string so that definition get adds here and it keeps a list of all our definitions. Which is which we have defined in our types what are the comments are there it will be reflected there and that gets done with the help of there is a control agent binary. So and this is the actual the controller folder. This let's go to the main file where where we define our controller the manager and leader gets initialized and this is the controller where we set to the manager. So here the just sometime back we were discussing about the two things one is the force and one is the ones for is the resource to whom the controller will be primarily watching and owns is the resources which during this reconcile during this things we create and we set our owner reference to that resources. Same like if you see the replica sets like replica sets owner reference to the ports similar way now the data SDK sets the owner reference to their created resources earlier we earlier it used to support some functions on the like on the basis of suffix or prefix we used to get set our reference. Now we have owns and this is the reconcile loop which keeps on calling on every change every desired state change or some error occur or some change in our force and owns on the basis of force and own change and also there is a default time there we did get calls and it get rerun. So here we write our own logic create resources and manage resources currently in demo we have so the installation will be like first is CRD definition installation second thing it comes to since we are building this operator and we are building a Docker file on top of and we have to install this. So in this controller we are playing with the Kubernetes resources like suppose we wanted to create one stateful set and one config map. So we have to give this permissions we have to authorize the container in the word authorize our processes inside the containers to create or delete that resource. So that all authorization has been done using the service account so that all back when we roll back success control we create where we have the service account rolls and roll binding if it is on cluster scope we have the cluster roll and cluster binding. So let's apply this thing now it was already there it just configured that now let's create the I'm using the operator name space so it has created now we can see the operator content is getting created so this file we have a Docker file here yeah it is running now we can see it is running. Now let's apply our CR which is a custom resource let me show you this so we have a kind our own we have defined our own kind we have defined our API version group version and version. This is a metadata this is spec we can see like for other things suppose example stateful set we have been taking that so in stateful set we also see the similar kind of structure. We see API version kind metadata spec so here also we have defined that in that way and we have defined our own specs now whatever the specs what we want. So once we apply this thing we can see that once we apply this CR that reconcile loop call in and their functionalities were there to create these resources. So it is called and see we can see that like all ports are up and running. So let's have some test like check against the upgrade case how it will behave in upgrade so we have the same CR here also so here the version is 0.1.0 let's let's change it to 0.1.1. I have changed it everywhere and let me apply this let me confirm that so we have our own resource now we have we saw that like let's describe this resource to check the version. Yeah it is already 1.1 so it is because of that it didn't get updated let's let's move to 0.1.0 and apply this now. Let's configure now let's see the ports so older ports are going and like new ports has become new ports has been coming. Let's now new ports are up let's get our old description describe our old describe our CR custom resource so we can see our version is 0.1.0 and our ports are also up with new version so it's more like seamless and it's similar like we can write our own logic as many as many as the features what we want we can write that something breaking change we have added the logic for that change. And if let's take example like if the application is running and something failure happen we have we have updated the manifestation we have applied this in upgraded case and something is fell in that. Image only and it's not coming up and running so what is in that case so we can write a logic in that case so that if something fails there it will it will again take the older version and again install that or it continues with the older. New polls if there is some failure or it will come go down and older will stay so that way our application will be application will don't will not have a downtime so this is more on the radar so looking forward for more questions and answers. Yeah someone wants to test locally they can clone this repo and test locally and if there is something they can raise the peer as well. Thank you so much they can scan one more time and feel free to contact me on Twitter link in GitHub dev.to looking forward to connect with you. Thank you.