 Welcome to KubaCon Clonidicon North America 2023. This is our maintenance track for KubaEdge. Thank you everyone for coming. So my name's Indy. I'm the maintainer and one of the TSC members. So I will give some deep dive to the KubaEdge with our latest community update. So the KubaEdge project, the goal for this one is try to solve edge computing problem with cloud native approach. So we are guided by the cloud computing scenario, including the far edge, near edge, including the IoT device, also all the way to the CDN, the large cloud edge. So this will come consistent with applications, resource management, data, and device. So we just recently released our 1.15 release last month. So here is the release notes. If you have questions, please let me know. There is some updates. The detail, the link is there. And also, we are in four release every year. So we were following the upstream Kubernetes to four release per year. However, Kubernetes just updated two, three release per year, but we still keep the four release per year to give the community very frequent update to ensure we have all the things to catch up. So the KubaEdge is the first cloud native edge cloud computing the OSS project. We follow the open governance. Everybody are welcome to contribute. We connect the cloud and edge in the cloud native way. We are in the incubation space in the cloud native. We are applying to graduation after this KubaCon because every TSC member in the CNCF is in this meeting in this conference. So after this conference, the TSC member will initiate the cloud native community. So a brief history. So we initiated this process from 2018. So we launched our open source on 2018 November and we donated to CNCF. So after this five-year journey, we are applying to the graduation stage. So we want to be a graduated project in CNCF officially. So I'm going to give the project updates. So because this architecture is in our website, I have introduced that in the last couple of years. So basically we are doing same list cloud edge coordination. So one thing, the different cloud and edge is we achieve edge autonomy. And also for the edge node, we try to achieve low resource consumption. And also one important thing is for the IoT case, we simplify the device communication and we'll go a little bit deep dive in the following slide. And we're always following the open ecosystem. We'll come to everyone, every company to contribute to the project. So let's briefly to see the process we deploy apart in the edge node. So it's very similar to Kubernetes deployment. The different is the edge node is on the remote side. So supposedly that will have a low bandwidth and also the high latency. Before the Kubernetes edge, we were experiencing the difficulties we need to develop for either our OTA protocol to deploy the app to the far remote edge node or you have to manually send somebody to do that. So this project, the goal is to deploy application to the remote edge more cloud native way. So we can see it's very similar to Kubernetes deployment. So on the cloud side, you use the least and watch have a desired state. Then after you do the Kubernetes control apply, then the scheduler will see your desired state have the pod to deploy. So the scheduler will update the pod binding to the node. Then it will be in persist in the ETCD. After that, the cloud core is the new code edge part. So the edge controller will watch this pod update desired state. Then we through our protocol from the cloud hub to tell the edge hub to see, OK, we got the desired state update. Then edge core will communicate with the local deployment update the desired state in an edge node. Then the edge core is responsible for create the pod is similar to the cobalt. So you can see the pod creation is very similar to Kubernetes. So we are following this cloud native way. So as an application developer, you don't need to do anything for your side. It's very similar to your deploy application on the Kubernetes. You just update your desired state, and that's it. Now I'm talking about a little bit. I promise about the IoT. So these play features were implemented from 1.12. So we have the Modbus mapler to the DMI framework. So we are working in progress for Bluetooth serial pod mapper based on the DMI framework. So we decoupled the control plan and data plan for IoT device. The device will be as a service. So the data is transmission from over the edge mesh. So the goal is we want to help developers focus on their own application development, now the device management remotely. So we reduce the bandwidth. So reduce the channel congestion between cloud and edge. And also it's more flexible and unified way to manage your IoT device. So this is take advantage of the CRD from the Kubernetes. The detail, the link I put in here. So here is the overview. So there will be three stages. In the API level, you do the DMI implementation and the report to device train. So this way you can manage your device through the metadata and manage all this device left cycle. The second layer will be the control plan and data plan. So in the demo module, you connect the DMI and device driver. And you define your data plan module, including the data process capacity. Device driver is the lowest level that expose device driver interface to the users and manage the need of various type of IoT devices. So as I said, the Bluetooth is under development. So it should be ready in two releases. Here is a little bit more deep dive for the Cloud Edge Mapper data plan. So we provide a RESTful API to provide edge-side data pooling capacity. And we provide data precision capacity in the edge and on the locally, then we synchronize back to the cloud. So this will be very easy for the developers to maintain or to control your device life cycle. So you don't need to worry about how you can maintain the device. So you only operate from cloud side. Here is a little bit deep dive for the architecture based on the time. So I will skip if you are interested. This slide will upload in the website. And you can take a deeper review. Now I'm talking about, I mentioned the edge communications through the EdgeMesh. EdgeMesh is developed by our SIG networking. Here is the deep dive. So it is adaptive multi-edge cloud edge networking. We provide a tunneling. So it's kind of a service design. It has a building in the edge local DNS. So it's communicated through between the edge nodes and edge cloud communication. So it supports layers 4 and the layer 7 traffic management. So EdgeMesh can cross-subnet to do the cross-subnet communication. We are working in progress to support standard ECU for service governance. So that working progress, we should be able to finish it within a year. I forgot to mention that consistent service discovery and assess experience is cross-edge and the cloud. So if you are interested, you can join our SIG networking to have a deep look at our sub-project. EdgeMesh is in our repo. Now is the SIG AI. We have a sub-project called Sedna. It's kind of a distributed AI collaborative. It provides an AI collaboration kit. So we call it a collaborative learning instead of an increment. It's an increment learning process. So it defines AI framework with edge cloud synergy. For other AI or distributed AI learning, there are some bias based on your data set on the individual edge node. So this framework tried to do collaboration increment AI learning to remove this data bias on each individual remote node. And so it's compatible with TensorFlow, PyTorch. The pedal is from Baidu and also Minus Go from Huawei. So it supports multiple AI frameworks. So if you want to try, you can go to our SIG Sedna in our community repo is on GitHub. SIG Security. So we are one of the first CNCF projects, reach L4, the supply chain level for security artifacts. Security here is the link and the QR code for our full auditor report. So it's persisted by the third party. We is the one of the first one reaching this L4 level. And also we are one of the first CNCF project. We integrate with a fuzzing testing. So here is a full report. So if you're interested, you can go there or you can scan the QR code to see the details. Also, we have down thread modeling and also security protection analysis. So here is full details. So here is the QR code. If you are interested, you can go there. Basically, we do all this level for this analysis. Let me show you some more details. So here is our policy and the vulnerability management. So we have our method to report a vulnerability or a kernel vulnerability and have this formalize the remediation process. So you can see we have the stage reporting. Whenever we got the vulnerability reporting, we have a security to confirm that. We do our SRC security response community to respond to that and do the patching. Then we do this embargo stage for restricted disclosure. Then after our partner already patched that, so we do the public disclosure to secure our partners. So here is our details doc. So the link is on the bottom left. The QR code on the right, if you're interested, you can to see our formalize procedure. Now the robotics is different from the IoT. So robotics will be a more complicated device connected to the Edge. So it's locally consistent with the Dell experience. We provide very convenient R&D in simulations. So you can simulate your robotic robot control without the real one. You can simulate all the process. Then you can achieve out of box the robot skill whenever you have your robot connect to the Edge. So it's very efficient robot operation management is similar to the device management. So we provide unified access of a heterogeneous robot. So it's have a collaborative management of a multiple agent. So robotics have a regular committee meeting every two weeks if you're interested. So you can find the calendar in our GitHub. So let me show you some user case we provided. So we partner with a few partners already. So it's including we deploy on the offshore or the oil field. Over the sea is a typical low bandwidth case at a very remote restricted resource. And the CDN is large edge cases. And also we deploy on the highway tow boost. So that one is a very heterogeneous device. Cases some are ARM. Edge nodes some are x86. And also some have a high speed connection in the good area. Some is only 2G radio network. So it's very low bandwidth. And also we partner with some vehicle. The electronic vehicle producers to bake our co-ed in their vehicles. And very exciting we also deploy our edge on the satellite. So it's very low bandwidth high latency cases too. So let me deep dive a little bit to our satellite deployment. So that is a low earth orbit satellite. So the challenge is the resource on the edge. I mean the satellite is very limited. The analysis precision is very low. The satellite do the data collection, ground analysis. And they want to do the massive data transaction. However, it's very challenging to the satellite ground network. And application operation and measurement or update are very difficult. That's all the challenges. So our solution is say, OK, we do multiple mode collaborative inference. When you do the inference on the remote, so the satellite application will break down and use small models. So instead of a large AI model, we tailor the small models to reduce the latency. And the ground station, we use a large regular model to facilitate the sample identification. Basically, we want to do the data clean and data sampling on the edge side to reduce the actual data needed to do the remote, I mean the satellite to ground communication. So in this case, we do the incremental training on the heart samples. We want to do every training on every node. So it will increment from previous results. So we also automatically update locally, make this satellite very, it's more smarter. And as I said, we do the indiscriminative way to match the applications. The ground station will hold a full review of satellite results like your dashboard on Kubernetes control plane. And you can see the application status. You can do the logging. With this way, you can see the satellite to ground data transmission. We reduce 90%, more than 90%. Also, we do the collaborative inference on both large and small models depends on your location to improve object recognition, the precision up to more than 50%. Here is another one is offshore oil deployment. So it's similar to the other node. It's a typical high latency, low bandwidth cases because all this offshore oil field is deployed over the sea. And you can either transfer from the radio network or you have to transfer from the satellite. So this way, the latency is high, the communication, and the bandwidth is low. So we do similar. To this, we optimize the transition. And also, then we pick the radio network or satellite transfer data there. Similar, we want to do this in a cloud native way. On your base care on your shore or on the land, you have an overview of everything. Your manager application deploy on the remote field. Similar to the previous oil case, you can manager your lifecycle application through your cloud dashboard. So the last, not the least, I'm talking about our community. So it's very important to maintain a open governance and open community. You can see since inception of our work is steady growing the contributors. Now we have almost 7,000 stars and almost 1,900 plus forks. We have almost 1,500 contributors from different companies. So it's more than 100 organizations. It's from different companies in the last year. I'm talking about the open governance model. So as I mentioned, we have different six. So including the CIG, IoT, CIG, robotic, CIG AI. Very important during the last year, we have our steering committee is from seven steering committee members from six different companies. And we have 11 six. So the signal is similar to. As we're trying to do the similar things to upstream Kubernetes community, we have a signal to do the node control scheduling. And the device, CIG device, IoT is through the device mapper dimension control IoT device. Scene networking is now focusing on the edge mesh. CIG scalability is trying to scale up our deployment. Now we can manage 50,000 more edge nodes in one deployment. And CIG security has achieved a lot of things during the last one and a half years. We, as I mentioned, there is security. And also we formalize our vulnerability management process. CIG robotics is controlled robots and also work with the vehicles. CIG AI is through the collaborative learning. So we try to do a small model inference on the edge node, large model in the cloud node. And also we do the collaborative training. So without transfer large amount of data from edge to cloud. So you can do small training also on your edge node. CIG Mac is working with the telecom partners to do the Mac. And also we have one more working group. It's the wireless group. There's a few more forming the CIGs. One is the CIG release, try to formalize our release procedure and also CIG testing. Do the conformance testing for our community. If you are interested, please join the CIG. These two CIG are open to call for participation. Here is our landscape. So in the indexed scenario, we have AI, LTE, Mac robotics. And the second layer is extensive core framework. We have the edge cloud scheduling. The core framework is mainly do by the CIG node. Edge cloud orchestration is similar to Kubernetes. The runtime we support containers, VMs, so in the same deployment we are trying to mix the container node and also the VM node in the same deployment. We also work with the Wasam community to support that. Also we do the heterogeneous resource support. You can see in the edge management heterogeneous hardware and in the live device, so all kind of devices we already support. And the Bluetooth is incoming. One of the important support in the latest 1.15 release is we supporting the Windows node right now. If you're interested, you can go to our website. We provide our roadmap. So I have about six minutes left. I'm happy to answer all your questions for our community. Good talk. Thanks. One question about the edge portion of the software. How do you bootstrap this onto the edge devices? Allow it to talk to the cloud control piece. Let me show you. So we have a device mapper. Basically we use a device twin. So from the cloud side, you can see through your metadata. So basically it's a metadata describe your device. So you can control device state through your metadata, basically on, off. Or for example, you have the traffic light. You can change to red, green, yellow from your metadata change from your cloud. So it will pass down to the edge node. And then we use device train to control your device. Yeah, yeah. I think my question is a little different. And I'm wondering, let's say you are behind the LTE device. And normally there's only one way communication. You can have the device talk to the cloud side of the control plane. But you cannot have the control plane to launching your pod or something. Initiate that from the pod at the first time. So you need to have the device side to bootstrap, to understand where the call home is, all those information at the beginning on the device. Normally edge node is behind a firewall, behind a net device, behind the LTE. So from the internet, there's no way to access the edge nodes without the edge node bootstrapping mechanism. Yeah, let me show you. Thank you for this a good question. Thank you for this a good question. You see, in this one, we do the edge, basically, the edge is very close to your device. So in order to go across the firewalls, so we have this cloud core edge core communication. So basically, we set up a tunneling is communication between cloud core edge core. Basically, the communication initiate is not from cloud to the edge, but from edge to the cloud. So I think you can configure your firewalls, say, block all the ingress data. But for egress, you can allow that. So basically, the cloud core initiate, we have a long running connection as a web socket by default. You can choose a quick as the alternative. So basically, in this way, you can cross your firewall. You set up the connection from your edge to the cloud and keep that open, keep that connected. So in this way, you can have a two-week duplex communication between cloud and edge. I hope that answers your question. Yeah, it is. But somebody needs to prepare the edge core side, the device side to have the configuration, including the security mechanism to access which control plane with the capability of the security portion. Yeah, thank you. I think the good question in the security. Yeah, in the bootstrap, we work with our edge node providers when they have an in production. They have a default pod back in the firmware or when they boot up. So it's connect to your control plane in a predefined security port. In this way, then you do the OTA update to update your latest edge control plane. Then this way, then you upgrade. Then in that way, you can define a new or different security port. However, we have a default upgrade server. It's all communicated by the provider, say, how you define your bootstrap status or process. Thank you. Great talk. So I had a question. So you're using a lot of GRPC and WebSocket calls. So GRPC from a native load balancing standpoint, Kubernetes is very not very efficient with that. So how do you do GRPC load balancing based? So let me. So which part? Yeah, we use a ProPath and the GRPC yearly. So which load balancing you are talking about? So when you connect the mobile devices via the GRPC to the edge nodes, yeah. Yeah, we run out of time. But I'm really appreciate that you can come. We can do offline. Thank you.