On déploie k3s sur raspberry !

Kubernetes, sur des raspberry ? Mais, pourquoi, comment ?

Tout commença début 2019, a l’époque la guerre des orchestrateurs de conteneurs était en train de s’achever, et Kubernetes était en train de s’imposer. OpenShift avait déjà abandonné son moteur maison pour basculer sur kubernetes, Rancher abandonnait également son moteur maison depuis la version 2.0.

Il était alors temps pour moi d’en apprendre plus sur Kubernetes, mais avoir un cluster kubernetes ce n’est pas gratuit et je souhaitais minimiser les investissements tout en ayant une solution pérenne dans le temps. Les solutions permettant d’avoir un “cluster” sur sa machine (minikube par exemple) devenaient trop limitantes pour pouvoir continuer à apprendre, il fallait que je puisse réellement jouer avec un cluster qui comporte plusieurs machines.

C’est à peu près au même moment qu’un certain Darren shepherd (Co-fondateur de la société Rancher) sortait une nouvelle distribution kubernetes, sobrement appelée k3s (k8s, mais plus léger) dont l’objectif était d’avoir la version la plus légère possible de kubernetes. Avec une fonctionnalité très importante, le support des processeurs ARM !

Il ne m’en fallait pas beaucoup plus pour sortir un raspberry d’un tiroir (Pi 3 à l’époque) et commencer à monter mon cluster !

Disclaimer : Je ne vais pas m’attarder sur la partie installation “from scratch” de chacun des composants d’administration du cluster kubernetes, pour ça je vous recommande d’aller consulter le tutoriel de Kelsey Hightower, Kubernetes the hard way

Installation de K3s sur un raspberry

De nombreux tutoriels existent déjà pour l’installation de k3s et si vous voulez vous lancer, je vous recommande l’article de Alex Ellis qui m’a servi de tutoriel pour déployer mon cluster la première fois https://blog.alexellis.io/test-drive-k3s-on-raspberry-pi/

En suivant le tutoriel, vous arriverez rapidement à la phase d’installation de k3s, et pour le coup c’est très simple :

❯ curl -sfL https://get.k3s.io | sh -

Et c’est tout… C’est pour moi le point fort de cette solution et qui va me permettre d’explorer facilement et ne pas avoir peur de “crasher” le cluster tant il est facile de le reconstruire.

Dans les secondes qui suivent vous devriez être en mesure d’interroger votre cluster pour avoir les noeuds qui sont disponibles (en l’occurrence un seul noeud) et voir son état

❯ kubectl get nodes
NAME           STATUS   ROLES                  AGE   VERSION
k3s-master     Ready    control-plane,master   38s   v1.20.2+k3s1

Ok, j’ai un kubernetes fonctionnel, mais je suis loin d’avoir un cluster ?

En effet ! Mais cette configuration m’a déjà permis de faire mes armes pendant plusieurs semaines (ça prend du temps de commander un raspberry parfois ^^).

Alors clairement vous ne pourrez pas déployer de solutions consommatrices en ressources avec cette configuration, pour ma part j’ai tout de suite voulu mettre en place du monitoring à base de prometheus (quand on a goûté au DevOps on ne s’en passe plus :p) et clairement un raspberry pi3 seul n’est pas suffisant pour ça. J’ai quand même pu déployer une application PHP, avec une base de données, le tout utilisant un partage NFS sur mon NAS pour la persistance de données.

Un vrai premier cas d’usage en réalité, avec la possibilité de jouer avec les volumes, les cronjobs, les ingress, etc… Mais j’ai réellement pu commencer à travailler des notions plus complexes avec l’arrivée de mon deuxième raspberry, et donc l’installation de mon premier agent. L’installation est toujours très simple, et la principale différence vient de l’ajout d’un fichier de configuration pour donner les informations de connexion et d’enregistrement auprès du premier noeud du cluster

# Dans le fichier /etc/rancher/k3s/config.yaml
token: << token pour s'authentifier auprès du master >>
server: << IP du premier raspberry >>

Puis de lancer la commande d’installation, en précisant qu’on installe un agent cette fois-ci :

❯ curl -sfL https://get.k3s.io | sh -s agent

Et quelques secondes plus tard on obtient :

❯ kubectl get nodes
NAME           STATUS   ROLES                  AGE   VERSION
k3s-worker-1   Ready    <none>                 50s   v1.20.2+k3s1
k3s-master     Ready    control-plane,master   38d   v1.20.2+k3s1

Une fois qu’on commence à avoir plusieurs machines on va pouvoir se rendre compte un peu plus des contraintes du modèle distribué. Avec notamment la gestion de volumes partagés, la gestion du réseau entre les différents noeuds etc… On peut réellement commencer à parler de cluster !

Ok, c’est bien mais aujourd’hui il sert à quoi ce cluster ?

Personnellement après plus de deux ans, je dois dire que ce cluster a été un outil clef dans ma veille et dans mon apprentissage de Kubernetes. J’y aie depuis rajouté un troisième raspberry (un pi 4 avec 4 Go de ram cette fois-ci !) qui est devenu le master de mon cluster. Pendant un temps, j’ai eu besoin d’un agent avec un processeur x86, et j’avais donc une VM Hyper-V sur un serveur windows avec un agent k3s installé, et ça fonctionne très bien !

Ce dernier cas d’usage m’a d’ailleurs permis d’explorer les taints et les tolerations au niveau de kubernetes pour déployer les pods qui avaient besoin d’un processeur x86 sur le bon noeud automatiquement.

Au final, je vous l’accorde, l’utilisation de kubernetes n’est absolument pas nécessaire, et je pourrais tout déployer sans avoir à l’installer. Mais le fait de se contraindre à utiliser la solution presque au quotidien m’a permis de soulever pas mal de problématiques et de comprendre plus en détail le fonctionnement d’un cluster kubernetes. Aujourd’hui, je n’en ai clairement plus besoin pour l’apprentissage (j’ai la chance de faire beaucoup de kubernetes en mission, et même de donner des formations sur le sujet), mais je continue quand même de le maintenir et de l’utiliser pour sa facilité à être maintenu dans le temps.

Dans un prochain article sur le sujet je vous partagerais plus de détails sur les différents éléments que j’ai déployé dans ce cluster avec les contraintes associées, à commencer par la gestion du trafic entrant, la gestion du monitoring, la gestion des volumes, etc…

En attendant n’hésitez pas à réagir en me posant des questions ou en partageant cet article