Contribution to architectures for edge computing acceleration with general purpose devices

Laburpena

Nowadays, cloud and edge computing technologies has been adopted in different use cases, such as video processing, Internet of Things, machine learning, etc. pushing the evolution of the virtualization architectures for those applications. For example, the use of deep learning for the automatic classification of the information provided by sensors requires a high amount of computing power that should be placed where the information is generated, in order to reduce the amount of information that is transmitted and to get results with low latency. Graphics Processing Units (GPUs) can accelerate such applications thanks to their parallel architecture. Thus, efforts are being devoted to investigate solutions to improve the performance by using the GPUs alongside the Central Processing Units (CPUs) and reducing the total cost of cloud and edge computing system. This thesis is part of this effort. First, we studied the performance of the GPU of several embedded devices, proving that they are able to accelerate different operations. Then, this type of embedded processors can be included in gateways, and process part of the information generated by sensors (e.g. cameras, LIDARs, etc.). Then, we studied how to build a GPU enabled edge infrastructure that may effectively share the resources among the different users. Containers are one of the technologies that is impacting the virtualization architectures, so we designed a new dynamic scheduling platform for Kubernetes (an orchestration system for automating containerized application deployment, scaling and management), called “KubCG”, that is able to manage the deployment of Docker containers in a heterogeneous computing systems that use CPUs and GPUs together. This platform implements a new scheduler that optimizes the deployment of new containers in a Kubernetes cluster. We have performed different tests to validate this new algorithm, and KubCG was able to reduce up the total running time comparing to the default Kubernetes scheduler by a 64%.