Edge Computing — Journey to KubeEdge
UPDATE: Evolution to Edge Computing is covered in https://medium.com/@sakthishanmugam02/what-is-edge-computing-6c7546051834?sk=5db039951650db0154f10c5f171cc176 (if interested)
Before jumping into the topic of what is Edge Computing, understanding the real need for that kind of infrastructure approach is of the greatest importance. The IT world has seen the evolution from traditional client-server architecture to cloud computing. That was not sufficient enough, the reason is quite simple: the number of devices accessing the infrastructure is exponentially growing as compared to the computing world, so as the amount of data it generates. As of now, everything in the world is connected to the internet, be it a smartwatch, smartphone, smart tv or self-driven cars.
This raises concerns on existing cloud infrastructure for the bandwidth it needs to support, latency for each request, safety and security aspects of the data being transferred between the device and the cloud. Let’s take a simple emergency scenario of self-driven cars, assume that a self-driven car has to pave a way for an ambulance coming on the same track. To do so, the car has to send its current traffic information to the cloud and some analytics has to be performed by comparing the other vehicles on that same & nearest track. Then instruction has to be issued to the car to leave ways. All need to be performed in a fraction of seconds. But it is quite challenging with just cloud infrastructure which is located miles away from devices where data is originated. This leads us to the concept of Edge Computing.
So, what is Edge Computing? It is about pushing the intelligence to the edge of the network. This means, bringing the computing, storage, analytics (+caching) capabilities as close to devices itself. How we could achieve this feat? By introducing network layers (edge systems) between the devices and the cloud data centers. Therefore data doesn’t need to travel all the way to the cloud to get it processed, instead edge systems would do the needful. What we are gaining out of this approach is, firstly, ultra-low latency as the edge systems will be located as close to the devices. Secondly, data filtering and reduction: means, all the data is not sent to the cloud, hence reducing the stress on the bandwidth requirement. Third, security & privacy compliances of the data can be satisfied as it is not sent all the way to the cloud.
However, introducing Edge Systems between devices and the cloud is not an easy task. We need to compliment with effective provisioning and orchestrating capabilities to make it resilient. Because the number of systems that we are going to manage is not as simple as the above picture. It will be billions of devices.
It is important to remember that, edge devices are not going to limit themselves to one communication protocol. It relies on a wide range of mechanisms like Bluetooth, WiFi, 3G/4G/5G and so on. So, Edge servers also not going to run applications that would fall under the same architecture/runtime. Hence it is good to containerize the applications to deploy it on the edge servers with the help of runtime like docker. While we say this, the obvious thing pops out our mind is Kubernetes to orchestrate these application containers. Woefully, that is not so straight-forward to run Kubernetes directly on the Edge Servers due to its nature of limited computational resources. Even if those servers allow us to install all Kubernetes components, customers may not willing to spend the precious compute resources for managing the Kubernetes control plane, rather they look to use it for processing the data.
Here it emergence the situation for the need of compact/optimized version of Kubernetes, which is KubeEdge. KubeEdge is an open-source system for extending native containerized application orchestration capabilities to hosts at Edge and it is light-weighted in nature by stripping a bunch of features out of the Kubernetes binaries. Notable differentiation is done at edged which is a light-weighted node agent (equivalent to kubelet), SQLite is used instead of etcd. Plus, orchestration capabilities are separated from edge nodes to the cloud side. Means, Kubernetes control plane [master node components] would be placed on the cloud side and computing functionalities [pod deployments] will be handled at the edge side. The below picture would show the architectural difference between Kubernetes and the KubeEdge.
IBM has product called Edge Application Manager with unique set of features too especially related to autonomous management!
I hope this article would give you an insight into what is edge computing and Kubernetes’ role in making it more effective.
Thanks Andrew King to get me a book recently. I owe you for that! I would like to dedicate this blog to you.
Thanks to Ankur Srivastava who gave me the opportunity to learn new concepts.
Thanks to Manu Mathews who always be a great inspiration to people like me.
