 Good afternoon, I am Zhang Yifei from Alibaba, and I will share with you how do we build the serverless by using K8S module container and the bare metal cloud. So there are three parts, the first part is serverless overview, the second part is the serverless platform and the third part is about the Kata containers. So before I talk about the serverless platform, let's look at the status quo of the serverless and what kind of challenges we are facing and how can we address these challenges and how can we construct space for this platform. So the status quo first, for development, the first goal we need to collect the requirements and then we enter into the development base and then we have test, deploy, operation. During all these different steps, we need to see very much maintenance, best practices, effective iteration and quick response. So these are the issues that we need to bear in mind during the whole circle. For example, maintenance, we have development, development maintenance and also the deploying development maintenance and for best practices, you have to develop according to the usage requirements and also you need to have an effective iteration. So how can we have a quick response for each iteration? You will find that the development logic will take less time. So the environment maintenance will take longer time and the best practice for development and cost reduction will also take a long time. So here we have two main problems. One is the high cost of operation and maintenance. Second is the high cost of development. How can we solve these two problems? So normally we have two steps. The first one is to have the definition and the second we can use the solution and to working towards the goal that we set during the development phase. So the definition of serverless is a cloud computing extension and the cloud providers will round the server and also manage the allocation of machine resources and also the users will pay on demand or on usage. It has three core features. So the users no longer need to care about the server and the second is to pay on demand and the third core feature is the elastic scale. So the user do not need to worry about the server so they don't have to worry about the O&M cost reduction. And also the elastic scaling can reduce the development cost. So for serverless there are two roles, user and customer. These two roles can help us to understand better about the serverless. User do not need to care about the server and they pay on the demand or on usage so they don't have to pre-purchase some capacity. And also the user can enjoy elastic scaling or auto scaling. For platform they need to provide resource pool services as well as on demand, and also platform provides auto scaling services and secure data services. And serverless also has scenarios for the scenario applicable including event driven costs. And on the tasks. And also delay in sensitive tasks for scenarios applicable. One is start delay sensitive tasks and another one is processing delay sensitive tasks. These two are not applicable for the serverless. So now we have an overview of serverless. So how can we construct a serverless platform? Serverless is to address the O&M cost reduction. And also we want to reduce the development cost by using serverless platform. So we have three core challenges in order to address these challenges. One is secure, cost and performance. And secure is to prevent non-legal access. And cost is to reduce the platform O&M cost. And further reduce the operation cost for the user service. And performance is about the user get done. So we need to satisfy the user demand. In order to address the three core challenges, we can use the multi-tenancy to improve the resource usage rate. And also to operate multi-tenancy service on the platform to reduce the access risk between different tenancies. So for multi-tenancy, it has different dimensions. So when we list all the dimensions of the multi-tenancy, we will have a better targeted solution. We have first dimension strong isolation. So strong isolation has another solution. One is to supply the other one is for data playing. We have to prevent the non-legal access, which includes the runtime and also the network isolation for control playing. We need to manage the API call. And so the other tenancies resource cannot be seen by managing the API. So this is for the strong selection. And also we need to satisfy the interconnection between the cloud services. This is the second dimension, the third dimension for multi-tenancy performance because they might affect each other between the multi-tenancies. So from launch and operation, we need to satisfy the multi-tenancies demand. So data playing, interconnection, launch and operation are the most important dimensions here on this. Therefore for serverless platforms, I think we will focus on the data playing, interconnection, launch and operation. So roughly I will introduce the solutions for the performance. We use elastic bare metal instance. This is a new type of service. So it combines both strengths from both physical and virtual servers. So it can do rapid scaling and it is very elastic. And also it also has the same performance as a physical server. And for strong isolation of network access and interconnection, our solution is VPC network. Different tenancies VPC is naturally isolated and in default model. And strong isolation around time millisecond level creation, we use secure cutout continuous to guarantee. So there are some details. Because in this you can see we rely on KAS to achieve orchestration. So to base on the resource applied by the tenant or the users to do allocation. And in KAS we have this idea of numerous namespace. Namespace it emphasizes the logic of the logical isolation of resources. Now think back about the tenants and VPC and this relationship. What is the mirroring relationship of these three tenant, namespace and VPC? So you can see this is the relationships. So this is our concern. So on every tenant they have multiple KAS namespace. And for every KAS namespace is one to one to VPC. And for VPC for every one VPC you have numerous KAS namespace. So this they can control the complexity of building this platform. So let's look at an instance to see how this relationship is represented. So here you have tenant A and tenant B. So for every tenant they have different namespace. And for every namespace is one to numerous in relationship in terms of VPC. And for VPC they also responded to multiple namespace. So to build a serverless platform we have solved the core challenge which is the multi-tenancy issue. And we know how to solve which dimensions to solve. And meanwhile we know that for one serverless platform we know the relationship and how to design it. So after we solved these two core issues we can look at the serverless platform construction, the basic architecture. So you can see at the platform level it is KAS based orchestration ability. And then we can put it in three different EBM poles to achieve the higher utilization. And we also maintained this resource pool which is based on elastic bare metal instance. So on every node you have multi-tenancy services. And these services are at operation level isolated through containers. And the strong isolation and interconnection is down through VPC. And you can see this is also you have like a virtual network service to support all of these. So basically the user can control the data flow and they can also use SLB to access. And also under the same SLB the services on it can. So this is the logical description of a serverless platform. There is also a key solution which is security container. So my colleague will introduce the secure to container. My name is Hua Wei, I have ILE Cloud. So my job is on container D and secure container. I am also a reviewer from container D community. So I am not going to talk about Cata containers. ILE on network operation and maintenance what we do. The serverless platform based on Cata containers. So this is an illustration I get from Cata website. So I will start with this to talk about what Cata is. You can on the right, on the right hand. So on the base layer it is a hypervisor. On the framed part is a VM. You have guest kernel, you have agent. And that agent is actually the thing that responsible for the true lifecycle management of the container. If you use Cata, so this actually runs on a VM. So and then you have Docker approach to hand down the directives. And through the blue part it is a VSOC. This VSOC is talk to a cumule. And you can see that this use a cumule. We can use VSOC it or other like Cata proxy to communicate with cumule and send the directives to the agent. And it will create a container on the VM. And actually this is similar to Run-C. On the VM you operate, you use Run-C, but it doesn't actually use Run-C. But the logic is the same. It use agent to create a container. So Cata container then naturally supports pod. So a VM is a pod. So all the containers run on this VM. And this is how Cata works. On the left hand it is Cata containers how to connect, how to respond to the upper layers of core. So we use Kubernetes. So on the left there is Cata-Shen V2. Cata-Shen V2. And it is what the Continuities community design design kind of interface. So this interface create a star stop. So interface that is relevant to containers. So V2 this interface. Actually before in Continuities, we call it V1. Because as a beginner you only have Run-C. And then you have Cata, you can advisor. So that's why the community people do update this interface. So now it also supports Run-C. And also for this interface So this is the native architecture. So originally you can see we also use V1 interface. And I will introduce the red block which is the shin part. So for this part I will focus some of the updates we did for Cata while we shift from Cata-Shen V1 to Cata-Shen V2. You can see for the V1 we have like a 1, 2, 3, 3 element or component. So if you use one Cata container there will be three binary codes of components running on it. So if it is too many that means when you stop the container there could be some leakage. On the other hand on the Cata-S there is also a withdrawal issue. So in V1 you cannot achieve it. So this graceful exit. So for Cata-V1 they do not have the binary to preserve the status quo. So when the container stopped function and if you cannot queue it and maybe they will send a sick queue signal. A sick queue can queue all the process. But for V1 they cannot do it because they don't have a long-term running binary. So it cannot perform the graceful exit. But V2 can do that. So that's why our platform updated after V2 was launched and upgraded from V1 to V2. And also technical architecture we used. The dash line is the open source to connect KDS to container D. But we actually use Poch. Poch is Alibaba's open source project. So we can, which can provide more functions or performance than container D. And you can see these port are Cata port. And for the machines we use the elastic bare metal. And for hypervisor we use QMU. Hypervisor like AW at the ferrocracker is also a very lightweight technology but it's not usable. So we use QMU. Look at the network solution. So for VM there's two important parts. One is network and IO. And for network we actually choose Shenlong ENI, our elastic bare metal. They provide a very good service. And for ENI they provide a very good net card. And also for the different guest VPC are isolated at the network. So you can see for multi-tenancy network isolation. And so this guarantees the network's isolation and interconnectivity. And it is ENI based. And Cata choose direct net card. And for every port they have one ENI which is directed to ENI. So on the left is a tenant, how his network is connected. And on the right is Cata and Ronci. You can see four parts while it's clever. And the other is Cata, plus EN and a host. So you can see this solution actually solved the VM's network issue. This is IO performance optimization. So Cata's native Cata use 9PFS but there's a lot of issues. For example it is pool IO performance and also it costs QMe 10. And also it has a depth compatibility issues. So we have some technical issues. Maybe we need answers and questions before they solve these. For multi-tenancy we need to have an operation strong solution. Like Cata's security here. And secondly for networking we also need to have a strong isolation. We can use the VPC network. So one tenants can have multiple names fixed. But one name is Kriska only Kriska. There's one you can see. So maybe we can have some fun discussion and I can figure out my thoughts. Like Cata's they have some IoT apps or IO components. So like Cata's they have some IoT apps or IO components. So like Cata's they have some IoT apps or IO components. I need to find a console to help me with QMe 10. So I think that's my thought. QMe 10. So like Cata's they have some IoT apps and QMe 10. So QMe 10. We have two ways to connect to the graph driver. We have a, do you see over the B2, which is a graph driver, while in a kind of a terminal connected to the graph driver? And also, we have a device wrapper in the stable on 4.19. So it's about the one kind of driver. So you can get a QMMA, QMMAD, and then like the容器拉定像, it's like this. Every layer is actually a table, and I don't care what it is, I just pull it down and then I just pull it down, and then I just pull the data from the layer. So how can we decompress the disk and the data to connect to the graph driver? For this part, it's actually wrapped up into a snap shot. It's like, for example, we usually use Overlay, and then it's Overlay's graph driver. And then if you use QA2, you can use QA2 to solve how to put the compressed data into the QA2 and then this part is actually through the QV image. And then you can hang it out to create a QA2 document. Then you can make it to the file and to make its effects. Then you can use QNMV to do the QNMV. And then we can hang the QNMV out and then you can use thelayer to do... You can use thelayer to do the layer, and then you can dig out the compressed data. And then you can see the layers but for Overlay, So for one layer, it's a snapshot. It's a snapshot, and it goes from O2 each layer. It's a normal ID. This is a test with Andrews, and it reflects the character of I.O. Actually, it's I.O. Because Andrews has a lot of blood. When the blood is hot, he doesn't like to cover his eyes when the blood is hot. So he has to wear a mask. In the back, it reflects the character of I.O. The data of the test shows that the character is very bad. Through such a test, you can see the character of I.O. This is a contrast between the character of I.O. We will talk about the device network. This It's going to be slower than my selector. Next, let's talk about some of the things we do on the cloud. The main thing here is to talk about monitoring. Because the cloud's K-8 is currently monitoring some of the things we do on the cloud. The money seeker does it from the cloud to the seagull to read the data and then to get the data from the cloud. Because when you look at it, it's actually running in the virtual machine. So it's going to read the data from the seagull. So on this side, we've done a whole cloud monitoring. In fact, it's very simple. Because K-8 actually provides a platform and then we want to have a platform and then we'll do a matrix of a platform. Then they'll provide you with a interface that needs some interface. Then we'll go through this interface and then we'll go through the different runtime to go through. We can actually do it with Kata, and then we'll go through Kata to go through. So you can use the Kata to do everything. And then you can use the authentication to Kata runtime. And then it's going to continue with the state interface. So the state interface is actually going to be able to get the data from the virtual machine. But you can actually do different things in different runtime. And then this is going to be the platform that we're doing right now. And then we want to do it because we can do it for Kata. And then we're going to be able to use the multi-functional interface. And then it's going to be able to run to the runtime framework. And then we're going to be able to put it on C. But the previous theme part of this solution is going to have a lot to do with the runtime. And then the Kata part is going to be going to be supported. And then we'll do this for GFAS. GFAS is still a question mark. So because GFAS doesn't report the monitor data feedback in the GFAS, it does not report the GFAS. So what GFAS are doing is doing is going to scale the instrument bit. So this is some optimization that we have done on the Kata container.