Dernière modification le 11 janvier 2020
Très rapidement, je me suis intéressé à Docker pour faire de la conteneurisation et plus particulièrement pour déployer des architectures microservices ou cloud-native. Dès que Swarm a été intégré dans la distribution Docker-ce, c’est devenu mon orchestrateur de prédilection. N’ayant pas été le seul a raisonner comme ça, il était facile de trouver de nombreux exemples Dockerfile et Docker Compose pour travailler dans le domaine du réseau.
A postériori, force est de constater que Docker a perdu la bataille des orchestrateurs qui n’aurait pas du être la sienne. Kubernetes (K8S) a été largement adopté pour l’orchestration de conteneurs.
On ne peut pas dire que ça a été facile dès le début. Lorsque j’ai testé Kubernetes en 2017, il était très difficile de stabiliser une installation et encore plus difficile de la maintenir stable lors de la mise à jour des composants. De nombreuses distributions Kubernetes ont vu le jour pour mettre à disposition des packagings validés de composants (Red Hat, Canonical, …), mais ça restait tout de même lourd et réservé à des usages dimensionnés. Certains systèmes d’exploitation se sont spécialisés pour proposer de la conteneurisation sous une forme adaptée et se sont dirigés rapidement vers K8S, mais leur utilisation n’était pas souple. Kubernetes a même été disponible pour processeurs ARM rendant possible la création de clusters pour des labs à moindres coûts. Dès lors, des distributions Kubernetes adaptées pour tourner en lab sur une seule machine ont été crées (MicroK8s, Minikube, …) mais c’était plutôt réservé à des développeurs et pas vraiment utilisable en exploitation.
Ma vision de Kubernetes, comme étant un outil qui n’était pas fait pour mes besoins, a commencé à être modifiée en juillet 2018, lorsque Rancher a travaillé sur une distribution simplifiée de Kubernetes. Ils ont développé une distribution de Kubernetes, nommée K3S, avec comme objectif d’être stable et peu gourmand en ressources afin de cibler des utilisations en dehors des Data Centers. Il aura fallu presque 16 mois pour atteindre la version stable officielle, mais les versions intermédiaires testées étaient déjà très prometteuses.
Un des premiers principes de K3S a été de supprimer tout ce qui n’était pas indispensable et de remplacer certains composants de Kubernetes par des outils plus simples et moins gourmands en ressources. Une base de données SQLite a été intégrée à la place d’etcd pour le datastore. Des fonctionnalités simples mais puissantes ont été rajoutées comme : local storage provider, service load balancer, helm controller, et Traefik en tant qu’ingress controller. Tous les composants du Control Plane ont été intégrés dans un seul binaire et processus. Certains providers ont été supprimés et les dépendances externes ont été minimisées pour ne laisser que containerd, Flannel, CoreDNS et des utilitaires systèmes (iptables, socat, etc…).
Au niveau configuration matérielle, le minimum demandé est une CPU et 512 MB de RAM. Monter un cluster K3S avec un serveur de management (agent inclus) et deux agents prend moins de 15 minutes et devient un bon candidat pour porter certains microservices du NetDevOps…