 First of all, thank you so much for sticking to the last talk. I know it's very hard and energy consuming to be through this entire conference and sticking to the last talk. I appreciate your patience. And I hope we can make your patience worth. So starting with cluster management and cluster API, how many of you are aware of the term cluster API or have used it? OK, a lot of them. You are using it or you are currently introduced to it? Or you have been using it from a long time? How many of you have been using it for a long time? Very few. And how many of you started using it recently? Narco organizers gave a very good introduction. It's not working. So I'll just skip through very fast. My name is Subash Mita. I work at Civo as a site reliability engineer. And I was in the past LFX mentee for cluster API provider GCP. And I've also been an outreach intern. And my friend Anirudh will introduce himself. Hey, everyone. I am Anirudh. I work as a software engineer as I self. Apart from that, I did LFX mentorship at CABG. And right now, I also maintain two of the cluster API providers, which is Hetsner and High Velocity. And so we'll let's talk about bits and pieces of cluster API. So very quickly, moving over to the agenda, we'll just discuss about the cluster lifecycle. Why it is very hard to maintain the cluster lifecycle by manually and why we need that automation. It's common, right? We are living in the DevOps world. We love automation. So the type of Cappy providers, like there's a common misconception that cluster API has providers like GCP provider or Azure providers. But there's also the type of cluster API providers under which is infrastructure. And under infrastructure, there are providers like GCP, Azure, AWS. So we'll be discussing about that. We have been hearing about Kubernetes this entire day today. I won't bore all of you with, again, starting with Kubernetes. Just a basic introduction. You know all what is Kubernetes' basic orchestration scaling tool. We will get on to the fun part there next. So this is a very basic architecture of cluster, Kubernetes cluster. The major components here I would like to highlight is this control plane. Please try to remember the words that I tell because this will be used in the next slides. The control plane then controls the nodes and then later on the pods wherein all our workloads are running. So we'll be playing around with this control plane a bit to automate all of the things that a Kubernetes does for us. Why do we need to manage clusters? This is a very big question. Why do we need this automation that we are about to talk today about? So as the complexity grows, for example, I have around 10 to 15 applications in my organization, and I want them to run concurrently and to be available to every customer at all times. So I would require a very good scalability, traffic management, and load balancing. I don't want my application to be down when there's more footfall, like more people are visiting the website, or when less people are visiting the website, the application is not working at all. So to manage all of these things at all times to ensure your application is running at all times, we would need the scaling and load balancing of your clusters at all times. So that is not possible always, manually, to do that. You won't be sitting at the front of a PC and you'd be monitoring your Kubernetes clusters all day. Would you? You won't? So all about rollouts and rollbacks, automated. Like if you make any changes to one cluster spec or one configuration, you want that all of the applications that are using that same feature, common feature, to adopt to that, you won't be going to every cluster or every pod or every node and be changing that concurrently, would you? You won't, because that would be a repetition of your task. So we would need automated rollouts and rollbacks. We need to admit we humans are very lazy. We always find ways to reduce our workload. That's why all of these tools are built. Self-failing, sometimes what happens, node dies or a pod dies. So if a pod dies, whose duty is it to pull back the pod? Obviously, the management or the configuration that has been given there. But sometimes what happens, if I give an example, in a cloud service provider, if a customer is running their workload on any cluster, and one of their pod fails, but they're not aware of it. We as engineers, I'm working as a site reliability engineer. So I know when I get an alert at PagerDuty or when I get an alert at Alert Manager, I know this pod has failed and something is wrong with this cluster. And all of these things, the customer is not able to put their application to full use because of this issue. So how does the customer know all of this, that their application is not failing and is working all of the times? So we would need something of self-healing. If something happens, if a pod moves ahead of the memory, like uses more memory than required, it would fail. That's common concern. It would fail. But how do we make sure that this pod comes back as efficiently as it was before? So that's what's self-healing. And we would need to automate that stuff. Again, configuration management and secrets. Secrets is a very big pain, like managing secrets, managing roles, and managing access across every stage, like with pods, with nodes, or with multiple clusters in an environment, is very difficult. To manage all of these manually is very difficult, right? So that's why we would need cluster API. So this is a very small meme, where you can see, I think you can understand it infrared from it. Like running a Kubernetes bare metal cluster in an production environment is very easy. But it would take you ages to go to that perfection and to make sure every end-to-end process is done correctly, and your applications are up and running always. OK, a lot of things about the background. What is capping? So cluster API is basically a Kubernetes style bootstrapping operator. It's kind of an operator which is allowing us more control over our clusters, but in an automated way. Like all of the difficulties that I discussed before are managed or handled by a cluster API. Cluster API will basically provide you with just a cookbook where you can get a set of recipes and you can add in your own flavors to make that recipe your own. You can call it your own. You can deploy it in your own infrastructure. You can add in your own resources. Or you can add in anything that you like that suits your requirements or suits your needs. And you can make all of these processes hassle-free and automatically using cluster API. That, too, in the Kubernetes-style API management. So yeah, there are multiple types of providers where cluster API can be customized to be built on particular infrastructure. You can bootstrap one from zero level and build that up to your needs. And then it's very simple to use. There are set of CRDs, custom resource definitions, where you define your state that you want your cluster to be in, or you want the desired state of your cluster where you want to see your cluster running or configuring. You can get that through very simple steps using cluster API. Because everything has been set, like the plate has been set, all of the ingredients has been given to you. You just need to cook it in your own way. Important fact, more than 100 Kubernetes distributions and installers have been created till date now. So not just cluster API GCP, cluster API AWS, or cluster API Azure, there are more than 100 Kubernetes distributions today and all coming with a template. So all you need is just an environment and you pick up the template and you are ready to go with your Kubernetes cluster in production environment, all controlled within your hand. So moving on, we'll discuss a bit about the cluster API architecture. So my friend will take over from you. The whole architecture of the cluster API. So first, the user makes the API request to Kube API server and as Shubhash Mata said, the cluster API is all about different CRDs, different resources, and running together to make your managed clusters. So there are three main components, which is cluster, machine deployment. So machine deployment and machine has the same relation as your deployment and pod. So like as deployment you create to manage different pods, like you have machine deployments which is reference to the clusters and through machine deployments, you define how many machines you want and stuff like that and the cluster API controller or operator handles all the things. And cluster defines your Kubernetes cluster in different providers, like GCP, AWS, and Hetsner, like that. So we have different layers in cluster API. So basically we have five layers which is bootstrapping, control plane, infrastructure, IP address management and API add-ons and adapters. So going to bootstrapping. So bootstrapping is creating the Kubernetes cluster. So like you have a cluster, but you don't have like a Kubernetes inside and whatever, all the components. So what you will do, you will write a CRD, like boarding YMLs and define what are the configurations you need to the bootstrapping. And as you can see, we are creating a test cluster thing and we are deploying that in a GCE. And the popular thing like cluster API use for bootstrapping the cluster is QVADM which is a different set of topics. But yeah, you write a lot of QVADM scripts to like the bootstrap your cluster in the provider. Yeah, second is control plane. As she said, the two main important things is control plane and workers. Control plane actually controls your cluster API cluster. So we have like, as you can see, as I said, we created a QVADM bootstrap cluster. So we need a QVADM control plane. So we said the control plane has three replicas and we have like kind and whatever CID and cloud providers DC. This is a basic like QVADM control like CID for spinning cluster in the Google cloud. And the next layer is infrastructure. So infrastructure can be like, it's like an abstraction over different providers. So your AWS has infrastructure, your GCP has infrastructure. So the providers of cluster API writes this infrastructure. So if you go to the main cluster API repository, you won't find any infrastructure code or controller in the main cluster API project. But you will find it in different providers of cluster API. So suppose you came up with a new cloud provider tomorrow and you want to write your own cluster API controller for that, so you will write your own infrastructure CID. And you will define your resources like your region, your network and reference to those things. And we have a machine template for our infrastructure. So this machine template actually refers to the machine of our cluster. So it will get reference to the worker nodes and those like CIDs get referred to our infrastructure. And second thing is IP address management, which is like you have different now pods, different cluster API machines and everyone needs like IP address. So you probably need another CID controller to manage your IP address. So you don't find like a conflict and like say like pod conflict like that. Yeah, so we like a lot of softwares we have add-ons and adapters like in cluster API as well. We have add-ons and adapters. So suppose if famous software we have is Helm. So suppose you want a Helm support in your cluster API provider. So what do you use? And we also use in my provider like Hitzner, like we have the Helm add-on support. So if anyone wants to write the entire thing using Helm, so they will also like install the Helm CRD into their cluster and like they do all the scripting thing using Helm. So you can also like write those things into, like consider those things into the cluster API ecosystem. So as I said like we have in a base which is cluster API and in different like providers have their repositories and infrastructure and what makes is like a similarity. So suppose the controller you write for GCP will be almost identical for controllers you write for AWS. So the basic architecture will be same. So like, so you can see like in GCP we have the cluster API in top and second layer we have the CRDs which is like cluster API is controlling, control plane deployment, machine deployments and things and at the bottom we have infrastructure layer which is like GCP provider and at the end the GCP cluster gets created. Now if I go to the next slide and now it is AWS. So AWS has the same architecture like cluster API working in the same way for different providers. So it's like working like a framework. So here you can see the same. We have at the top layer cluster API controlling different CRDs and at the bottom we have the cloud provider which is like getting spined up, the cluster getting spined up and all the network being managed by IP add-ons and if you want you can do whatever using Helm. So it's like a whole ecosystem. And last one the provider I maintain which is Hetsner which is also like very similar and it's nothing I don't want to waste more time but it's at the bottom it's all same. Yeah, so it's one of the biggest projects in Kubernetes community. So do contribute like if you want to and you can see different open issues are good for the issues first and there are not like if you don't know much like go code or coding you can also contribute in different ways like documentation. Like we have this shadow program of cluster API where different people get selected for like maintaining the project for a fixed term like six months term where you get to learn from the maintainers and there are different like section of the shadowing program which is first one is very important like popular which is the CI signal which is maintaining a whole like proud jobs of Kubernetes ecosystem and you will be monitoring and you will be reporting to the maintainers and what went wrong and other like mis-happening thing and also there are like shadow for documentation so you will be writing and documentation and like if you are good into shadowing you will become a maintainer too. So the Kubernetes community is working very hard to like bring this cluster API to light and to help a lot of people have their lives make easier so we would request anyone to contribute in any way they can there are also non code contribution types like you can contribute to the design you can contribute to the documentation you can help in the translation of the docs or simply you can just help anybody else in the community or by joining the Slack channel. So there are multiple resources like these are by far the most trusted and the most popular ones. You can join the Slack channel of Kubernetes and you can like go down to the sub channel of cluster API where you can communicate with the people or help out anybody else. You can go to GitHub cluster API through this link where you can like get the code repository of the cluster API and then you can navigate to the other parts of it. There's the cookbook that I talked up to you at the beginning of this talk like you get the template over which you can you build your own infrastructure you can get that at this location the CAPI cookbook or this I think that's all for us. Do you have any questions we can take that? Cluster API and open cluster manager which we discussed in the morning the same or the different? Is cluster API or open cluster management same or different? See a cluster API basically gives you like a set of recipes that I'm telling you open cluster management is a different thing. You get a set of instructions already built like in a general way and you tailor that to your own requirements and modify that to your own requirements to manage the cluster or manage the environment you're in. While open cluster management you just get to manage the cluster that's already built for you. So that is basically a different part wherein you start and you not just the managing part but also you can control how your cluster is built from the ground up. It's, see Terraform is also a manual thing, right? You don't love to write Terraform code always. For every little change you will always have to make changes to the Terraform file and then do Terraform apply and all of these things will run again from the top. So in that process sometimes what happens your cluster IP changes. So there can be conflicts. You don't get to manage that. You don't have the right to manage that, right? But in cluster API something like, if something goes wrong you're automating this entire stuff. So if something goes wrong you can, the cluster API manages it itself because you have already provisioned that state. Like for example, you have said if I slap on it, I know he will slap me back. So that's the state I have already defined. I know this will happen, right? But in Terraform you can't do that. You can't tell, you can't write conditions in Terraform. You can't write like in Terraform, hey Terraform if something happens like this in my cluster you need to change this configuration by yourself and deploy that to my cluster. That's not the process to do that. I hope I was able to make you understand what I was telling you.