DEV Community: Tanguy BAUDRIN

On déploie k3s sur raspberry !

Tanguy BAUDRIN — Thu, 18 Mar 2021 00:00:00 +0000

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

Le DevOps, c'est quoi exactement ?

Tanguy BAUDRIN — Fri, 05 Mar 2021 00:00:00 +0000

Pour ce premier article, je vous propose un edito ou je vous partage ma vision et ma compréhension de ce qui aujourd'hui est devenu un "buzz-word"

DevOps, ça veut dire quoi ?

Le devops — ou DevOps (selon la graphie habituellement utilisée en langue anglaise) — est un mouvement en ingénierie informatique et une pratique technique visant à l'unification du développement logiciel (dev) et de l'administration des infrastructures informatiques (ops), notamment l'administration système.

— Wikipedia

Comme le décrit si bien Wikipedia, le DevOps c'est avant tout un mouvement, une philosophie, au même titre que d'autres mouvement bien connus comme l'Agilité avec lequel il a d'ailleurs de fort liens.

Aujourd'hui le terme est devenu "à la mode" dans le monde de l'informatique et on le retrouve dans de nombreux usages qui ne sont pas adapté (Non, non, DevOps ne sers pas à qualifier une personne qui sais écrire du code et administrer un serveur)

Et quel est le but ?

Le mouvement DevOps est la suite naturelle du mouvement Agile, ce mouvement ayant à l'origine pour objectif de permettre aux équipes métiers et aux équipes de développement de travailler ensemble à l'optimisation de la production de valeur ajoutée directement pour les utilisateurs.

Le mouvement DevOps partage ce même objectif, mais en incluant également les équipes opérationnelles (Ingénieurs réseau, Administrateurs système, Administrateurs de base de données etc...) dans la recherche de la meilleure façon de produire de la valeur ajouté pour les utlisateurs finaux.

Vous l'aurez donc compris l'objectif du mouvement Devops est d'embrasser l'ensemble des équipes IT et de rayonner bien aux-delà des "simples" équipes de développement ou d'opérationnels (On entends même aujourd'hui parler de DevSecOps, et pouquoi pas un jour de DevSecFinOps...).

Ok, mais comment ça fonctionne ?

Dans les concepts que l'on va retrouver dans la mise en place du mouvement DevOps au sein d'une organisation on retrouvera systématiquement différentes notions

Observabilité

L'un des piliers du mouvement DevOps est l'observabilité, l'observabilité comme son nom l'indique, consiste à rendre "observable" son SI et les différentes solutions déployées. Cela va bien souvent consister à exposer des "métriques" (latence, temps de réponse, nombre d'utilisateurs) dans le but de mesurer de manière objective et factuelle le niveau de service rendu à l'utlisateur. Cela ne comprends donc pas que des indicateurs techniques, mais aussi des indicateurs métier (satisfaction client, taux de rebond, engagement des utilisateurs)

Automatisation

Une autre brique importante va être la mise en place d'un maximum d'automatisation dans les process de déploiement et de maintenance des solutions. L'objectif étant d'avoir des actions répétables, traçables et qui minimisent au maximum le risque d'erreur humaine. On va alors mettre en place des processus d'intégration continue,

Gestion des incidents

Comme pour l'agilité, le mouvement DevOps prone l'amélioration continue, et cela va passer par la mise en place de pratiques de gestion d'incident décrites et appliquées. Dans les phases les plus avancées de la mise en place du mouvement DevOps on va commencer à parler de "Chaos Engineering" ou l'on va volontairement couper des services au niveau de l'infrastructure pour valider le bon fonctionnement de son service.

Et en pratique comment je mets en place tout ça ?

Dans la pratique le DevOps en tant que tel, et bien ça n'existe pas... En réalité, il n'y a pas de recette toute faite pour la mise en place du DevOps, celle-ci doit être adapté au contexte de l'entreprise ou de l'équipe qui souhaite le mettre en place.

Dans les faits, on retrouve souvent aujourd'hui la mise en place du "Site reliability engineering" (ou SRE), qui est une approche pratique de la démarche qui est proposée par Google. Elle apporte des solutions concrète a mettre en pratique (SLI/SLA/SLO, Error budget, Post-morter). Mais le "SRE" n'est pas le "DevOps", tout comme le SCRUM n'est pas l'agilité. Pour faire une analogie dans le monde du développement orienté objet, on peut considérer que le DevOps est une classe abstraite, et que le SRE est une implémentation de cette classe abstraite.

J'espère que cet article vous aura aidé à y voir plus clair sur ce qu'est le DevOps