Welcome to the session. today we're going to talk about current. It's an open source project. That's aimed at simplifying Cuban these cluster processing at scale, right? So all of us who've been in the DevOps world know what a pain it is to, probably in a cluster, right? You have to come up with, an optimal way to do it at scale, and to manage, complex Configurations as well. So Codent solves this problem. in the session, we're going to look at the challenges and we're going to see what difficulties are there in platform engineering and then approach Codent. And towards the end of it, we'll see, Codent in action, right? So I'm Bharath. I'm in the OSPO team at Monantis. I'm a senior software dev and an open source contributor. Been working in and around Kubernetes for a while now. Let's get started. So we all know how the cloud was supposed to be right, but very quickly It got into this maze where everything became just so much complex And even kubernetes which started as a very basic project quickly grew and although it is the ecosystem, is what makes it today the ecosystem has become so big that It's super complex, even for an experienced person in this world. That's why we need a simplified streamlined process, which we call platform engineering today. And for enterprises specifically, when you look at platform engineering, if I have to sum up, what are the key things that you look for? Developer self service is extremely important. So having a dedicated DevOps team that's as big or even bigger than your development team is not scalable anymore. So you've got to have a self service portal. Where your dev teams and your QA teams and your security teams and all the other teams can manage the infrastructure themselves with the platform engineering being the backend You also need operational simplicity If you don't have that then providing this for multiple teams across your company becomes extremely difficult Customizations is again another important thing because like I said, for different teams, the requirements will be different. So without changing the core model, having the option to customize is what, brings this whole process about for platform engineers. And visibility and control, again, at an administrative level, this is extremely important to manage your clusters. And then, last but not least, security and compliance. Every company is going to follow it. that's a primary, these days. So given all these challenges, there's a growing need for multi cluster configurations. So for a platform engineer, you need multi cluster configurations for multiple things, such as AM and work nodes or multi tenancy, edge devices, IOT, and so on. Now, when you look at the market and see what are the options available for me to accomplish this, Then if you don't do anything that's always an option, right? So if you don't do anything, your infrastructure costs grows up and up. And before you realize you're paying like huge cloud bills, right? Then let's take it like a basic step ahead with DIY open source tools. of course, there's been so many tools for cluster provisioning and maintenance in the open source market. But then there's always this. Learning curve, that's, that comes with it. And then you gotta understand each tools and you gotta understand how one tool works with another integrations and configurations and all that. And then of course, you have the problem for extending it to your on premises as well. Then if I have to take it another step further, there are proprietary solutions, but the proprietary solutions obviously come with expensive licenses and they're quite limited to the options that they provide. And more often than not, two years, three years down the line, what's going to happen is that without, you looking at it really hard, you are in a vendor lock in, right? And if you have to expand to multiple clouds, and it becomes really difficult at that point. So to solve all these problems, we are presenting an enterprise grade open source solution, right? That's cost efficient and that's customizable and it's completely in your hands and your control, right? And it works on multiple public clouds as well as on drum. This is where Codent comes in, right? At a very high level, we have three things. Cluster management, state management and observability. So the cluster management, what I mean by that is, how are you going to manage multiple clusters across clouds at scale? That level of cluster management is taken care of by Codent. State management talks about the day to operations when you deploy or need to deploy multiple applications across your clouds in a single click. That's your state management and then comes. Observability. So when you have a working operation, clusters and workloads and apps running on it, the one thing that's 100 percent needed in this world or any world is really observability tools. So we're baking this into the current ecosystem without having to rely on external resources. We have to again do configuration yourself. All this is that so open delivery is used and you can just use it right from the package. So before jumping there, just one last thing about the golden paths that's often talked about in DevOps. So everybody wants to perfect this. Every company, every team is looking to move as close as possible to a golden path, although you can always argue there isn't one. But right. Having something close to that is still a lot of success. It still saves you a lot of effort, money, and it gives you a repeatable process for maintenance as well as scalability. So especially when you have a choice of multiple clouds, then this becomes extremely important as well. A quick look at the Codon architecture. So at a high level, like I said, there are three components. One is the cluster management, one is the state management, and then you have the observability stack. So with the cluster management, what happens is we use upstream capi controllers. So Since this is completely open source, the underlying technologies to make this happen is also open source. Based on the cloud, we have the CAPEX controllers as well. CAPA for AWS, CAPZ for Azure, CAPV for VMware, and so on. We deploy the upstream CAPI controller, as well as the cloud specific controllers, onto your management. Cluster along with that will be the Cosmotron controller. So K0s and Cosmotron form a core part and this entire architecture wherein we use that for controller management. So this becomes your management cluster wherein the KCM controllers and a bunch of other components that are related to current along with the upstream components. Are running on the management cluster and right here in the management cluster for state management We have sveltos controller So sveltos like I said is for managing the states and deploying applications across multiple clusters, right? again, this is an open source project and it's Integrated into codent so that all you need to do for example If you want to provision or deploy cert manager across all your clusters Then all you need to do is include search manager in the configuration file. And that's that's automatically deployed to all the clusters And that is what's shown, here on the right side in the child clusters So in the child cluster along with all the kubernetes add on services that you'll find You'll also see that this is felt as agent that's operating there To talk between your child cluster and the management cluster, right? How you accomplish this entire thing is by defining something called as a cluster deployment We'll look at this in detail when I go to the demo part But just briefly I want to mention that your entire cluster configuration will be controlled and monitored using this cr called as cluster deployment and to facilitate the Configuration of the clusters based on the cloud. We have multiple cluster templates and to facilitate the applications configuration, we have service templates. So the example that I gave you earlier about cert manager is an example of a service template and example, let's say you want to deploy it on AWS. That's defined as a cluster template, right? So this is a very overall architecture of, Got it. So now let's go into the demo and just before we go into the demo. I want to open the documentation and just briefly go through this so if I Look at the installation part, right? So we have a help package. like I said, you need a management cluster. It could be kind or it could be running on any other infrastructure as well. for simplicity, you can try kind to run on your laptop or any VM and then all you got to do is do a helm install. Of, of the KCM, right? Once you do this, a bunch of components are installed, like I said. The controllers, the Cosmotron controllers, a bunch of other KCM stuff. And then we proceed to define our, cluster templates and then define the cluster deployments. So now let's jump into the terminal where in I already have a kind cluster, right? And if I do this, you'll see that there are all these namespaces. And if I do this, you'll see all the parts that are up and running. So it's exactly the same. Like I mentioned, there's an alive kind cluster. All the controllers and Cosmotron and other components of KCM, right? And the next thing, by the way, that's this. So kubectl hyphen and KCM system is Ka. And if I do cluster template get, here you go, you see all the different cluster templates. So these are pre packaged templates that are available for you to try based on the clouds. So we have for AWS EKS and then AWS and then Azure EKS and Azure OpenStack and vSphere. Similarly, you have service templates and by default, a bunch of service templates are baked into the management cluster. when you install it, the other Helm shot. some of the examples are these, right? So all you've got to do is specify this in the cluster deployment. So just to show you how that looks let's take a look at a shore. These are all the files that you typically need. not all of them, but I'm going to show you one by one. You'll need a secret. All these instructions are provided in the docs, by the way. So the instructions are segregated. Or cloud provider and it's slightly different for cloud provider based on how they expect the credentials to be set up and all that So example aws you have these keys for azure you have something different, right? you've got to create You've got to create a service principle based on the subscription ID and for OpenStack, again, it's all these variables and similar, similarly for vSphere as well, right? essentially, there's a secret. yml file and then there's a credential file. this credential is referenced by the secret and cluster identity is also referenced by the credential. cluster identity is a file. That is a cr of azure cluster entity and it references these stuff now Finally, let's take a look at the Cluster deployment. So i'm defined two cluster deployments here. One would be a basic cluster with One control plane and one work node, right and it uses minimum cpu Okay, and then there's another control under the cluster deployment pretty much a similar configuration but I have used A gpu enabled cluster, right? I've applied both these things. Just to show you the other bit as well For aws you have all these things as well, right? So aws How you have to choose? Is if to choose the instance type based on what you want. So here i've chosen an instance type Which is a gpu enabled worker node if you don't want a gp enabled worker node It's absolutely fine. All you got to do is select something like this to three dot small t three dot medium Whatever is your requirement and similarly for open stack as well Now i'm going to show you the kind of objects that we work with. So Since i've already ran this Here you go. So when you list the cluster deployments, you'll see something like this, right? Let's go ahead and list one of them and Do if no yaml, there you go. It's as simple as this So this is where you mentioned the cluster template and this is where you mentioned the credential and this is where you mentioned the configuration that's specific to you and this is completely customizable if you look at you can look up the documentation for all the various, fields that are available. and that's that so as to show you another example, let's look at the open stack one So there's an identity ref. There's a specific to open stack cloud And then there's the control plane configuration the work configuration and then the template so on and so forth, right? So this is our private cloud. So some configuration that's related to that has to be provided All right. now that we've seen the cluster deployments, and like I mentioned, it's all Capi objects, right? So you can see the Capi object being created underneath, right? So you'll have the AWS cluster, Azure cluster, OpenStack cluster, and you will also have the AWS machines, and Azure machines. And open stack machines, right? And finally if I have to do a machines Then as you can see it's listing all the machines that are available on the cluster to access this cluster it's as simple as getting the secret so Ka like I said is in the kcm system namespace. Let's look at all the secrets in the kcm system There's a bunch of secrets, but what we're interested in is the secret that has kube config appended to it. So for every cloud, you have a kube config and I've exported them all. I think. Let's also export this and let's also export this. Now, if I go here and do this. Now I'm in the Azure context. I do this. There you go. I have a single worker node and a single control plane node and it's up and running, right? Similarly for AWS. Alright, there you go. Last but not the least for OpenStack as well. All right, so you have all these notes, right? So you know, it's as simple as that and on the cloud You can see that these machines are provisioned here Similarly for a short as well. So as you can see this one is using the standard one and this one is using instance type that has gpu support as well, right? So that's running the tesla t4 nvidia chip Then aws has these So essentially, it's as simple as this, end of the day, what you need to do is define your cluster deployment and specify the configuration and Gordon takes care of it end to end, right? yeah, you have the KCM repository. It's completely open source. You can go take a look. Contributions are absolutely welcome. We have a slack channel as well. It's updated here. yeah, that's pretty much it. Thank you. Thank you for listening. Bye bye.