Sistema de gestión de software para dispositivos IoT

Abstract

Uno de los problemas actuales del Internet de las cosas (Internet of Things, IoT) es el despliegue de aplicaciones nuevas o actualización de antiguas sobre los dispositivos de forma remota. Existen problemas debidos a las dependencias, sus versiones y compatibilidad de estas con las nuevas actualizaciones. Otros problemas vienen derivados de que los errores que se producen en una aplicación puedan afectar a otras, o incluso afecten a componentes principales del dispositivo, es decir, problemas de aislamiento, y además puede existir una falta de escalabilidad de la red. Durante el desarrollo de este proyecto se han utilizado contenedores para ejecutar aplicaciones en los dispositivos IoT y solucionar los problemas de aislamiento y dependencias. Para la ejecución de los contendores se hace uso de dos motores de contendores de código abierto, Docker y balena-engine. Para la gestión de la red de dispositivos se ha usado Kubernetes, un sistema de orquestación de contenedores. Gracias a Kubernetes se ha creado un clúster de tipo maestro-esclavo que permite, a través de una API, gestionar los contendores que se ejecutan en los dispositivos, y, por tanto, las aplicaciones. Del uso de Kubernetes se obtienen otras ventajas, como la posibilidad de exponer servicios directamente desde los dispositivos para ser consultados desde el exterior del clúster. Con Kubernetes se solucionan tanto el problema de la escalabilidad como el despliegue. En esta memoria se explican conceptos básicos tanto de contenedores como de Kubernetes y se profundiza en su funcionamiento interno, algunas características de seguridad, protocolos utilizados, direccionamiento interno, etc. Al ser tecnologías orientadas a la computación en la nube se han adaptado al IoT, por lo que se explica cómo realizar estas adaptaciones para posteriormente ponerlas en práctica. También, se evalúan las características mínimas a nivel de hardware para que un dispositivo pueda incluirse en el sistema. Para demostrar que la teoría explicada realmente puede ponerse en práctica, se ha creado un clúster de Kubernetes de pruebas, desde cero. Para ello, se ha hecho uso de Kubeadm y Kubelet, y se ha utilizado Kubectl para dar las órdenes a través de la API que expone el maestro. El clúster de pruebas consta de dos Raspberry Pi, que juegan el papel de dispositivos IoT y son los esclavos, y por una máquina virtual ejecutándose en un ordenador portátil que juega el papel de maestro. El maestro hace uso de Docker para la ejecución de contenedores, mientras que los esclavos hacen uso de balena-engine por motivos de rendimiento y capacidad de computación. Este clúster es híbrido, ya que conviven en él dos motores de contenedores distintos y es multiarquitectura, puesto que el maestro es amd64 y los esclavos arm. Se explica además, cómo deben ser configurados los componentes principales del clúster como Kubelet o el componente encargado del direccionamiento interno, llamado Flannel. Dado que los dispositivos IoT por lo general utilizan sensores u otro tipo de hardware, se debe garantizar que es posible acceder a estos desde las aplicaciones que se ejecutan en un contenedor. Por ello, se explica el funcionamiento del hardware de una RaspberryPi a través de pines GPIO, cómo la aplicación puede acceder a él desde el contenedor y cómo se deben realizar los despliegues en el clúster para que los contenedores que se lanzan automáticamente puedan hacer uso de los sensores. Dentro de un contenedor se ejecuta una imagen que contiene la aplicación. Se han creado dos imágenes para ser ejecutadas en el clúster de pruebas. Estas dos imágenes hacen uso de sensores. La primera usa el sensor de luz para enviar a sus logs el nivel de luz externo y la segunda hace uso de diodos led para simular un semáforo. La creación de estas imágenes se utiliza para explicar el proceso de creación y optimización de una imagen cualquiera hasta conseguir que ocupe el mínimo espacio posible, ya que los dispositivos suelen tener poca memoria, y también para que puedan ser descargadas rápidamente desde el registro de imágenes. Como registro de imágenes se ha utilizado Dockerhub. Por último, se muestran evidencias de la creación del clúster, de la ejecución de las aplicaciones creadas en el clúster de pruebas y se evalúa el grado de obtención de los objetivos fijados.

One of the current problems of the Internet of Things (Internet of Things, IoT) is the deployment of new applications or updates of old ones over devices remotely. There are problems due to the dependencies, their versions and their compatibility with the new updates. Other problems arise from the fact that errors that occur in one application may affect others, or even affect the main components of the device, that is, isolation problems, and, also, it could exist a lack of scalability of the network. During the development of this project containers have been used to run applications on IoT devices and solve the problems of isolation and dependencies. For the execution of the containers, two open source container engines, Docker and balena-engine, are used. For the management of the device network, Kubernetes, a container orchestration system, has been used. Thanks to Kubernetes, a cluster of master-slave type has been created that allows, through an API, to manage the containers that are executed in the devices, and, therefore, the applications. Other advantages are obtained from the use of Kubernetes, such as the possibility of exposing services directly from the devices to be consulted from outside the cluster. With Kubernetes both problems, scalability and deployment have been resolved. In this report, basic concepts of containers and Kubernetes are explained and their internal functioning, some security features, used protocols, internal addressing, etc. are studied in depth. Being technologies oriented to cloud computing have been adapted to the IoT, so it is explained how to make these adaptations to put them later into practice. Also, the minimum characteristics at the hardware level are evaluated so that a device can be included in the system. To demonstrate that the explained theory can actually be put into practice, a Kubernetes cluster for tests has been created, from scratch. For this, Kubeadm and Kubelet have been used, and Kubectl has been used to give the orders through the API that the master exposes. The test cluster consists of two Raspberry Pi, which play the role of IoT devices, so they are slaves, and by a virtual machine running on a laptop that plays the role of master. The master makes use of Docker for the execution of containers, while the slaves make use of balena-engine for performance reasons and computing capacity. This cluster is hybrid, since two different container engines coexist in it and it is multi-architecture, since the master is amd64 and the slaves are arm. It also explains how the main components of the cluster should be configured, such as Kubelet or the component responsible for internal addressing, called Flannel. Since IoT devices usually use sensors or other hardware, it must be guaranteed that they can be accessed from applications running in a container. Therefore, it explains the operation of the hardware of a RaspberryPi through GPIO pins, how the application can access it from the container and how the deployments in the cluster should be carried out so that containers that are launched automatically can make use of the sensors. An image containing the application is executed inside a container. Two images have been created to be executed in the test cluster. These two images make use of sensors. The first uses the light sensor to send the external light level to its logs and the second uses LED diodes to simulate a traffic light. The creation of these images is used to explain the process of creating and optimizing any image until it takes the minimum space as possible, since the devices usually have little memory, and also so that they can be downloaded quickly from the image registry. Dockerhub has been used as image registry. Finally, there is evidence of the creation, of the execution of the created applications in the test cluster and the grade of objetives achievement is evaluated.