MicroK8s : Canonical automatise la haute disponibilité

La haute disponibilité est arrivée sur MicroK8s. Et Canonical tient vraiment à le faire savoir.

Depuis la mi-septembre, cette fonctionnalité était en tête de gondole sur le site officiel du projet. Elle a désormais son onglet dédié.

Son intégration est effective depuis fin août et la sortie de MicroK8s 1.19. Cette nouvelle version de la distribution Kubernetes « légère » (destinée aux déploiements IoT/edge et aux clusters de test locaux) apporte aussi, entre autres :

• La prise en charge de ConfigMap
• Une commande pour la sauvegarde du magasin de données
• Un add-on pour Multus (plug-in destiné à connecter un pod à de multiples interfaces réseau)

MicroK8s : la résilience avec trois nœuds

Concernant la haute disponibilité, elle s’active automatiquement sur les clusters à partir de trois nœuds. C’est la configuration minimale pour assurer la résilience du datastore Dqlite.

Alternative à etcd, Dqlite se fonde sur SQLite. Il y couple, pour gérer la réplication de l’état des clusters, l’algorithme de consensus Raft.
Avec ce dernier, les nœuds peuvent être de quatre types : « leader », « voter », « standby » et « spare ». Les deux premiers participent activement au maintien du datastore. Le troisième stocke une copie de la base de données et peut prendre le relais en cas de panne d’un « leader » ou d’un « voter »*.

Dans la même logique de disponibilité, sur MicroK8s, tous les nœuds exécutent le plan de contrôle principal et les API Kubernetes.

* Le remplacement d’un nœud « leader » peut prendre jusqu’à 5 secondes. La promotion d’un non-votant au rang de votant, jusqu’à 30 secondes.