 Hello. Hello, everybody. Welcome. Welcome to the advanced multi-cluster scheduling with open cluster management. Just a quick question. How many of you know open cluster management at CNCF project? A few hands. Yeah, it's going to be a good session. I'm Lewis. I work for Red Hat and also for the open cluster management project. This is Dario, my colleague. You want to introduce yourself? Dario, I work for, I work at for open cluster management for a while in the latest months, a little bit less, but I'm going to say something concerning open cluster management. Normally you should know that about. Yeah, thanks. Let's let's dive right in. We don't have a lot of time. So I'll go straight to this slide, which is what is open cluster management. For those who doesn't know what it is, it's a CNCF Sandbox project. It's supposed to provide vendor neutral APIs for multi cluster Kubernetes management. So what does that mean? If you can handle multiple clusters at once, open cluster management can help you right there, right? So sorry, doesn't matter where it's located. Doesn't matter the infrastructure. Doesn't matter which flavor of Kubernetes it is. It's supposed to have multiple APIs for helping with multi cluster management. What are these APIs? I'll speak about the main ones, the main features. One, open cluster management is going to give you a cluster inventory. So if you manage 10 clusters, you have a list of 10 managed clusters like a cluster inventory. So that's one. Second one, it's called workload definition. Dario is going to talk more about this. And it's supposed to help with with workload placements. That's why the title of the call is advanced to scheduling because it's going to help you schedule and place workloads in the right clusters. So that's one of the main APIs. And plus where it's going to land. Which namespace? Which clusters? Is it going to be a static workload? It's going to be a dynamic workload. So there are many APIs that we are going to explore in this lightning talk. Dario, you want to go ahead? Yeah. As Luis mentioned, cluster inventory is one of the main topic of open cluster management. Fundamentally, you have to think a single pane of class that show all your managed cluster. The managed cluster has to be registered. So open cluster management doesn't come with something that create provision on the cluster for you. But you can create a cluster. A recent Kubernetes cluster is enough to be registered. Normally to register a cluster, you need to do some operation on the managed cluster. And the main paradigm that is behind open cluster management is the pull mode. In the sense that is the managed cluster that get in touch to the control plane that from this point on, we are going to call the hub. That is the name of the control plane. So there is this model that is the hub that handles the managed clusters. So as soon as your cluster is registered, a managed cluster now is part of the fleet, you can start to deploy your workload using this API, which is a customer resource, which is a plain customer resource Kubernetes, which is the manifest work. Basically, it's just a resource that wrap other resources in the slide. We tried to show something. There is the manifest work. Hello work is just deploying the namespace work and a deployment, a standard Kubernetes deployment. One of the cool features of the manifest work is that he's able to return the status of the resource and state, not only the status of the manifest work, but also the status of the resources that he deploy. This is done by the agents that ran on the managed clusters. That is the way it was cluster management at the moment. Now, where open cluster management implement what in the upstream Kubernetes environment is called namespace sameness. This is a best practice that is, and the community converges on this best practice, but is industrial considers a good approach in the sense that a namespace has to be the same across the fleet. So if you have a database, for example, that the namespace that is called a database, it has to be the same in every managed cluster. And even if there is a cluster that does not, doesn't need to have the namespace or we cannot for a regulatory reason cannot have the namespace, in that case, you have to prevent the deployment of that specific namespace. How is it done? Is it done through an API that is called the manager cluster set, that it has to be bind to a specific namespace through another CR that is the manager cluster set binding. As soon as you have a manager cluster set, you can start to select or repel the cluster in that managed cluster set through standard way label and selector and taints and tolerations. Labels are standard labels that you can apply on each Kubernetes resources. Taints are a little bit different, but there is a one that is pretty cool, is the claim. Claim is the ability on the manager cluster can say, okay, I am this cluster, I can support this step. For example, think about IP address that are free or big storage volume that are bigger than other cluster and so on. So the manager cluster can declare a claim and you can select the workload to go on those specific cluster with that claim starting from the hub. As soon as the placement is ran, the placement decision, which is another customer resource, is generated and in the placement decision, there is a list of cluster that can run the specific workload. As soon as you have the status in the placement decision, you can decide to schedule across the group of the clusters the specific workload using a strategy. There are three kinds of strategy. At the moment the API are still very, very young, at least for the rollout strategy. So if you want to collaborate, this is the time, this is a good time to come and help in the community. That's all. That's all what I have for today. Don't hesitate to come and see us at the kiosk on Wednesday afternoon. Thank you.