K3S, le kubernetes allégé hautement disponible

Dans cette présentation, nous avons fait plusieurs retours plus spécifiquement sur K3S, notamment concernant l’impossibilité de faire du multi-master dans la version 0.9.1, ce qui limite de manière assez forte ce type d’outil sur des infrastructures de production.

Ce n’est que depuis quelques jours que cette fonctionnalité est supportée en mode expérimental dans la dernière version de K3S à ce jour, c’est à dire la 1.0.0.

Le but de cet article est de vous présenter cette fonctionnalité, mais d’abord, petite présentation rapide pour ceux qui n’auraient pas tout suivi.

Présentation rapide

Nous allons repasser sur quelques aspects rapides de K3S.

Comme je l’ai dit au dessus, K3S est développé par Rancher. Cet outil se veut être un Kubernetes épuré condensé dans un simple binaire avoisinant les 50 mo. Rancher le recommande pour l’IoT, la CI ou les architectures ARM. De plus, Docker est optionnel, c’est containerd qui est utilisé par défaut. Pour finir, K3S fonctionne sur des instances très petites, t2.nano (1 vCPU et 500 Mo de RAM) jusqu’au a1.4xlarge (16 vCPU et 32 Go de RAM), si on prend le type des instances AWS.

Qui dit Kubernetes allégé, dit fonctionnalités en moins, 5 au total :

• Suppression des fonctionnalités taggées “legacy”, “alpha”, “non-default”
• Suppression des addons
• Utilisation de SQLite3 comme stockage par défaut (etcd3 est toujours disponible)
• Gestion automatique du TLS
• Très peu de dépendances avec un système d’exploitation GNU/Linux (sauf le noyau et plus spécifiquement les cgroups)

Techniquement, comment ça marche ?

Pour monter votre cluster K3S, il suffit d’installer le binaire sur deux serveurs distincts et de récupérer le token du premier serveur qui sera votre “master” pour le donner au second qui sera votre “worker” ou “node”.

C’est avec cette simple ligne que vous allez pouvoir rattacher autant de noeuds à votre cluster à partir du “token” du master :

k3s agent --server https://ip-de-mon-master:6443 --token ${NODE_TOKEN}

Voici l’architecture détaillée de K3S :

SQLite est la base de données par défaut quand on utilise un seul master, on retrouve les composants par défaut de Kubernetes et on peut voir que sans configuration additionnelle, le Kubelet va parler à containerd.

Le multi-master

Comme je le disais dans l’introduction, la version 1.0.0 de K3S apporte le multi-master. Attention tout de même, cette fonctionnalité est encore pour l’heure, expérimentale. Celle-ci permet de rendre hautement disponible votre cluster et remplace SQLite par dqlite qui se veut être une base de données SQL rapide, intégrée et persistante avec le consensus Raft.

Si vous souhaitez plus d’informations sur le choix de dqlite, je vous invite à consulter ce billet.

Ce qui change ici, c’est la manière d’initialiser notre premier master, et donc le cluster, on fera comme suit :

K3S_TOKEN=SECRET k3s server --cluster-init

Sur le premier serveur “master”, on viendra récupérer son token et pour intégrer le deuxième et troisième master, on fera la commande suivante :

K3S_TOKEN=SECRET k3s server --server https://ip-de-mon-premier-master:6443

Démonstration

Je vous propose de tester le multi-master à travers la base de code donnée juste après, qui va faire plusieurs choses :

• Déployer une infrastructure sur AWS : un VPC, 3 sous-réseaux privés, 3 autres publics
• Déployer 6 machines, une dans chaque sous-réseau avec une 7ème qui servira de bastion
• Provisionner les machines pour installer K3S (3 masters et 3 workers)

L’infrastructure sera déployée avec Terraform, et les machines seront provisionnées avec Ansible.

Clonez le dépôt de code à cette adresse :
https://github.com/axinorm/k3s-multi-master

Pour démarrer, créez à la racine de ce dépôt une clé privée et publique du nom de id_rsa et id_rsa.pub.

Avant de manipuler les scripts qui vont mettre en place notre infrastructure, nous allons créer et démarrer le conteneur dans lequel nous allons exécuter toutes nos commandes, pour cela rien de plus simple :

./workstation/launch.sh

Une fois le conteneur lancé et exécuté, il faut se placer dans le dossier workdir qui correspond au volume monté du dépôt de code :

cd workdir

À partir de maintenant, il faut copier la configuration par défaut de Terraform dans le dossier configs, celle-ci se trouve dans le dossier mygroup. Renommez ce dossier selon le nom que vous voulez attribuer au projet. Faites la même chose avec le sous-dossier myenv avec le nom de l’environnement que vous voulez déployer (par exemple dev).

./infra-bootstrap.sh --provider aws --account <group>-<env>

Cela va initialiser un bucket S3 et une base de données DynamoDB qui va gérer nos tfstates.

Nous sommes maintenant prêts à jouer les différentes commandes qui vont créer notre infrastructure, avec tout d’abord, la création de tout ce qui concerne le réseau (VPC, sous-réseaux, internet gateway, NAT gateway, etc.) avec Terraform :

./infra-builder-terraform.sh --account <group>-<env> --layer 001-vpc

Une fois le réseau déployé, on attaque les machines (bastion, masters et workers) :

./infra-builder-terraform.sh --account <group>-<env> --layer 002-vms

Notre infrastructure est déployée ! La partie Terraform est donc terminée, nous allons nous occuper de provisionner nos machines. Mais avant cela, il faut générer l’inventaire sur lequel Ansible va s’appuyer :

./infra-make-inventory.sh

Pour la partie Ansible, nous devons copier le fichier all.template.yml en all.yml qui se trouve dans ansible/group_vars, vous pouvez modifier ces valeurs par défaut. Une fois cette action effectuée, nous pouvons lancer le provisionnement de nos machines virtuelles :

./infra-provisioning.sh

Et voilà, votre cluster K3S multi-master est enfin déployé, vous pouvez vous connecter sur le bastion et observer les noeuds de votre cluster Kubernetes :

admin@ip-11-0-0-13:~$ kubectl get nodes
NAME            STATUS   ROLES    AGE   VERSION
ip-11-0-0-19    Ready    master   70s   v1.16.3-k3s.2
ip-11-0-0-29    Ready    master   69s   v1.16.3-k3s.2
ip-11-0-0-9     Ready    master   94s   v1.16.3-k3s.2
ip-11-0-0-118   Ready    <none>   63s   v1.16.3-k3s.2
ip-11-0-0-172   Ready    <none>   63s   v1.16.3-k3s.2
ip-11-0-0-148   Ready    <none>   63s   v1.16.3-k3s.2

Conclusion

Tout d’abord, et nous l’avons vu à travers la démo, K3S est un orchestrateur de conteneurs rapide, très léger et simple à mettre en oeuvre. Le multi-master ne pourra que renforcer son adoption par les équipes pour d’autres usages qui demandent de la haute disponibilité.

Néanmoins, il peut être aussi, pour des équipes plus réticentes au monde Kubernetes, une porte d’entrée accessible.