MicroK8s : Canonical automatise la haute disponibilité
Publié par Clément Bohic le - mis à jour à
Canonical accentue sa communication sur la dernière fonctionnalité phare introduite dans MicroK8s : la haute disponibilité automatisée.
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 :
MicroK8s : la résilience avec trois nouds
Concernant la haute disponibilité, elle s'active automatiquement sur les clusters à partir de trois nouds. 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 nouds 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 nouds exécutent le plan de contrôle principal et les API Kubernetes.
* Le remplacement d'un noud « leader » peut prendre jusqu'à 5 secondes. La promotion d'un non-votant au rang de votant, jusqu'à 30 secondes.