 Hello everyone. Welcome to our presentation and I'm Nguyen Tan Huy. I come from the Vithal Group and I am a Cloud Solution Engineer at Vithal Group. My colleague is Nguyen Sihil but for some needspan reason he couldn't be here. And now today I will talk about the topic implant of the software to support the cloud infrastructure needed by a cloud provider community cluster. And my presentation has been the first one year of view, security problem, the next solution for implementation and the last one year value. Let's start. As you know, Q&A is a complex piece of software. Provisioning and managing community cluster is a challenging job to installing, configuring all the components of a community cluster such as Cubeless. Scalular is a costuming time when you do manually. It means the situation when you have to manage hundreds of community clusters. Provisioning in pro-processing environment and day-to-day to operate a cluster can be so tedious. Although there are some tunes such as QVDM but it can manage full lifecycle of the cluster and here is cluster API is a QVD sub-project and started by cluster lifecycle 6. It's a, it's a really collaborative API that can be used to manage the lifecycle of one or more community cluster. Next, let me see a diagram of the component of cluster API. The way cluster API works is separated into a provider and what the provider do is that they have to make very modular. So that means you can plug in different infrastructure and different bootstrap machine. So we have the core cluster API controller is a core cluster API. It's managed, it includes the API lifecycle logic, solar, all the lifecycle management is a operating, rolling, update a machine, all that. Then we have the bootstrap which is how to join a node, join a node in the QVD cluster. Cluster API comes with a built-in bootstrap provider, so bootstrap provider based on the QVDM project. When we have a, then we have the infrastructure provider where you have your different infrastructure like environment, environment clouds, anything. For example, cloud, you have a Azure provider and AWS provider, parameter provider, etc. As a last, we have controller provider which are responsible for managing control plane machine. Managing can mean updating control plane machine, make sure the community components are just scattered already. As the core API includes our custom resource definition, custom resource definition, built-in resource that let you, you can extend the QVD API. So cluster API provider can provide API on some custom resource definition such as machine, machine sets, machine deployment. So I want to describe the overall architect of the previous virtual cloud system before get into the middle of the matter. So architect consists of three main models, cluster management platform called CMP, the QVD provider and open stack. CMP as a management model, community directly with the user to UI and receive the request and send this request to QVD provider. Next, QVD provider is a centralized management model that impacts the QVD cluster. When receiving a request from the CMP, QVD provider will send this down to the open stack to create QVD cluster. Based on the cluster API provider, open stack solution to create QVD cluster unit to create numerous other resource such as global server, but the information of the component is stored in the open stack and open stack is your private cloud. So the CMP can get the information about the the resource created below the open stack. So when user send a request to create QVD cluster, the request will be sent to QVD provider and it is to send to the open stack. And here is the network model of our architect. SVM of user cluster will be plugged into true VPC. One VPC is a user VPC and the second is provider VPC. For the request that requires to go out to the internet, they will go through a router and go out the internet. And for the request that requires administrative and interaction with the open stack, it will go through the provider VPC and to last browser, the API server must load. We use a load balancer attack to VPC and expose it to the internet through a frapping IP. So our architecture is resolved in some problem later. The first server like transparency of our system. When customer has a destructive behavior, it's harmful to the system such as they release a resource, apply a fire jammer, we can know and customer can completely completely blame the supplier. Additionally, it will take a long time to determine which resource is having a problem. When they are in issue with the client infrastructure, which impacts the customer experience and the customer will not be satisfied. Another consider issue is likes of information. When a client send a request to create a community cluster and the system dies successfully. All they receive is a notification that the cluster has been created successfully. The system can tell which resource are being created accordingly. And the customer will be able to update, revive, estimate, develop in the timely manner since they don't have the information about the and from that the third problem is the calculation of the cost of using customer. You cannot know what they have paid for and another issue is a complex network model. The issue affects both the customer as well as the provider. And I will talk about our solution. And instead of using cluster API provider open stack, we custom and desire plugin named cluster API provider with help. So plugin can go to the CMP to create a community cluster. Our CMP can create resource similar to open stack as is our new architect. Use the send a request to create a community cluster to UI. The CMP receives the request and send it now to community provider. And then it will go back to CMP to create a related resource to the cluster API provider. And the information of the resource used to create a cluster such as the balancer server will be stored in the CMP and it can push to the user to UI because it's possible to show the customer the information of the resource created. And this now is here the new architect model network. It's the end of the user cluster plugin user VPC and for all the request to do in the internet or connect to CMP API to a writer and we still give the balancer to the API server master node. And to custom cluster API provider detail we follow the cluster infrastructure provider contract of the cluster API. And the machine infrastructure provider contract of the cluster API. We have a defined detail cluster, detail cluster template, detail machine and detail machine template. In the API tie we add we add the field spec and standard. Spec field is the defined the standard and the standard field. We define the option standard. In the API detail cluster tie we have spec field control plan and point. It's the endpoint for the cluster control plan and other object. As at the standard field we have a required field ready. It's able to indicate the provider specific infrastructure has been provided. And in the detail machine tie we have spec field provider ID. It's an identifier you add the provider machine instance. And at the standard field we have required field ready and other optional field such as follow reason, follow message. And we have defined process here called reconstruction. So provider must for new update and direct result and respond accordingly. So we have a row based asset control. It's a, okay, in more detail. We define for main customer definition is the detail cluster, detail machine, detail cluster template and detail machine template. At the detail cluster we have defined the component of the detail cluster structure. So VPC, subnet, reason, localizer, security group, listener, API server port, control plan and point. And in the detail cluster we have defined the detail cluster spec and detail cluster standard. And at the detail machine we have defined a component of detail machine such as server, reason, image, volume, size. And the detail machine template, it have the cluster API provider detail can integrate with other cloud provider. So it's the state transition when you create a machine. When machine creates a virtual provider, what's the machine in pending status. And machine controller set the data script name from virtual config. As I said that is provisioning. So infrastructure pro, infrastructure provider start to create infrastructure for machine. And when machine infrastructure is ready, it's set the state of E ready. It's like state of E provisioned. And when the state of machine infrastructure ready and the machine controller you set the machine state of E provisioned. And now when it's the controller of our cluster API provider detail, when cluster API provider detail run, it will run to concurrent record size stream. It's a cluster and machine. So cluster record size stream will create a cluster infrastructure ready. And the stream of record size machine will wait for the cluster infrastructure ready. At the record size of cluster, we will create a VPC, create some net, create a robust and another other object. It will as well the cluster infrastructure ready. It will set infrastructure state of equal to and cluster state of equal to. Then the record size machine will start to create the object. It creates volume, creates server and loss balance, loss balance member and another object. When the older object is created, it will set the machine state of infrastructure equal to. And the state of E provisioned. So the new solution has been brought many benefits to our platform. It can provide sufficient information to user when user send a request to create the cluster. And all the other information of the relative result can put to the UI. So the customer can see all the information. The second is it will solve the pet problem and customer will know what's the next. So new solution will as well just transparency for customer system. And the last it will increase the experience when they use our cloud. Yes, thanks for your attention. Anyone has a question?