Guide d'installation rapide de SafeKit avec Kubernetes (module miroir k3s.safe)

Guide d'installation rapide de SafeKit avec Kubernetes K3S sur Linux

2. D'abord sur les deux nœuds

Sur 2 nœuds Linux Ubuntu 20.04, en tant que root :

Assurez-vous que le nœud a accès à Internet (peut-être via un proxy)
Copiez k3sconfig.sh, k3s.safe et le package safekit_xx.bin dans un répertoire et placez-vous dedans (cd)
Renommer le fichier .bin en "safekit.bin"
Assurez-vous que k3sconfig.sh et safekit.bin sont exécutables.
Modifiez le script k3sconfig.sh en personnalisant les variables d'environnement en fonction de votre environnement (dont l'adresse IP virtuelle)
Exécuter sur les deux nœuds : ./k3sconfig.sh prereq

Le script va :

Installer les packages Debian requis : alien, nfs-kernel-server, nfs-common, mariadb-server
Sécuriser MariaDB
Créer des répertoires pour la réplication de fichiers
Préparer le serveur NFS pour le partage des répertoires répliqués
Installer SafeKit

3. Sur le premier nœud

Exécutez sur le premier nœud : ./k3sconfig.sh first

Le script va :

Créer la base de données de configuration K3S et l'utilisateur k3s
Créer le fichier de stockage des volumes persistants (fichier fragmenté) et le formater en tant que système de fichiers xfs
Créer la configuration du cluster safekit et l'appliquer
Installer et configurer le module k3s.safe sur le cluster
Démarrer le module k3s en tant que "prim" sur le premier nœud
Télécharger, installer et démarrer k3s
Télécharger et installer la charte Helm nfs-subdir-external-provisioner
Afficher le jeton K3S (à utiliser lors de la phase d'installation du deuxième nœud)


/opt/safekit/safekit –H "*" state
---------------- Server=http://10.0.0.20:9010 ----------------
admin action=exec
--------------------- k3s State ---------------------

  Local  (127.0.0.1)    : PRIM (Service : Available)(Color : Green)
Success
---------------- Server=http://10.0.0.21:9010 ----------------
admin action=exec
--------------------- k3s State ---------------------

  Local  (127.0.0.1)    : SECOND (Service : Available)(Color : Green)
Success

7. Tests

Arrêtez le nœud PRIM en faisant défiler son menu contextuel et en cliquant sur Stop.
Vérifiez qu'il y a un basculement sur le nœud 2 qui doit devenir ALONE (vert).
Et avec des lignes de commande sous Linux, vérifiez le basculement des services (arrêtés sur le nœud 1 dans le script stop_prim et démarrés sur le nœud 2 dans le script start_prim). MariaDB et K3S devraient s'exécuter sur le nœud 2.

Si ALONE (vert) n’est pas atteint sur le nœud 2, analysez pourquoi avec le journal du module du nœud 2.

cliquez sur node2 pour afficher le journal du module.
exemple de journal de module SQL Server où le nom du service dans start_prim n'est pas valide. Le processus sqlserver.exe est surveillé mais comme il n'est pas démarré, à la fin le module s'arrête.

Si tout va bien, lancez un démarrage du nœud 1, qui resynchronisera les répertoires répliqués depuis le nœud 2.

Si les choses vont mal, arrêtez le nœud 2 et forcez le démarrage en tant que primaire du nœud 1, qui redémarrera avec ses données localement saines au moment de l'arrêt.

Plus d'informations sur les tests dans le Guide de l'utilisateur.

8. Essayez le cluster avec une application Kubernetes telle que WordPress

Vous avez l'exemple d'une installation WordPress : un portail web avec une base de données implémentée par des pods.

Vous pouvez déployer votre propre application de la même manière.

WordPress est automatiquement hautement disponible :

avec ses données (php + base de données) dans des volumes persistants répliqués en temps réel par SafeKit
avec une adresse IP virtuelle pour accéder au site WordPress pour les utilisateurs
avec basculement automatique et réintégration automatique

Remarques:

Le chart WordPress définit un service à load balancer qui écoute sur les ports <service.port> et <service.httpsport>.
WordPress est accessible via l'url : http://<virtual-ip>:<service.port>.
L'IP virtuelle est gérée par SafeKit et automatiquement basculée en cas de panne.
Par défaut, K3S implémente des load balancers avec Klipper.
Klipper écoute sur <virtual ip>:<service.port> et achemine les paquets TCP/IP vers l'adresse IP et le port du pod WordPress qu'il a sélectionné.

$ export KUBECONFIG=/etc/rancher/k3s/k3s.yaml
$ helm repo add bitnami https://charts.bitnami.com/bitnami
$ helm install my-release bitnami/wordpress --set global.storageClass=nfs-client --set service.port=8099,service.httpsPort=4439

10. Si nécessaire, configurez un checker splitbrain

Voir ci-dessous "Quels sont les différents scénarios en cas d'isolement réseau dans un cluster ?" pour savoir si vous devez configurer un checker splitbrain.
Dans la configuration du module, cliquez sur Advanced configuration (voir image) pour modifier userconfig.xml.

Déclarez le checker splitbrain en ajoutant dans la section <check> de userconfig.xml :

<service>
  ...
  <check>
   ...
   <splitbrain ident="witness" exec="ping" arg="IP du witness"/>
  </check>

Appliquez la configuration avec Save and apply pour redéployer le fichier userconfig.xml modifié sur les deux nœuds (le module doit être arrêté sur les deux nœuds à l'étape Save and apply).

Paramètres :

ident="witness" identifie le témoin (witness) avec un nom de ressource : splitbrain.witness. Vous pouvez modifier cette valeur pour identifier le témoin.
exec="ping" fait référence au code ping à exécuter. Ne modifiez pas cette valeur.
arg="witness IP" est un argument pour le ping. Changez cette valeur avec l'IP du témoin (un élément robuste, typiquement un routeur).

Lorsqu'il y a un isolement réseau, le comportement par défaut est :

comme les heartbeats sont perdus pour chaque nœud, chaque nœud passe en ALONE et exécute l'application avec son adresse IP virtuelle (double exécution de l'application modifiant ses données locales),
lorsque l'isolement est réparé, un nœud ALONE est obligé de s'arrêter et de resynchroniser ses données depuis l'autre nœud,
à la fin, le cluster est PRIM-SECOND (ou SECOND-PRIM selon la détection d'adresse IP virtuelle en double faite par Windows).

Lorsqu'il y a un isolement du réseau, le comportement avec un split-brain checker est :

un split-brain checker a été configuré avec l'adresse IP d'un témoin (typiquement un routeur),
le split-brain agit lorsqu'un serveur passe de PRIM à ALONE ou de SECOND à ALONE,
en cas d'isolement du réseau, avant de passer en ALONE, les deux nœuds testent l'adresse IP,
le nœud qui peut accéder à l'adresse IP passe à ALONE, l'autre passe à WAIT,
lorsque l'isolement est réparé, le nœud WAIT resynchronise ses données et devient SECOND.

Remarque : Si le témoin est en panne ou déconnecté, les deux nœuds passent à WAIT et l'application n'est plus en cours d'exécution. C'est pourquoi vous devez choisir un témoin robuste comme un routeur.