Initier un cluster Rancher K3S en mode HA …

Image for post
Image for post

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) :

Car officiellement on était habituellement sur ce type de structure dans un cluster K3S :

Image for post
Image for post

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 :

Image for post
Image for post

En utilisant toujours le même gabarit CX11 à l’avenir avec 1 vCPU et 2 Go de RAM :

Image for post
Image for post
Image for post
Image for post

Et je les installe sur l’instance :

Image for post
Image for post

Je peux lancer mon serveur Etcd qui fait office ici de backend de stockage pour ce futur cluster :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

A ce stade, je crée trois autres instances Ubuntu 18.04 LTS qui vont servir de noeuds maîtres du cluster K3S :

Image for post
Image for post

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 …

Image for post
Image for post

On peut l’installer simplement via snap :

$ snap install gobetween --edge
Image for post
Image for post

Je modifie avec les adresses IP publiques des noeuds maîtres le fichier /var/snap/gobetween/common/gobetween.toml

Image for post
Image for post

Je relance le service et le Load Balancer est prêt :

$ snap restart gobetween

Image for post
Image for post

Un équilibreur de charge externe a donc été configuré pour ces nœuds maître sur le port TCP 6443 :

Image for post
Image for post
Image for post
Image for post

ainsi qu’une connexion à ZeroTier pour MetalLB :

Image for post
Image for post

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 :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

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 read ne 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é :

Image for post
Image for post

Je peux substituer l’adresse du serveur dans le fichier Kubeconfig avec celle du Load Balancer :

Image for post
Image for post

Il est alors possible de relier des noeuds “Agent” dans ce cluster K3S :

Image for post
Image for post

Par l’ajout de trois nouveaux noeuds Ubuntu 18.04 LTS dans Hetzner :

Image for post
Image for post

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) :

Image for post
Image for post

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 :

Image for post
Image for post

Installation de MetalLB pour fournir un service de Load Balancing interne au cluster K3S en lien avec ZeroTier :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

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 :

Image for post
Image for post
dhcp.yaml
Image for post
Image for post

Je peux tester simplement mon traditionnel démonstrateur FC avec ce manifest YAML :

$ kubectl apply -f deployment.yaml

Image for post
Image for post
deployment.yaml
Image for post
Image for post

L’adresse IP retournée me permet d’accéder sans surprise à la page web du demonstrateur FC :

Image for post
Image for post

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+/
Image for post
Image for post
Image for post
Image for post

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 :

Image for post
Image for post
Image for post
Image for post

Je n’ai alors plus qu’un seul noeud maître :

Image for post
Image for post

Et le cluster K3S est toujours actif :

Image for post
Image for post

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 …

Image for post
Image for post

A suivre !

Above the clouds, the sky is always blue ...

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store