 Hello everyone, I am Charles, software engineer at Alibaba Cloud. Today we are going to present our work. Take the edge to the cloud with OpenYard and the EdgeX Foundry. This is a cooperation project between Alibaba Cloud and the VMware. This talk will be divided into four sections. First, I will introduce the four main challenges of applying Kubernetes to Edge computing environment, and how OpenYard addresses these four challenges. Then Ishing will provide necessary backgrounds of EdgeX Foundry, and how we combine OpenYard with EdgeX Foundry. And finally, we will wrap up the talk with a demo. So why we need to use OpenYard and why we cannot use Kubernetes in Edge computing environment directly. To answer this question, we have to understand that applying Kubernetes to the Edge computing environment requiring us to overcome four challenges. First, how can we prevent the pods from being evicted if edge nodes are temporarily disconnected from the API server? Second, how can API servers send a request to an edge node if they are located in two isolated networks? Third, how can we deploy workload by region as system settings or device models in different regions may vary? Four, how can we manage the Edge device with different protocols in a Kubernetes native way? We develop OpenYard to address these four challenges. The design principle of OpenYard is extend the native Kubernetes to the Edge. Therefore, we won't change the system architecture or any core components of the Kubernetes. In the other words, we will tackle all the four challenges only using the native Kubernetes workloads. In addition, we always keep the goal in mind that we have to support all upstream Kubernetes features. Here is the system architecture of OpenYard. As we can see, to have an OpenYard cluster up and running, we only need to deploy several controllers on cloud nodes, and on each edge node, we only need to deploy Yard Harp and the Yard Tunnel agent. In addition, we provide a command line tool, Yard CTL, to help us to manage an OpenYard cluster. By simply running the Yard CTL convert, all the above components will be automatically deployed. Next, I will introduce each of these components and how they help us to tackle the four challenges. The first problem we try to solve is how can we prevent pods from being evicted when a network connection between an edge node and an API server has been cut off. In the edge computing environment, the network connection between edge nodes and API server can be unstable. However, Kubernetes requires the API server to be tightly connected to worker nodes. If a worker node is disconnected from the API server, or the API server misses several harbids from the worker node due to pool network connection, the node will be marked as unready, and the pods running on the node will be erased from the ATCD. Later, when the worker node reconnects to the API server, the Kubernetes will notice that pods running on it are not in the ATCD, then it will physically evict the pods. This is something we don't want to happen. To avoid this from happening, we develop Yard Hub. Yard Hub functions as a reverse proxy and local cache, that is deployed on each edge node. After it is up and running, we will connect the Kubernetes to the Yard Hub instead of connecting to the API server on the cloud. During the runtime, the Yard Hub will keep checking the healthiness of the network connection between the edge node and the API server. If the network between the edge node and the API server is stable, Kubelet will talk to the API server directly, and synchronize the pods state as it does in the native Kubernetes. In the meanwhile, the Yard Hub will cache pods states in the local cache storage. If the network between the edge node and API server is cut off, the Kubelet will use pods states in the local storage instead. In addition, we have a garbage collector running in Yard Hub, which periodically removes useless pods state from the local cache. At the same time, we have the Yard Controller Manager running on the cloud to prohibit API server from expelling pods from unready edge nodes. The second problem we wanted to resolve is how can we redirect the requester from API server to edge nodes. It is very common that users may want to fetch logs of pods or execute commands in pods. This operation is normally conducted by using the Kubectl command line tool, which will send HTTP request to the API server first, and then API server will redirect the request to corresponding nodes. However, in a production environment, API server is usually located on the cloud, while edge nodes are located in users' private local networks. Therefore, API server cannot talk to edge node directly. We developed a Yard Tunnel to tackle this problem. Yard Tunnel using a client server architecture. On each cloud node, we deploy a Yard Tunnel server, while on each edge node, a Yard Tunnel agent will be deployed. Even though the incoming traffic may be blocked outside of the private local network, edge nodes can still send requests out of the local network. Therefore, after Yard Tunnel agent is set up, it will initiate a reverse connection and register itself on the Yard Tunnel server. To redirect the request to the Tunnel server, we inject the rules to the host IP table, which will redirect all outgoing HTTP requests with destination part 10,250 and 10,255 to the Tunnel server. Yard Tunnel use the API server network proxy internally. I will refer to API server network proxy as an AMP in the rest of this talk. AMP does not work with old version of Kubernetes. Let's does not support the egress selector. Therefore, we add an interceptor inside the Tunnel server, which will encapsulate HTTP requests in a format that is compatible with AMP. Also, since the AMP use GRPC protocol to transfer data between Tunnel server and Tunnel agent, we are able to further reduce the bandwidth between the cloud nodes and the edge nodes. After our HTTP request is encapsulated, the AMP server will pick the corresponding AMP agent and send a request to it. The third challenge that prevents using Kubernetes in an edge computing environment is that Kubernetes does not support deployed workloads by regions. Since an edge cluster can be located across multiple network or geographic regions, an assistant or device setting in different regions may vary, so users may want to deploy workloads by region. For example, the system architecture of edge nodes in Region 1 may be AMD64, while in Region 2 may be ARM64. If users want to run same workloads in both regions, then they have to create two workloads with exactly the same configurations but only difference in container image name. This can cause exponential increase in maintenance efforts with the increasing number of workloads. We developed the Yacht App Manager to its demanding burden on users. Specifically, the Yacht App Manager contains two controllers, the No Pool Controller and the United deployment controller. The No Pool Controller can group nodes into pools, can be nodes with same system architecture or nodes from the same network region, and then we can manage nodes in the same pool, uniformly. For example, we can add labels, annotations, or tints to all nodes in the same pool. After we group nodes into pools, United deployment controller can deploy the workloads based on the same template but different configurations across pools. In addition, we leverage the service topology feature to bound the east-west network traffic within a pool. The last challenge is how can we support various kinds of edge device made by different manufacturers using different communication protocols. Existing solution either need to change some key components of the Kubernetes significantly or require users to implement the device adapter or driver from scratch, which result in large development effort in the loss of some upstream features. Inspired by the UNIX philosophy, do one thing and do it well. We believe that Kubernetes should focus on managing computing nodes while the device management should be down by a mature edge computing platform. Therefore, we come up with the idea of integrating EdgeX Foundry into OpenYard. Next, Yixing will give us some necessary backgrounds of EdgeX Foundry and introduce how we combine EdgeX Foundry with OpenYard. Okay, thanks Charles for the introduction. Hello, everyone. I'm Yixing from VMware City Office and also the maintainer of the OpenYard project. So for those who are not familiar with EdgeX Foundry, I'd like to give a general introduction first. Then I will cover the OpenYard and EdgeX integration overview. At last, there will be a demo to illustrate how it works. So what is EdgeX Foundry? It is an open source when the Neutron Project and the Linux Foundation with Apache 2 license. It is also a microservice loosely coupled software framework for IoT Edge computing. And at the same time, it is hardware and OS agnostic. If we need to use one sentence to describe it, EdgeX is a mid-ware that connects things with your IT environment. So crudely speaking, the surface of EdgeX constitute a dual transformation engine. First is translating information coming from sensors and devices, various hundreds of protocols and thousands of formats into EdgeX. And second, it can deliver data to applications, enterprise and cloud system over TCP-IP-based protocol, information and structure of customer choice. Now let's take a look at the EdgeX architecture. From the south side to the north side, it has four layers. The device service layer, which is responsible to connect all kinds of sensor devices or actuators over hundreds of OT protocol. The core service layer, the supporting service layer and the application service layer. Let's take the data flow in EdgeX system, for example, to illustrate how it works. First, a sensor data is collected by the device service from a scene. And the data is passed to the core service for local persistence. Data is then passed to application service for transformation, formatting, filtering and can then be sent to North to enterprise and cloud system when needed. Data is then available for Edge analysis and can trigger device acutations through command service. Basically, there are two paths to control the Edge device. One is through the cloud. The other is some automation control on the Edge through some predefined logic through the user defined application service or rule engine or both. Since you can always combine them together, like you can train models on the cloud and create an application service on the Edge for inference. Now let's take a look at the EdgeX deployment scenario. In today's IoT landscape, it is imperative to leverage compute, storage and network resource wherever they live. So in the first scenario, you can deploy the device service on the Edge side and everything else in the cloud. This is for latency in sensitive applications. In the second scenario, if the gateway has enough compute and storage resource, you can deploy the full EdgeX foundry service on the gateway and gain good response time. In scenario three, if the gateway is not that good, you can just deploy the device service and the core service there and move the application and analytics to the server part. The fourth scenario is quite similar with the fourth one except it deployed EdgeX on the fourth server to gain better latency response. So we can see that the quantity and the function of a macro service deployed on a given node depends on the use cases and the capability of the hardware. Now let's take a look at the OpenUlt and EdgeX foundry integration. On the cloud side, we run your control manager, your app manager and the tunnel server manager. You can run it on any public private or hyper cloud or on primitive center which according to your requirements. And on the Edge side, besides the default you have and the tunnel agent, we will deploy a new device controller which is responsible for sync data between the EdgeX and the Kubernetes. The EdgeX cloud service will also be deployed on the Edge side. In some cases, the sensors direct connect gateway doesn't have enough resource. We can just deploy the EdgeX device service there. The Edge node can be either un-based or ex-18.6 based. Now I will use a demo to illustrate how it works. Let's take a look at the demo environment property. We have a master node running on the cloud and we'll have two work nodes running in the private network. The pipe 4 is in my home office and the e-box is running in another location. They together compose a unified Kubernetes cluster across cloud and Edge with different hardware architecture. We use kubectl to get a node to check the node status in the cluster. This is the pipe 4 node. We connect a temperature and a humidity sensor through GPIO pin 17. This is an RGB LED light connected to the pipe through GPIO pin 18, 19 and 20. This is the second work node which is x18.6 based. We next will deploy the EdgeX cloud service to the pipe 4 work node. We use kubectl to get a pod to check the deployment creating status. After a few minutes, we run the command again. We can see that the EdgeX services are up and running on the pipe 4 work node. The device controller will send the device information to Kubernetes. We can use kubectl to get a device to list all the devices in EdgeX. We can use kubectl to get device profile to list all the device profile information. Also, we can use kubectl to get device service to list the device service information. Like what we can do to the traditional Kubernetes object, we can change the device status by kubectl edit. First, we run command kubectl edit device name. We then set the device property light to color right as the desired value. We save and exit. You can see EdgeX will turn the LED light to right. Next, we run kubectl edit device name again. This time, we set the desired color to blue. We save and exit. We can see EdgeX turns the light to blue. Last, we run kubectl edit device name again and set the desired color to green. Then we save and exit. We can see EdgeX will turn the LED light to green. So with EdgeX and OpenJord, you can manage your LED devices in your Kubernetes native manner. Thanks for listening our session. Now it's kill and A time.