3 En tant qu’ingénieur DevOps chez Scality, je côtoie des clusters Kubernetes et des pipelines CI/CD sur tous les grands clouds. Au quotidien, je maintiens notamment Zenko, et je dispose donc généralement d’importantes ressources de calcul et de stockage pour tester et déployer de nouvelles infrastructures. J’adore Kubernetes et je serais prêt à déployer un cluster sur à peu près n’importe quoi, de deux grille-pain à AWS. Puis un jour, j’ai entendu l’annonce de Rancher concernant sa micro-distribution Kubernetes baptisée K3s (cinq de moins que K8s) J’ai immédiatement eu une envie irrésistible de monter un petit cluster physiquement transportable et de pousser K3s dans ses retranchements. Passionné de Raspberry Pi depuis longtemps, j’y ai naturellement vu l’occasion d’un projet passion. L’idée est simple mais intéressante : prendre quelques Raspberry Pi et les relier en cluster Kubernetes. L’idée n’a rien d’unique, cela a déjà été fait ; mais associée à ce Kubernetes allégé, elle laisserait assez de place pour accueillir quelques charges de travail. Je me suis mis à rêver de Zenko sur un équipement edge isolé, où la réplication asynchrone vers le cloud ferait merveille. Je me suis dit : « Allons-y ! »LA LISTE DE COURSES POUR UN MINI-CLUSTER KUBERNETES Commençons par la liste de courses : Cinq Raspberry Pi 3B+ (plus les cartes mémoire) Boîtier C4 Labs « Cloudlet » à 8 baies routeur portable TP-Link chargeur USB Anker 6 ports de 60 watts switch 8 ports LE CASSE-TÊTE DU SYSTÈME D’EXPLOITATION Il existe d’innombrables guides de qualité pour configurer un Raspberry Pi avec les différents OS disponibles. Pour la configuration initiale, j’ai commencé avec un simple Raspbian pour voir si je pouvais trouver ou construire des images ARM pour tous les services Zenko. J’ai pu construire facilement les composants clés – les images CloudServer et Backbeat – à partir de l’image Docker ‘arm32v6/node’. Une fois cette étape réussie, j’ai voulu tester MongoDB, la base de données au cœur de notre moteur de métadonnées. C’est là que j’ai rencontré mon premier problème : MongoDB 3.x ne prend en charge que les systèmes d’exploitation 64 bits. Je tenais cela pour acquis depuis si longtemps que j’avais oublié que cela pouvait poser problème. Heureusement, les Raspberry Pi 2 et plus récents utilisent des puces ARM 64 bits, mais il me fallait tout de même un nouvel OS, Raspbian n’existant qu’en version 32 bits. Il n’existe pas de liste définitive, mais la plupart des distributions proposent une version ‘aarch64’ qui fonctionne généralement avec les Raspberry Pi récents. J’ai opté pour Fedora 29, surtout parce qu’elle propose un outil CLI pour charger l’image sur la carte SD, ajouter une clé SSH publique et redimensionner le système de fichiers racine pour occuper toute la carte SD. Ce sont autant de configurations manuelles à faire habituellement après le premier démarrage du Pi. J’ai ainsi pu configurer mes cinq Pi sans brancher de clavier ni d’écran, et disposer immédiatement de serveurs headless opérationnels. Remarque : vous pouvez télécharger Fedora ici. Une fois tous mes Pi configurés, il ne me restait plus qu’à monter le cluster Kubernetes. J’ai déployé tant de clusters sur des machines virtuelles et des serveurs bare-metal que j’ai l’impression de pouvoir le faire les yeux fermés, mais cette fois n’avait rien à voir avec tout ce que j’avais fait jusque-là. Grâce à l’installeur K3s, j’ai obtenu un cluster de quatre nœuds dédiés et un master/nœud déployé en moins de cinq minutes (sans compter le temps de configuration de mes RPi). Leur script de bootstrap rend l’opération ultra-simple. Aussi simple que ceci : # Sur le nœud serveur de contrôle curl -sfL https://get.k3s.io | sh - # Le kubeconfig est écrit dans /etc/rancher/k3s/k3s.yaml k3s kubectl get node # Pour configurer un nœud agent, exécutez la commande ci-dessous. NODE_TOKEN provient de /var/lib/rancher/k3s/server/node-token sur votre serveur curl -sfL https://get.k3s.io | K3S_URL=https://master-node-hostname:6443 K3S_TOKEN=XXX sh - KUBERNETES SUR UN MINI-RACK Le cluster de 5 Pi étant opérationnel, il était temps de rendre l’ensemble transportable. Les objectifs : un seul câble d’alimentation pour tout, et une connexion Wi-Fi facile où que l’on aille. Cela impliquait aussi d’éviter la corvée de la configuration manuelle et de la connexion de chaque Raspberry Pi au Wi-Fi à chaque nouvel endroit. La solution était simple : rendre le réseau lui-même tout aussi transportable avec un petit switch et un routeur portable. Le boîtier Cloudlet de C4Labs est très bien pensé pour la gestion des câbles, et bien conçu, avec des instructions claires pour installer tous les Raspberry Pi. Dans notre cas, je tenais à laisser aussi de la place pour le routeur portable, le switch et le bloc d’alimentation. Heureusement, et par pur hasard, la longueur du switch commandé correspondait exactement à la hauteur intérieure du boîtier, ce qui nous a permis de le monter verticalement. Il restait ainsi de la place sous les Pi pour le bloc d’alimentation, et nous avons pu installer le routeur portable TP-Link dans l’une des baies restantes. Ventilateurs montés, Pi branchés et câbles rangés, il restait un problème évident : le switch 8 ports et le bloc d’alimentation USB avaient chacun besoin de leur propre prise. En examinant le switch, j’ai vite remarqué qu’il fonctionnait en 5 V, et pouvait donc facilement être alimenté en USB. Mais les six ports du bloc d’alimentation étaient déjà pris par les cinq RPi et le routeur portable. ET ENSUITE ? C’est tout pour aujourd’hui. L’objectif est maintenant de soumettre ce minuscule cluster à quelques charges de travail pour en évaluer les performances, puis de transformer le processus de configuration en quelques playbooks Ansible simples afin de rationaliser le bootstrap de plusieurs nœuds. Dites-moi ce que vous en pensez ou posez-moi vos questions sur le forum.
