KubeCon : Huawei fait de Kubernetes une solution de Edge Computing
Alors que Microsoft, Rancher et Canonical peinent à trouver comment exécuter des applications au pied des objets connectés, Huawei arrive avec KubeEdge, qui occupe seulement 70 Mo en mémoire.
Le prochain domaine à conquérir pour Kubernetes est celui du Edge Computing. Lors du salon KubeCon qui se tenait la seconde quinzaine de novembre, des ingénieurs de Huawei sont venus présenter leurs dernières avancées sur KubeEdge, un projet Open source arrivé depuis peu en une version 1.0 enfin utilisable.
« Le besoin que nous voulons adresser est celui des objets connectés qui génèrent des données trop lourdes pour être remontées dans le cloud – comme des images et des vidéos. L’enjeu de KubeEdge consiste donc à déporter les applications d’analytique qui fonctionnent d’ordinaire en ligne, vers un équipement d’appoint sur site, en conservant leur format d’origine, afin qu’il n’y ait pas de code spécifique à développer pour un fonctionnement en edge », explique Jason Wu, en charge des produits liés au cloud public chez Huawei Technologies, lors d’une session de présentation à laquelle LeMagIT a pu assister.
KubeEdge n’est pas le premier à proposer d’installer une plateforme Kubernetes sur le terrain. Rancher avec K3S, Canonical avec Microk8s et, dans une certaine mesure, Microsoft avec Virtual Kubelet, ont tous imaginé une solution pour faire tenir Kubernetes dans une petite machine autonome que l’on pourrait accrocher aux pieds des caméras de vidéo-surveillance, ou sur le mur d’un point de vente. Mais, jusque-là, aucun d’eux ne semble parvenir à convaincre les entreprises.
Rancher détenait jusque-là un record en lançant son K3S dans seulement 512 Mo de RAM et 200 Mo sur disque. Il y parvient en éliminant dans Kubernetes toutes les fonctions qui ont trait au fonctionnement en cloud, ainsi qu’en remplaçant le moteur de containers Docker par le modeste Contairnerd et l’index Etcd par la petite base de données Sqlite3.
KubeEdge va encore plus loin : il réussit, lui, à tenir dans 66 Mo de RAM et 30 Mo sur disque.
Des nœuds locaux pilotés par le cloud
« L’approche classique consiste à installer toute une plateforme Kubernetes sur un équipement d’appoint. La nôtre est de considérer que l’équipement d’appoint est juste un nœud esclave qui fait partie d’un cluster plus vaste qui, lui, fonctionne en cloud », indique Jason Wu.
« Sur le nœud installé en edge, il n’y a que le strict minimum pour exécuter des applications. »
Jason WuHuawei Technologies
« Dans KubeEdge, toute la partie contrôle, c’est-à-dire celle qui distribue et orchestre les tâches, s’exécute toujours depuis le cloud. Sur le nœud installé en edge, il n’y a que le strict minimum pour exécuter des applications. »
D’ordinaire, Kubernetes se compose de nœuds esclaves qui exécutent des pods (la capsule autour d’un container) au moyen d’une couche logicielle appelée Kubelet. Tous les Kubelets obéissent à un nœud maître qui, lui, exécute toute une pile de logiciels : l’ordonnanceur, le contrôleur, l’index Etcd et un serveur d’API, lequel assure la liaison technique entre tous les nœuds. Dans Rancher K3S, même si un seul nœud est déployé sur site, il faut au moins qu’il exécute tous les logiciels du nœud maître.
Dans KubeEdge, la couche Kubelet est remplacée par un agent Edged qui, comme sur K3S, en constitue une version très allégée. Mais il n’y a plus de nœud maître sur site. A la place, un nouveau module EdgeHub communique en HTTP avec un nouveau module en cloud appelé CloudHub, lequel assure la liaison avec le service d’API du nœud maître, issu, lui, d’un Kubernetes conventionnel.
« Au-delà de minimiser la taille de Kubernetes sur site, notre approche permet de contrôler tous les nœuds – ceux en Edge et ceux en cloud – depuis une seule interface. Cela résout un problème psychologique de taille : puisque les entreprises n’aiment pas que des traitements s’exécutent loin de leurs datacenters, nous englobons ici les traitements en Edge avec le reste de leurs applications. KubeEdge ne crée pas un nouveau déploiement de Kubernetes, il étend au Edge le Kubernetes que vous utilisez déjà », assure le responsable de Huawei.
Du Edge Computing pour la première fois hautement disponible
L’architecture de KubeEdge a un autre avantage sur celle de K3S : elle rend possible la haute disponibilité. « Nous pensons qu’un des usages du Edge Computing sera de se servir de la puissance de calcul répartie sur tous les sites de production pour effectuer des traitements à un coût plus faible qu’en cloud. Notre conception rend cela possible, puisque le nœud maître répartit les applications sur tous les nœuds et, si l’un d’eux ne répond plus, déplace les traitements vers un autre nœud. »
« Le nœud maître répartit les applications sur tous les nœuds et, si l’un d’eux ne répond plus, déplace les traitements vers un autre nœud. »
Jason WuHuawei Technologies
Sur la solution de Rancher, en revanche, l’utilisation de la base Sqlite3 empêche le nœud maître d’être redondant : s’il tombe en panne, plus aucun traitement ne s’exécute, même s’ils étaient assurés par tout un cluster de nœuds esclaves sur site.
A l’inverse, il a fallu doter KubeEdge d’un système qui le rende autonome en cas de coupure réseau. Et c’est en particulier sur ce point que l’équipe de Huawei s’est montrée innovante.
« Nous avons accolé à notre agent Edged un module MetaManager qui enregistre sur le stockage local de l’équipement toutes les commandes d’orchestration du nœud maître. Ainsi, en cas de coupure du réseau, si le nœud doit redémarrer, il se souvient comment redéployer ses pods, avec quels noms et quelles règles de fonctionnement. »
« Nous avons également implémenté au niveau de notre agent un réseau virtuel, appelé Edgemesh-Proxy, qui permet à plusieurs nœuds sur un site de continuer à communiquer entre eux sur le réseau local. Ca fonctionne en peer-2-peer, même en l’absence d’un nœud maître pour servir de DNS », explique Jason Wu.
La richesse fonctionnelle autour de l’agent Edged est ce qui, à terme, devrait assurer le succès du projet. En plus du MetaManager et du Edgemesh-Proxy, on y trouve un module DeviceTwin censé s’interfacer avec tous les protocoles des objets connectés pour récupérer directement leurs relevés ou leur envoyer des ordres, sans que les développeurs aient à écrire dans leurs applications des modules d’interprétation. Lors de la présentation, KubeEdge dialoguait en l’occurrence avec le moteur Mosquitto de la fondation Eclipse, afin de communiquer aussi bien en MQTT qu’en Bluetooth.
