Finalement, après plus d’un an depuis sa conception initiale, la version 1.0.0 de Rancher K3s est arrivée cette semaine =>
K3s propose notamment la nouvelle interface KINE pour les datastores qui permet de choisir le datastore le mieux adapté à son cas d’utilisation, notamment: SQLite, DQLite, MySQL, Postgres, etc.
Et une mise en réseau cryptée soutenue par IPSec ou Wireguard …
En version 1.0.0 on a également la possibilité d’initier officiellement un cluster K3s en mode Haute-disponibilité (HA) avec deux modes :
High Availability with an External DB
Un mode utilisant un datastore (magasin de données) externe pour le cluster : il nécessite donc
- Deux ou plusieurs nœuds de serveur qui serviront l’API Kubernetes et exécuteront d’autres services du plan de contrôle.
- Un datastore externe (par opposition au magasin de données SQLite intégré utilisé dans les configurations à serveur unique).
- Une adresse d’enregistrement fixe placée devant les nœuds “serveur” pour permettre aux nœuds “workers” de s’enregistrer auprès du cluster.
Mais également un autre mode (expérimental pour le moment) utilisant Dqlite de Canonical (à savoir du SQlite en mode distribué) comme on a pu le voir dans l’article précédent à propos de MicroStack et MicroK8s :
Edge Computing : Aperçu de la fonction clustering dans MicroStack et MicroK8s …
Dqlite (SQLite distribué) a été créé par l’équipe LXD de Canonical, la société derrière Ubuntu. Il s’agit d’une bibliothèque écrite en C qui implémente un moteur de «base de données SQL persistante, rapide, intégrée et persistante», qui offre un basculement automatique à haute disponibilité. L’équipe a publié la version Dqlite 1.0. Il est à code source ouvert sous Apache 2.0 et fonctionne sur les architectures ARM, X86, POWER et IBM Z. Dqlite est écrit en C pour offrir une portabilité maximale entre plates-formes. Son premier prototype a été implémenté dans Go, mais a ensuite été réécrit en C en raison de problèmes de performances dus à la manière dont Go interagit avec C.
Dqlite utilise C-Raft, une implémentation optimisée de Raft en C, pour obtenir un consensus transactionnel et une tolérance aux pannes hautes performances tout en préservant l’efficacité et la faible empreinte de SQLite :
- Dqlite - High-Availability SQLite
- canonical/dqlite
- LXD releases Dqlite 1.0, a C library to implement an embeddable, persistent SQL database engine with Raft consensus | Packt Hub
- A Distributed SQLite - What Are the Possibilities?
Je pars donc du schéma suivant pour tester ce mode HA avec Dqlite :
Je provisonne mon serveur Rancher dans Hetzner Cloud :
et je continue avec trois autres instances Ubuntu 18.04 LTS qui me serviront de noeuds maîtres. Dans la première, je lance l’initialisation du cluster. Pour commencer, Il faut lancer cette première instance avec l’indicateur cluster-init pour activer le clustering et un jeton qui sera utilisé comme secret partagé pour joindre d'autres noeuds au cluster :
Pour exécuter K3s dans ce mode avec Dqlite, on doit donc disposer d’un nombre impair de nœuds maître. Rancher nous recommande de commencer avec trois nœuds.
Le premier noeud maître initialisé, je peux joindre les deux autres noeuds maîtres à ce cluster très simplement avec cette commande :
Les trois noeuds maîtres sont alors actifs :
Lancement de trois nouvelles instances Ubuntu 18.04 LTS qui feront office de noeuds Worker dans le cluster K3s avec ce petit script :
Le cluster est complet et opérationnel :
Installation de ZeroTier sur les noeuds avec Bolt pour l’installation de MetalLB :
Bolt - open source, agentless IT automation
J’importe mon nouveau cluster dans Rancher :
On distingue bien les rôles de chaque noeuds dans le cluster :
Installation de MetalLB et de la configuration sur une segment L2 :
Traefik prend une des adresses du segment configuré avec MetalLB :
Test rapide avec le sempiternel démonstrateur FC via ce manifest en YAML :
Le démonstrateur est accessible via une adresse IP fournie par MetalLB et ZeroTier :
À partir de cette version 1.0.0, K3s envisage de prendre en charge l’exécution d’un plan de contrôle hautement disponible sans recourir à un magasin de données externe. Cela signifie qu’il n’est pas nécessaire de gérer un magasin de données externe etcd ou SQL en production. Bien que cette fonctionnalité soit actuellement expérimentale, elle préfigure l’architecture principale pour l’exécution future de clusters K3s en mode HA.
A suivre !
Top comments (0)