 Hello, everybody. I'm Hong Tai-Ren from Huawei, and my GitHub ID is Crimbo-Mango. Maybe you have to manage multiple clusters to support development, testing, and all kinds of business. And maybe you are using CNCD2 to handle that stuff. Today, I want to show you a different system that will make this thing easier. With the system, you can use and manage multi-cloud just like a single cluster. You don't need to change your infrastructure, and you don't need to change your application configurations. The system is KMata. It's an open-cloud native and multi-cloud orchestration engine. The KMata project aims to offer ability to easily use and manage multiple clusters. People use multi-clusters just like a single Kubernetes cluster. Before the demo, I want to give you a quick overview of the architecture and the main concepts. The main components of the project include KMata API server, KMata controllers, and KMata scheduler. The KMata API server is essentially a Kube API server, so people can use Kube control command or client go to access it. KMata API server used to store users workload configurations and KMata API objects. It checks ETCD as a spec end. The KMata scheduler in charge of select clusters for resource template according to policy APIs. The KMata provides several APIs that are implemented by KMata controllers. The cluster API that is implemented by cluster controller provides a representation of the member cluster that is registered to KMata. The propagation policy API that is implemented by policy controller provides a representation of the rules where the resource template is through the propagation tool. The resource binding API that implemented by binding controller is an internal API which binds a resource template and a list of targeted clusters. The work API wraps a resource template. The execution controller will apply resource template to member clusters. The override policy API provides a Kube API ability to override resource templates before they propagate it to member clusters. Here is an example of a propagation policy. It represents a policy that propagates all deployments that labeled with multi-zoom replication and the targeted clusters should locate in three zones. Here is the example of override policy. It represents when a deployment should be propagated to clusters with label reading DC1. The KMata controller should replace its image registry. This is a resource template example. Don't be surprised. It's exactly the same YAML that people applied to Kubernetes. People can use kube control command to apply it to KMata API server. Okay, I'm going to show you how to join cluster to KMata and then apply a resource template and then apply a propagation policy to KMata. To the last, we'll see how to check status from KMata. Here, I prepared a KMata system and a Kubernetes cluster named member1. Okay, let's register the member1 cluster to KMata. Before we join the cluster to KMata, we should set kube config first to point to KMata API server. We can see all the API that is stored by KMata. Here is the cluster resource. When we join a cluster, KMata will create a cluster object for it. Now let's join member1. We have a KMata control command. We can use it to join member1 with its kube config. Yeah, let's check. Yes, the cluster has been joined. We can see the version, mode, and status. Here is a mode detail status of the member1 cluster about all API enablements and node summary information. Okay, now I'm going to deploy a propagation policy. Let's see the policy. The policy shows that it will deploy a deployment named injects to cluster member1. Okay, let's apply it. Yeah, now I'm going to deploy a resource template. Let's check. It's a simple deployment. Now, before we deploy the deployment, we can watch the deployment on member1 cluster. Yeah, first to export kube config. Yes, that's what we expected. Yes, yeah, let's apply the deployment. Yeah, after we deploy a resource template on the KMata, if there is a policy matches the resource template, the resource template will be propagated to member clusters. And after that, KMata APS KMata will collect status from member cluster. And we can get cluster, get deployment status from KMata. Yeah, after that, if we delete the deployment, the resource, if we delete the deployment, the deployment will be removed from member cluster. Yeah, okay. Thank you. That's the demo. Okay, that's all. Welcome to try it out by yourself. And if you have any questions, please feel free to contact the maintenance by the GitHub issue or Slack. Thank you. Bye.