 Hello everyone, this is Fupan from Ant Group and my co-speaker Wei Yang from Alibaba. Today we will give a topic about practice and landing of cart containers in Ant Group and Alibaba. First, we will give a short description about what's cart containers. Cart containers is an open-source community project working to build a secure container runtime that employs fast, lightweight water machines to increase container isolation. Cart containers act and perform like classic containers, but provide stronger workload isolation using hardware-virtualization technology as a second layer of defense. Now we can see that here is the cart container's key part. The cart containers are run in a water machine, and most of us will use the Q-Ming hardware as a water machine. Cart containers highlight about four features. First, it's about security. Cart containers run in dedicated kernel, providing isolation of network, RO, and memory, and can utilize hardware-enforced isolation with ventilation VT extensions. A second is compatibility. It supports industrial standards including OCR container format, Kubernetes-CR interface, as well as latest in water isolation technologies. A third is about performance. Cart containers will deliver consistent performance as standard linked containers increase the isolation without the performance tax of standard water machines. And last but not least is about simplicity. It limits the requirement for nesting containers inside full-blown water machines. Standard interface makes it easy to plug in and get started. As shown in the picture, cart containers bridge the gap between the hardware isolation of traditional water machines, and the speed and relatively small print of containers. For cart containers, each container or container part is launched into a lightweight VM with its own unique kernel instance. So, for cart containers, one container's bugs will not affect the other containers. So, from the description above, most people will think that cart containers are only suitable for untrusted workloads. Is that right? No, I don't think so. I think cart containers are not only about its security, it's also about isolation. The isolation from the latest in the efficiency and its results. For example, in Ant Group, there are about thousands of computer servers, and those computer servers are deployed or running about billions of services. And those services, some of the services are higher priority, but some of these containers will be low priority. If those tasks are running classical containers, for example, the R&C containers, as we know, the classical containers are there the same kernels. If a low priority container takes a critical routine, such as take a kernel logs, but at the same time, a high priority container or high priority task has something to run, it will try to get to the logs too. But at the same time, the low priority task has ticked the log. So, the high priority task can't get the log. This will prevent the high priority tasks get to run as soon as fast. So, I think cart containers can solve those problems. For example, we can run most of the low priority containers in cart containers and the high priority tasks in the classical containers. As we can see, the cart containers have three features. First, it's about resource isolation. The second, it's about common use. And last is resource efficiency. As we know, the cart containers are deployed as a machine as a key component. So, compared with the classical containers, it has a high resource isolation, and it also has a common use, but it has a weak resource efficiency. So, in Ant Group, we had done a lot of works to improve its resource efficiency. So, what we do to improve cart resource usage? First, we use the Rust VMM Hubvisor. We placed the Qmin Hubvisor. As we know, the Rust VMM Hubvisor is a little high-lit Hubvisor compared with the Qmin as a traditional Hubvisor. Second, we use the Rust language to rewrite the cart agent. The previous cart agent was written in Golan language, but the Golan language has a complexity runtime, which has a large footprint for memory. So, we use the Rust language to rewrite the cart agent. The third is we use the TTRPC to replace the GRPC. Since the GRPC is very complex, and cart containers only use the simple feature of the RPC. So, we think that there's no need to use the RPC here. Thus, we use the TTRPC developed by the container D community to replace the GRPC. And fourth, we use the VSOC to replace the VTL serial to communicate between the cart runtime and the cart agent. Last, we use the VTLFS replaced with 9p to share the container image between the host and the guest. As we can see in this picture, there are six key features we've done in Ant Group. Here, the previous used the GRPC, and here we used the TTRPC to replace the GRPC. And here we use the VSOC replaced with the VTL Serial. And we also use VTLFS replaced with 9p. And last, but not least, we use the lightweight Rust VMM hardware replaced with QMIM. So, with those efforts, we will get the benefits. The previous, the cart agent with Gula and the GRPC, the memory footprint of the agent is about 11 megabytes. But if we use the Rust agent and use the TTRPC to replace the GRPC, last, we got about 3,000 kilobits compared with the 11 megabytes. So, we got a very emphasis on the memory usage. In addition to the previous efforts we all worked with down in Ant Group. We also add an option channel to make our ops much more friendly. As we know, for example, if the cart containers had some issues in its guest, such as the kernel panic, or some issue, or something wrong, or the agent, there's no easy way to debug. But so, we add an option channel into cart containers that we will use our option tools to easily log into the guest and to debug the issues. The second is about upgrade for cart containers. Most people may think that containers there's no need to upgrade the containers, since they can easily stop the containers and as we know, it's the containers. But in Ant Group and in Alibaba, there are a lot of tasks, has a long run love charm, and it's not easy to stop those services. So, we have to figure out a way to upgrade those cart containers without stopping the services. Thus, we developed the cart sim v2 with the hot upgrade mechanism and the agent hot upgrade mechanism. Thus, we can replace the cart v2 and the cart agent offline without stopping the current services. Here, this is the big picture of cart containers deployed in Ant and Alibaba Group. The left side is about the tools such as monitor, logs, and enhanced ventilation. And the left side is about its compatibility, stability, and safety. All of those are based on Alibaba's X-Dragon material and it's run on AliOS. There are a lot of pieces or services running with cart containers such as the online services or offline services in Ant Group and Alibaba, and some mid-ware services, ad compute services, serverless or function communication, the big data communication, and offline tasks. Lots of tasks running in cart containers now in Ant Group and Alibaba. Okay, that's all. Thank you.