 Hello everyone, my name is Katie Gumanji and alongside Carlos Bonato, we're going to give a deep dive into Cloud Street PI. As mentioned, my name is Katie Gumanji and currently I am a cloud platform engineer for American Express. I have been in this role for the past year and I am part of the team that aims to transform the current platform by embracing the cloud native principles and making the best use of the open source tools. As well, I am one of the TOC or Technical Oversight Committee for the CNCF. Alongside TenAvi Champions within the open source community, we will be responsible to steer and maintain the technical vision for the ecosystem. Pretty much we are the committee that enables and leverages projects to join the open source community and be useful for our end users. Hello everyone, my name is Carlos Bonato. I am a software developer at Matermost. In the Kubernetes community, I work in the security as a branch manager and also in the cluster API and in the various cluster API provider as a contributor. Today, we're going to talk about the cluster API and this is our agenda for today. We're going to like give a quick overview about cluster API. We're going to explain the control plane. Kate, we're going to talk a little bit about cluster ops and Argo CD. We're going to see a demo. And we're going to talk a little bit what's the next 10 planet features for the cluster API and how you can get involved with why cluster API like today we have more than 100 installation tools for Kubernetes and also the cluster lifecycle. It's very hard to deal with it. Like the day two, day one, day two of the cluster. And the idea of a cluster API is bring in a central place like an easy way to create your cluster provisioning your workload cluster and manage this cluster in terms of upgrading repair outscaling and deleting the cluster as well in the end. Today we have a lot of providers that it's like a building block for the cluster API with you can plug your provider and start using that to provision your cluster. We have, for example, today Azure, pectin, AWS and other cloud providers. You can see a full complete list of the providers we support today in the API book as you can see in the link above. And if you don't find your provider here, you can build your own we support like there's in the book you can see how you can add a new provider. Okay, how it works. That is a lot of YAML files. That's everybody likes that. And it's a declarative spec that you declare your cluster. And we have like a management cluster that you install your cluster API and the cluster API providers, and that can bootstrap Kubernetes clusters across several cloud providers including also bare metal as well. For example, this example here so you can declare your configuration if you're going to apply this to the cluster API and again create cluster for in this example we have AWS VMware via sphere, Google Cloud and Azure. You can imagine this like being AWS cluster for a team A and another one VMware for the product B and so on you can have multiple cloud providers and you have your management cluster in one place only that can manage several clusters across various cloud providers. Where the cluster API are right now, like we are part of the SIG cluster life cycle project, we have more than 200 contributors, and we are in the alpha stage where like we are most likely to in the end of the alpha stage. We had like release alpha one, which was the initial implementation and the POC to validate if this everything works. Then we got alpha two, which with solid foundations and like building the bootstrapping agnostic infrastructure. A few months ago we release alpha three with like more primitives and a lot of improvements like trying to make a little bit more stable. And now we are like aiming for alpha four with more stability like not more having a breaking changes API and supporting a lot of UX to make it more easier to make easier for the people that are going to use that and also to support the V1 beta one transition for the next year. What we want where do we want to be like the idea of the cluster API is making the managing the life cycle of Kubernetes very boring and like to be easier to people use the cluster API and create your managing your clusters. We also have a lot of support a lot of use cases like you can write your own plugin you can write your own providers and the idea is also support like security requirements and different apologies in different complex scenarios as well. Now at this stage, I'd like to give a deep dive into the control plane resource. Now in the view on alpha three release, which is the current release. This control plane resource was introduced and it provides a lot of powerful operations of how can we manage our masters. Before I move forward with this topic, I would like to introduce the customer search definitions introduced by cluster API. At the moment, there are five of them cluster control plane machine, machine set machine deployment. The cluster resource is going to contain the holistic information about the cluster, such as the networking components will be able to specify the starters for our pods and services. Control plane as mentioned is a new resource introduced in view on alpha free, and it provides an obstruction layer of how can we manage our masters or the control plane or the masters with the core components in within a cluster. Machine is configuration is very similar to not configuration is going to contain information such as the version of Kubernetes you'd like to run alongside the instance type you'd like to attach to instance. Machine set is going to be very similar to replica set. It will make sure an amount of machine resources are going to be up and running at all time and machine deployment is very similar to deployment. It comes with a very powerful rolling out strategies between machine sets. One thing I would like to mention here is that the machine resource is immutable. That means that if you push new configuration to the cluster, the instance with all configuration is going to be taken down. And the machine with new configuration is going to be brought up. There is no patching. There is only mutability. To fully understand how we can create a cluster using cluster API and how all of these resources interact between themselves. I would like to introduce kind of a higher point of view or perspective of how can you use these resources overall. Now, to begin with will require a cluster resource. As mentioned, this is going to contain the entire networking configuration for cloud provider will be able to create resources such as VPC subnets and so forth. With the cluster automatically going to have associated a control plane with it. So we're going to have a control plane resource, and that is going to manage a set of machines. Now these machines are going to be our master nodes. The control plane estimation is going to install the core components for cluster. So we're going to have the API server the scheduler control managers, pretty much all packed back package nicely together. And the last thing for working cluster is our work nodes for the data plane. Now the worker nodes is something we attach to a cluster. It's not something which comes by default will be able to attach different sets of kind of working nodes to our cluster. As such, we're going to have a machine deployment, and that is going to have an abstraction layer above the machine set and of course the machines themselves, which are going to be our work nodes. Let's look at the YAML definition for our cluster, because this is the main resource which will bootstrap our infrastructure. As you can see in our cluster we're going to have the networking specified we're going to choose select a slash 16 for our pods. However, I'd like to draw your attention towards the control plane reference. Now this is the section which will invoke a different manifest, which is going to be a declarative representation of our control plane. Be mindful here that this is actually a trimmed output so we're going to see the full YAML definition through the demo. So within our control plane, we will specify our cluster the namespace is going to reside we're going to specify information such as the infrastructure template. And this is going to be the applicable definition of how we'd like our machines or for the masternodes to be configured. So if it's going to be for example in AWS we'll be able to specify the region, the instance type, pretty much configuration parameters like that. The QBADM config spec is going to focus on how can we initialize and join new machine to the cluster. And as well within the control plane we're going to define its amount of replicas so the amount of masters would like to have, along with the version of our Kubernetes cluster. And the last section we have in our cluster is the infrastructure reference. Now this is actually going to have the information of how we'd like to define those networking components I was mentioning before. As such, if we look at the manifest for AWS cluster, we're going to have a region specified in this case is going to be a West one, and we are going to attach an SSH key to our instances, and for now it's going to be the default SSH key. Before I move forward with the demo, I would like to showcase this setup we have with cluster API and Argo CD. Now cluster API is an extremely powerful tool because it completely rethinks the way we see our manifest for the clusters. They are actually represented for YAML and if we have YAML that means that we can have in operations within the cluster on top of these files as well. For example, if you have manifest, we'll be able to strengthen and get an applied templating layer on top of them, such as help for customise. Once we have this templating layer, it's going to be very easy for us to apply changes and reconcile any changes with a tool such as Argo CD and Flux. For the sake of this demo, we're going to use a Helm template for our cluster API manifest and we're going to reconcile any changes using Argo CD. Let's look exactly how we'd be able to upgrade a cluster by using just one command or one commit for our manifest. At this stage, in the top view, you're going to see our cluster. This is a demo cluster with six nodes, three master nodes, and three worker nodes, and this is running in 1.18.8. On the lower level of the terminal, you'll be able to see all our machines. So these are going to be the machine resources. We have a cluster API. As you can see, looking at the name, we're going to have the control plane, which is going to be our master nodes, and we're going to have our machine deployment, which is going to be pretty much our worker nodes. And all of them are running in 1.18.8. To create this cluster, I have used Argo CD, and pretty much I have an application here, which is going to go and look for the Helm chart. So if you look at the application details, we'll be able to see our Helm chart, which is declaratively defined here. So we're going to have a template, fairly standard for that. And the values file we're going to use is the values.demo, which represents 1.18, the amount of replicas for all masters and workers, which are going to be free. And we can further confirm that by looking at our parameters. This is pretty much what we see here. This is going to be our source of truth that we will feed to our Helm chart. Now, we would like to see how exactly the control plane resource works in a real example. For that, we would like to push a new change to our masters. And one of the most common operations we're going to have within an infrastructure team is upgrading your cluster. And for now, we'd like to change the version to 1.19.1. And I'm just going to commit this change with a very meaningful message as well. And I'm just going to push it straight away. Once these changes are pushed, they're going to be identified by our city straight away. Because I have manual reconciliation. If I just hit refresh, we'll be able to see that we are out of sync. We have a new commit. If you look at our commit, there's the only change we've done. So we've changed our version of Kubernetes. And because I have manual reconciliation, I'm just going to hit sync button and synchronize our resources. Now, the most interesting thing is to actually look at how exactly the machine resources behave or cluster API resources behave. As you can see already have a new machine being provisioned. So one for our masters and one for our workers as well. And this is going to be pushed. Another thing I'd like to showcase. If you look for example at AWS straight away, we'll be able to see that we have two instances initializing. So we already have the new machines rolling, at least creating. Once we have a machine being ready with a new version, it is going to be added to the cluster. Let's wait for maybe one or two minutes and see if that's actually going to roll out. The full demo is already recorded as well. We'll make that available on social media. We can attach a YouTube link to that. So you'll be able to see a speed up version of the entire process. But throughout once we have a new machine with a new configuration that is going to be added to the cluster and a machine with all configuration as mentioned is going to be taken down. So there's no patching. There is only need to be able to. Now, let's see if that will progress fast enough for us. Looking back into our AWS. Still initializing. Oh, you can see we have a new machine with 1.19.1 already added to the cluster. It's not ready yet. It will be ready once the networking calico actually is going to be appropriated through. And you'll be able to see as well that a machine. This one, for example, the scheduling is disabled. It is going to move all the pods transition all the pods to a worker to a working node. And subsequently it's actually going to be removed. And this is going to be performed over and over again up to the point in the new cluster, which is going to have all the nodes within the version. So this is going to be confirmed. As you can see, this machine is in the deleting stage. It's going to be removed. So this is pretty much that deployment strategy that powerful concept of how can we really do upgrades with just only one change to our control plane. I will just leave that running for now. It's going to be around 15 to 20 minutes depending on the amount of working notes or master news you have, but pretty much around 20 minutes we're going to have a new cluster, well, the same cluster with the new version. Okay, for the roadmap for the V1 Alpha 4, we are still doing some grooming to see what is the features we're going to add for Alpha 4. But the ones we already know and we are working on that is the ones you can see in the slide right now. We are going to focus on the UX and bootstrap, like have a machine bootstrap failure detection as well. We are going to work also in order more core improvements moving away from core one object to have for us and also like upgrading the dependency like using a QBDM V1 beta 2 types and to support that as well. This aiming like to have the latest QBDM and also aiming to like have more stable and moving to beta one later on. And this pretty much concludes the deep dive we wanted to showcase about cluster API. There are a few takeaways we'd like to leave with you before concluding the talk. The cluster API has been so successful and efficient in just one year and a half because it uses the building blocks principles. It does not concern itself to bring new API importance for Kubernetes to consume its capabilities. It actually builds on top of the existing primitives and making the best use of customer service definitions. A very important thing about cluster API is the fact that it's cloud agnostic. It truly provides that one interface that allows the infrastructure teams to plug into different cloud providers, but more importantly, by reusing these manifests. We would like to have a better management of our clusters overall. And currently cluster API as you can see is under continuous development. So if you'd like to have new features if you'd like to propose a new provider to be integrative cluster API, please reach out to the team and contribute. Now is the perfect time to customize cluster API to use case. If you'd like to find a bit more information about cluster API and some of the knobs and the kind of maintainers point of view, you'll be able to watch the webinar which was provisioned while recorded with help of CNCF. The link is provided below. If you'd like to find out a bit more of how to get started with cluster API, how can you integrate a cluster API with Argo CD and how you'd be able to do this one common line one line commit to upgrade your clusters. I have written detailed blog posts medium and you'll be able to find them there and pretty much get you started on all of these methodologies. If you want to like start contributing like in the project itself, you don't need to have only like coding skill. Like if you write writing skills if you write like writing documentation, writing, writing guides and so on. Like we have a lot of places that you can contribute for that. If you have like more product skills like we can get like collect use cases and compile and do all the stuff like we can see the use cases, and then we can build and plan better features as well. As well if you have coding skills, you can review for requests and become an approver like you can search for help when the tickets are good for issues across the entire cluster API, not cluster API but also the cluster API providers as well. There is a lot of help wanted tickets that we need help on that. If you have any other skills like you can like provide feedback to us, you can make demos you can ask questions you can also join the weekly community meetings and join our slack as well. Like you can also is helping testing the cluster API and then open the issues like to explain what is wrong or what we want to see on that as well. I mentioned if you'd like to have more information about today's talk please reach out to us on social media. We're going to be available on Twitter and team as well please read articles I have on the meeting account and reach out with any questions you have. Enjoy the rest of the conference. Thank you. Thank you.