 For this sharing, I am Jiaxin from China Mobile. I also have a partner to join me for this session, Mr. Lu Bin from ARM. Currently I'm responsible for two parts. One is Kubernetes. And now I'm a member of Kubernetes. The other part is for secure computing. So today I will focus on these parts, which is based on Kubernetes and ARM platform. What are the potentially future applications? Also, we will know the needs of edge computing and also why Kubernetes fits more for these scenarios. So before we officially start, I will make a survey among all of you. How many of you sitting here work for IoT related design and R&D? Raise your hands, thank you. So the following up question, how many of you use ARM? Only ARM, purely ARM, or any other platforms to be integrated? So when you develop IoT, do you use ARM platform or the other platforms? So you're still on the upper end for edge computing side. I just delivered this in 6.07. So I will share with you about this again. In terms of the operations, operators, the edge computing relating to two parts. One is the network side edge computing. Another is the onsite edge computing. So today we'll focus on the onsite in terms of how to architect your cloud and what business will aid shoulder and how to reduce the cost. So first of all, I will anchor the onsite. Great edge computing. In terms of IoT, what problems will come across in our industry? Actually, this is very clear in our sector. We cooperate with lots of enterprises. Now they're building smart city and smart buildings and also smart factories. A lot are based in the parks or campuses. They actually don't want to enable their workflows to flow out of their parks and campuses and we cannot control. So in terms of industrial scenarios, their protocols are ICANN or their independent or the private protocols, not the IP protocols. So these protocols are not fitable for putting onto the cloud for management. So what should we do? How to integrate these capabilities on our industrial gateways to transfer the protocols and to connect the protocols. And we can take the IP flow. So this is a new cloud scenario. And we need to integrate all distributed machines for better administration. This is our first need. And also low latency. A lot of people will talk about the deployment of 5G. After this rollout, the latency has been reduced. But when we discuss with the industry, they have not very high requirement for latency but very high requirement and need for the distance. At your home, we gave you a cable and you can enjoy the video. The traffic and speed varies out and also you can enjoy this. But if we offer the internet service for the whole building then sometimes the speed will be reduced. Broadband, bandwidth, no problem. But the speed has problems. So which means if nobody uses it, latency would be very low. But if lots of people use it, latency would be very high. So can you compare this as low latency? Yes, actually it is. But in terms of industrial scenarios, what they require is to control the time within 10 milliseconds. So if you reach 11 or 12 milliseconds, your system will break down. And they do need this distance-based latency, low latency. So for the outside devices, if you will manage them outside, how to provide better distance-based guarantee. In terms of standardization, now we're promoting the TSN networks for the corresponding low latency investigation. And also the data volume and the bandwidth. So the data volume has exceeded the bandwidth and we have millions of levels of the quantity of devices. And also the wide-area network connections are not reliable and very expensive. So in your home, sometimes we will buy this Moscow set-up server. Within it, we will put our own HD video. No need for ROM. Run it on the operator's network to play the video. No need to occupy the bandwidth. Also take this from the cost perspective. Assume we have deployed our services on the network side at computing. According to the pattern of the public cloud, you need to pay every month for connections. And you need to buy the storage. Every month, you need to pay a bit of money, 10 yuan or 20 yuan. Not sure, but you have to pay. Or you need to pay through ITE, monthly membership, or you buy a device printed at your home to provide very stable video service for you. And now lots of people are trying this. Or you buy a USB yourself. The cost is 40-50 yuan. Or you can purchase the other devices. So the users need to balance because edge computing focused on the cost orientation instead of the technology. So on-site will also show the loss of the value to serve. And also in terms of information safety relates to personal privacy data and business data. Very sensitive. And third-party apps. And third-party programming designers. Now we have lots of pilots. More than 90% scenarios are private based in campuses and parks. China Mobile can provide us the 5G infrastructure but the traffic will not go out of their parks. So for consumers, they're still using their own private cloud and their traffic are not exported. So very safe. And in lots of vertical sectors, this is their need because in the verticals, migration to cloud is very slow and also with the edge computing, we will come across similar problems because edge computing will come across similar problems to the cloud computing unavoidable. In terms of safety and security because for the public cloud, a security problem is different to the private. If we offer them the gateway or server services, then their traffic will not be exported out of the parks and they will be connected to the container. And this fits better for the market. And also self-made, local, fits for offline operation and on-premise, independent management, administration, higher reliability because it intrinsically has this self-made attribute. We don't want to... Enable our gateway to go through the breakouts so we don't want to influence maybe thousands of the IoT machines. Otherwise, edge computing would have no value. So edge computing has this self-made attribute and persistent. Lots of people might have lots of solutions. That also can be used. But if the network comes across problems because the reliability of the edge is lower than data center, sorry, what I mean is the reliability of edge computing cannot reach the reliability of the data center. So it's lower. So when we have the lower reliability we need to consider the on-premise management. Which means I am kind of a weak management or administration. We need to upload the data according to needs. So this is the kind of a weak connection with the cloud. Another part is hardware config. Recently, Raspberry Pi just launched the Raspberry Pi version 4. Very good product. Raspberry Pi can run ARM's container. This guy is from ARM. Now the ARM architecture is based in terms of IoT. It has the ecosystem and better than the other systems. And lots of phone run their architecture based on ARM. Another part is machine learning big data. Maybe you have your confusions. On the edge, the data is very small, limited. But you want to use it for big data processing based not like this because in AI and big data we have reasoning and learning. In terms of training and learning, for training specifically, we still think that it's reasonable to be put into the data center not in edge and not in the cloud of edge computing because of the precious resources. So what can we do? Reasoning. We have the models very ready. And we can input the models into our phone or the data center of edge computing. So if we have the video streaming we can use a model to process it directly. And then back end we can modify the model. So in terms of edge computing we have the AI and also on our phone we have the identification services or the image identification relating to AI. Also here, cost is a concern. For example, of course maybe my deep diver not very clear. Say we have a manufacturer from Hangzhou based in Hangzhou they work for a camera. The cost or the price is 2,000. Their camera price is 2,000. And they can provide face recognition service which means when we collect data we have provided identification or recognition services for your face and the accuracy is 60 to 70 percent because the chip processing capability is very small within the camera. After processing they need to migrate the traffic into the edge data processing center. This is one mode. Another mode is they only provide camera maybe only 40 or 50 yuan and for the information capture and they directly export the traffic into data center. In the future with the edge computing 5G there will be lots of traffic maybe for free. So what they should do is to rent the edge computer VM or CPU to process the corresponding face recognition information which means these are two options for them. So in terms of the manufacturer perspective I want to sell out more and the price higher but from the holistic view the camera will integrate lots of the AIs on the camera. This would be dependent on the integrated cost and price of our solution because you buy a camera the cost would be only 40 to 50 yuan and if you integrate AI applications on the front end the camera would be 2000 yuan but on the road on the street in the intersection you need about 16 cameras so the cost is very high. If we offer this cloud service on the remote end maybe the cost will be reduced because the payment method, the charging method now is not set yet so we will take parallel ways and now we need this infrastructure augmentation to improve the capability of Edge in order to expand its ecosystem. This is CNC enough and edge computing. What kind of a connection partnership have we forged in lots of the open source projects you may find the Kubernetes project. Why we have this? Because in the current Kubernetes environment all nodes are arm and mouse these scales are very small maybe dozens or hundreds of. Lots of topics today will show that we are responsible for maybe thousands of clusters but actually there are nodes quantity very small but on the edge sorry I will skip this part the Kubernetes architecture. On the edge the devices quantity will increase so how these devices work as a Kubernetes nodes to have better management you can see here there are lots of devices and we will have Kubernetes controllers etc but actually very hard to manage very hard to install for IoT device this is too large as I mentioned before lots of problems including communication so it will come across all these problems we can go through Kubernetes to standardize these devices and to manage them all and to manage this as the gateway to provide this to the customer next my colleague Lu Bin will come to stage Thank you Jiaquan while my colleague mentions that the smart cities and other smart projects with IoT would bring us some challenges and one of them is that through CNCF can we manage so many IoT devices so let's have an overall review of them well actually it is already up to the industrial standard and we are thinking about using Kubernetes to manage all of these infrared and Bluetooth devices for example your Bluetooth speakers and your infrared ACs to be all managed with IoT then let's look at the architecture for the Kubernetes Edge this is a very typical Kubernetes architecture master level, master level architecture and maybe in the future we can see many big changes on the master level and this one is a very typical master level architecture and as Jiaquan mentioned in the future our IoT cloud would be all supported locally and the current master level architecture is not visible for that if you remove the cable network cable here then on the Edge the slave 1, 2 could not support and it could not select or communicate and synchronize the local data and another slave would be on the slave end and there are some co-progresses three of them, the first is about Kubernetes and the second is about CNI it might be about Frankel or Kanako and the third would be Kubei Proxy which is about Service Discovery so these three co-progresses would be critical and if you go to check their memory footprint you would find them very high and for the gateways for IoT they would have very small, limited storage so these three co-progresses are like there are changes in Kubernetes and we would remove the unnecessary service and applications but still in each of these progresses the corresponding modules should still include network Service Discovery and container management and they would all be updated respectively for example for CNI the Kubei Edge would be updated to a distributed CNI or as Jaquan mentioned here, about information security the secure networking would be important in Kubei Edge the network is not only distributed but also secure with a VPN channel and of course we need to realize the autonomy of this Kubei Proxy system and in the Kubei Proxy and in the KubeNet they should all realize the Edge Note communication which is distributed and also to have some selection to synchronize the data not only on the API server on the Masters so this is the current Kubernetes architecture for a huge IoT cloud in the future if you include the device discovery into it maybe the Kubei Master Management would be probably up to millions of devices but if you use Kubernetes to manage this IoT cloud what challenges may we have but this slide is about its main advantages at present Kubernetes as a container orchestration it has a general application abstraction and about the dual-cube company which challenges Kubernetes as I said the IoT cloud would be totally different with our traditional data centers so the first challenge would be about limited resource and it means that the gateways compared with the server level hardware would have limited resources for example vulnerable CPU and limited storage and the second challenge would be about restricted network which means in our data center we may use Kubernetes to manage our private cloud but in Kube Edge the APSO may be in the machine room of China Mobile for example and the gateway is in your community, in your neighborhood it might be your home routers or the exchanges in the buildings but they should communicate with the certain Kube master and it will be through internet but the latency would be severe and it would be very highly cost and it is not reliable so it may cause a very long delay or even interruption and then about the local economy we know that in Kubernetes, each could slave node would have a local cache and it would have primary data communication and in the IoT scenario because Kube master is not reliable it is likely to be interrupted at a certain time point and at the cloud and at the edge it could not communicate normally so can we let each edge to discover their frame edge and to have the primary data communication then and also to discover the primary data with the new labels and update together this is about the local economy and then about IoT device discovery you know that in the Kubernetes cluster it does not support IoT device discovery if you use the Xiaomi device you may know that we could evolve a lot of Xiaomi devices into the Xiaomi system and fear it is similar, we could evolve a large number of infrared GKI or Bluetooth devices into the gateway could send it as a primary data to the Kube master and then in the China mobile machine rooms Kube master it could have an overall management of these millions of infrared and Bluetooth devices and then concerning Kube edge it is now under CNCF an open source project and for the time being Kube edge is based on Kubernetes 100% compatible with Kubernetes API and it has customized edge node components and runtime so for each slave Kube net and Kube proxy would be replaced with edge core in a distributed manner and it has a reliable messaging pathway, it means we have a pop-up for registration of these Bluetooth infrared devices and for our internet devices or home hardware we do not want to lose them so we have a reliable pathway for them we also have an edge offline on autonomy, it means at any time point it could be interrupted by the Kubernetes and it could also have the real-time synchronous updating with their corresponding nodes and we also have a very enriched application and protocol support to support all types of devices and it also has a simplified device on access and then let's look at the overall framework for Kube edge from the application perspective for Kube edge its application would be very simple and on the Kube master there is an edge controller and at each slave it adds an edge core memory footprint of edge core compared with the 3 core progress on the Kubernetes slave it is much more streamlined and could be run on the 100 MB gateway and for the edge controller it is on the cloud and it could synchronize the edge nodes and the application status for service to the primary data and it could introduce the abstract API for example for infrared devices or for Bluetooth large speakers it could have this abstract API of the devices and the edge core is also exclusive for this IoT system with an extra device discovery function this is discovery of the devices and we also introduced edge core which means on each slave there is an edge core to manage the application on the edge nodes and to realize the runtime for the pod which means it is a very lightweight Kube edge and then for this which is like the core or the soul of Kube edge and we need to pay attention to four things the first is edge hub and then the meta-manager the meta-data service and then the edge D, a mini Kubernetes and also MQTT which is for discovering devices and for MQTT we could pop all the discovered devices onto the master and then let's look at these four modules one by one the first is Kube bus which is like a CNI plus Kube proxy in the Kubernetes which is like a channel for distributed routing and VPN offering a secure network and then for Kube bus it has the following important functions first through the VPN channel it wants to connect all the edge nodes and for each edge node it could at least discover another one and the second function would be to guarantee the communication between edge node and cloud and the third one would be about discovery of the service which is similar to that of Kube proxy it is like the load balance and then about the meta-data service on the edge because the edge node would be connected with the cloud through internet which is not reliable with a very narrow bandwidth so for meta-data it evolves the following important features first this service is quite non-lasting if the connection between the edge node and the cloud is recovered then it could be synchronized to the edge cloud and because of the narrow bandwidth and instability of a high cost of internet then the synchronization is in an informative way it is not as what we used to have it is to synchronize the increment in the recent time period and the third would be about the decentralized meta-data service as we mentioned for KubeBus it could make sure of communication between the relative edge nodes and if here the edge nodes could be selected by their relative edge nodes it could be synchronized and then about the discovery of the devices for Bluetooth devices it is okay now so for the time being on the ARM platform including ARM 32 and ARM 64 Kube Edge it is available and you could download it and try it on the ARM platform and then for the Kube Edge we still need to further some key features like the unified management of the cloud edge the config map and more device recovery should be involved as well and the road map is here and you can have a look at this for each edge node each edge core could completely simulate a slab function and on the KubeBus master you can see it's 100% IPR compatible and it is not different at all from normal slabs and this edge core progress is very critical in the slab can I zoom in so that you can see it more clearly at present as an edge node its behavior is totally same as that of a slab on the edge node we can even deploy an edge TD symbol in this example we're using a node pod so ARM currently now everything is ready for the next step we need to introduce new features so this is the end of my presentation and our demo, any question? sorry the interpreter didn't hear the question because there's no microphone the Kube Edge is like to distribute the 3 core progress on the Kubernetes and as I said the core thinking here is about the synchronization of the metadata by their increment one is it's also connected to the cloud yes because I said the KubeBus is like a CNI and Kube Proxy and it adopts a VPN channel and it could make sure the master slab and slab slab communication and it also has a load balance and service discovery function so as to make sure local autonomy and the relative edge nodes could select and synchronize their metadata you mentioned the relative edge nodes but for the millions of devices maybe an edge node would also be up to millions of Bluetooth and infrared devices in the D2I farm platform what a heater, your Bluetooth loudspeaker and also your air conditioners at home actually the million level of a gateway would be less in order of magnitude than the edge nodes while you mentioned in one of your slides about the features of edge computing maybe in the first slide and it mentions about information security and I would like to know that when you use edge computing in information security do you have any specific use case while as I said the KubeBus would offer a VPN channel to make sure of the network security and then this could be about the long time we now have kata and gvisor and kata is ready on the arm and tomorrow I'm going to talk about gvisor on arm I have another presentation on that while I understand that some devices may contain some sensitive data and maybe it could run on the nodes or locally can you use your platform to deploy the home architecture yes maybe you can make it a new feature and in our group you could initiate for more discussion involving more people it may involve the security design and have you compared edge x together with gateway yet not yet we can regard edge x as the fundamental operation platform before we discuss this with their operators kubernetes can work as the coordinator on the cloud but edge x is a kind of carrier on the edge on the edge sorry I have used up my time I personally think that kubernetes thanks for this