Initier un cluster K3S en mode HA …
Il est visiblement possible d’initier expérimentalement un cluster Kubernetes avec Rancher K3S en haute disponibilité vis à vis des noeuds maîtres depuis la version 0.7.0 (même si une issue sur le dépôt github de K3S a été ouverte à ce sujet) :
Initial "v1" HA Support · Issue #618 · rancher/k3s
Car officiellement on était habituellement sur ce type de structure dans un cluster K3S :
Je commence par créer un premier noeud Ubuntu 18.04 LTS sur Hetzner Cloud qui fera office de noeud Etcd et de Load Balancer pour ce futur cluster :
En utilisant toujours le même gabarit CX11 à l’avenir avec 1 vCPU et 2 Go de RAM :
Je récupère les binaires relatifs à Etcd sur le dépôt Github de ce dernier :
Et je les installe sur l’instance :
Je peux lancer mon serveur Etcd qui fait office ici de backend de stockage pour ce futur cluster :
A ce stade, je crée trois autres instances Ubuntu 18.04 LTS qui vont servir de noeuds maîtres du cluster K3S :
Avec ces adresses IP publiques, je peux commncer l’installation d’un Load Balancer avec l’utilisation de gobetween :
un équilibreur de charge L4 (et proxy inverse) libre, open-source, moderne et minimaliste …
gobetween - modern & minimalistic L4 load balancer
On peut l’installer simplement via snap :
$ snap install gobetween --edge
Install gobetween for Linux using the Snap Store | Snapcraft
Je modifie avec les adresses IP publiques des noeuds maîtres le fichier /var/snap/gobetween/common/gobetween.toml
Je relance le service et le Load Balancer est prêt :
$ snap restart gobetween
Un équilibreur de charge externe a donc été configuré pour ces nœuds maître sur le port TCP 6443 :
Par la suite j’installe la nouvelle version de Rancher K3S sur les noeuds maîtres :
ainsi qu’une connexion à ZeroTier pour MetalLB :
Quand une adresse IP est utilisée au lieu d’un nom d’hôte pour l’équilibreur de charge, cette adresse IP est incluse comme ici avec un indicateur tls-san lors de la procédure de lancement des noeuds maîtres :
Pour amorcer les nœuds maîtres en haute disponibilité, les mots de passe appropriés doivent être copiés sur tous les nœuds. En passant
--bootstrap fullle noeud maître essaiera de lire les données d’amorçage à partir du serveur Etcd. Si elles n’existent pas, elles seront créées, puis les certificats seront écrits dans le serveur Etcd s’ils n’existent pas déjà. L’utilisation de--bootstrap readne récupérera que les données du serveur Etcd et une erreur s’il n’en existe aucune, et--bootstrap writeécrira toujours les données d’amorçage sur le serveur etcd mais ne les lira pas. La valeur par défaut consiste à n’effectuer aucune opération d’amorçage.
Le cluster K3S laisse alors apparaitre les trois noeuds maîtres en haute disponibilité :
Je peux substituer l’adresse du serveur dans le fichier Kubeconfig avec celle du Load Balancer :
Il est alors possible de relier des noeuds “Agent” dans ce cluster K3S :
Par l’ajout de trois nouveaux noeuds Ubuntu 18.04 LTS dans Hetzner :
J’ai donc septs noeuds au total pour ce cluster K3S en mode HA (trois autres noeuds agents ont été créés, en se connectant à l’adresse IP publique de l’équilibreur de charge des nœuds principaux) :
Lorsqu’un agent se connecte au serveur, il parcourt tous les noeuds finaux du cluster K3S et se connecte à un tunnel inverse aux noeuds maîtres afin que ces derniers puissent communiquer avec lui. Les points de terminaison du cluster K3S sont surveillés et toute modification entraînera des déconnexions d’anciens nœuds ou une connexion à de nouveaux nœuds.
Ici tous les noeuds sont opérationnels :
Installation de MetalLB pour fournir un service de Load Balancing interne au cluster K3S en lien avec ZeroTier :
Le mode couche 2 avec MetalLB est le plus simple à configurer et n’exige pas que les adresses IP soient liées aux interfaces réseau des noeuds de ce cluster. Il fonctionne en répondant directement aux requêtes ARP pour donner l’adresse MAC de la machine aux clients. J’utilise donc ici un segment d’adresses IP en lien avec le plan d’adressage défini dans ZeroTier dans la configuration de MetalLB via ce fichier de manifest YAML :
Je peux tester simplement mon traditionnel démonstrateur FC avec ce manifest YAML :
$ kubectl apply -f deployment.yaml
L’adresse IP retournée me permet d’accéder sans surprise à la page web du demonstrateur FC :
Avec le déploiement du metrics-server dans le cluster, j’ai accès rapidement à un simple monitoring de ce dernier :
$ git clone https://github.com/kubernetes-incubator/metrics-server
$ kubectl create -f deploy/1.8+/
kubernetes-incubator/metrics-server
Pour vérifier la haute disponibilité des trois noeuds maîtres du cluster K3S, j’arrête les deux dernières instances de ce trio :
Je n’ai alors plus qu’un seul noeud maître :
Et le cluster K3S est toujours actif :
Pour conclure, comme l’indiquait Erik Wilson dans l’issue sur Github, il est prévu dans l’avenir la mise en place d’un proxy d’équilibrage de charge sur chaque noeud du cluster K3S afin d’éviter le recours à un équilibreur de charge externe. Et également la mise en place de MySQL & PostgreSQL derrière une interface Etcd3 …
A suivre !
Top comments (0)