Kubernetes, futur tremplin pour l'edge computing et l'IoT ?

Kubernetes, futur tremplin pour l'edge computing et l'IoT ? MicroK8s, KubeEdge, k0s, K3s... Les distributions allégées de l'orchestrateur open source se multiplient pour s'adapter aux objets connectés et aux points de terminaison réseau.

Avec l'edge computing, les données ne transitent plus par un cloud centralisé mais sont traitées en local, au plus proche de l'utilisateur ou de la source de data. Souvent associé au déploiement de la 5G, il doit permettre d'absorber l'explosion annoncée des objets connectés. Cette approche présente d'autres avantages comme l'optimisation de la bande passante, des objets connectés plus autonomes, une réduction des délais de latence ou encore une sécurisation accrue des informations sensibles. Se pose toutefois la question de la gestion à distance de ces devices ? C'est là qu'intervient Kubernetes (K8s). A l'initiative de Google, cette plateforme open source a définitivement gagné la guerre des orchestrateurs de conteneurs logiciels et bénéficie du soutien d'une communauté croissante. Depuis deux ans ont émergé des distributions allégées de Kubernetes spécialement taillées pour faciliter le déploiement d'applications en frontière de réseau (edge) ou directement sur des appliances IoT.

Des projets signés Rancher ou Canonical

Rancher a été un des premiers éditeurs à faire tenir K8s dans une infrastructure autonome aux ressources limitées. Sa version light de l'orchestrateur, K3s, se présente comme un simple binaire dont l'empreinte est inférieure à 40 Mo d'espace disque et 512 Mo de mémoire vive (RAM). Elle se destine à des mini-serveurs en mode edge, à des objets connectés ou aux Raspberry Pi. Les composants tagger legacy, alpha, non-default features ont été supprimés de la distribution d'origine. Containerd remplace Docker, Sqlite3 se substitue à etcd comme magasin de données clé-valeur, et le volet réseau est pris en charge par Flannel et CoreDNS.

Autre éditeur, bien connu pour sa distribution Linux Ubuntu, Canonical propose avec MicroK8s, une version minimale mais conforme à Kubernetes dédiée aux déploiements IoT et edge et aux clusters de test locaux. Sous Linux, elle s'installe via les snaps et fonctionne sans machine virtuelle. A la différence de K3s, MicroK8s peut également tourner sur Windows et MacOS. Sa version Windows qui s'installe via un fichier exécutable exige 4 Go de RAM et 50 Go d'espace disque. L'approche en machines virtuelles est cette fois de rigueur avec la technologie Multipass. La version MacOS s'installe, elle, en lignes de commande via Homebrew.

En septembre dernier, Canonical a annoncé la prise en charge par MicroK8s d'un dispositif de haute disponibilité. Il s'active automatiquement à partir d'un cluster de trois nœuds. Dans cette optique, MicroK8s fait appel au datastore Dqlite, une base de données SQL embarquée, alternative à etcd et répondant aux contraintes des appareils IoT et aux micro-clouds.

Huawei et Microsoft dans la course

Egalement dans la course, l'équipementier télécom Huawei développe KubeEdge. Si la version 0.1 remontant à 2018 fonctionnait uniquement avec le service cloud IEF du groupe chinois, le projet a été depuis repris par la Cloud Native Computing Foundation (CNCF). Parmi ses contributeurs, on trouve des poids lourds du secteur de la tech comme ARM, Google, Red Hat ou encore VMware.

Sous licence Apache 2.0, KubeEdge remplace la couche logicielle Kubelet par un agent Edged appelé à gérer les applications conteneurisées. A la place du nœud maître auquel obéissent les Kubelets, on retrouve un web socket client (EdgeHub) et un web socket serveur (CloudHub). "Les développeurs peuvent écrire des applications basées sur HTTP ou MQTT, puis les conteneuriser et les exécuter n'importe où, dans le cloud ou en mode edge", avance le projet open source KubeEdge sur son site web. Dans sa feuille de route pour 2021, il prévoit de renfoncer encore cette synergie cloud-edge tout en intégrant des briques d'IA.

"Avec l'edge, on rajoute via Kubernetes une couche de complexité supplémentaire"

De son côté, Microsoft n'est pas en reste. La firme de Redmond est à l'origine du projet Virtual Kubelet, qui propose une approche serverless de Kubernetes. En octobre dernier, elle a aussi annoncé le lancement du projet open source Akri (qui signifie "bord" en grec) qui vise à connecter Kubernetes à des équipements en mode edge.

Dernier projet open source en date : k0s. Annoncé en novembre dernier par Mirantis, un éditeur californien spécialisé dans la gestion des containeurs logiciels, il se présente sous la forme d'une distribution entièrement conforme à l'orchestrateur open source. Elle a été créée par l'équipe à l'origine de Lens, un environnement de développement intégré (IDE) pour Kubernetes. Selon le billet de blog de présentation du projet, k0s est un binaire unique sans dépendance à l'OS hôte en dehors du noyau. Compatible avec les architectures de processeur Intel et ARM, il fonctionne sur n'importe quel serveur Linux ou sur Windows Server 2019. Il prend en charge la Container Runtime Interface (CRI), ce qui le rend compatible avec Containerd ou Docker Enterprise. Le développeur peut également visualiser et contrôler les clusters depuis l'interface graphique de Lens. Mirantis fait valoir que k0s permet de déployer et exécuter des charges de travail sur n'importe quelle infrastructure : environnement sur site (on-premise), cloud privé, cloud public, cloud hybride ou edge computing.

Directeur de la practice architecture solution au sein du cabinet de conseil Nexworld, Olivier Calvez tempère l'enthousiasme suscité par cette multiplication de Kubernetes light. "Sur le papier, le recours à ces distributions allégées fait sens. Elles répondent à la volonté d'étendre à l'edge computing le même environnement technique que celui du cloud", analyse l'expert. Toutefois, rappelle Olivier Calvez, Kubernetes a pu montrer des limites dans la gestion du multiclustering et plus encore dans celle des architectures multitenant. "Avec l'edge, on rajoute via Kubernetes une couche de complexité supplémentaire, l'utilisateur n'exerçant pas le même contrôle dans un environnement distant que dans le cloud", argue-t-il. Ce qui peut poser des problèmes de sécurité et rendre inapplicable ce type solution à des services ou des applications critiques dans le monde des télécoms ou de l'industrie 4.0 par exemple.