🚨 Avertissement
Ces procédures sont des opérations sensibles. Elles doivent être effectuées par des opérateur qualifiés maitrisant Kubernetes.
Arkhn décline toute responsabilité si ces procédures sont exécutées sans avoir averti et consulté le support d'Arkhn.
¶ Perte d'un noeud du cluster
¶ Rétablir la plateforme Arkhn malgré l'indisponibilité d'un noeud
En cas d'indisponibilité d'un noeud du cluster, la plupart des pods est recréée sur les noeuds restants. Néanmoins, certains ne sont pas déplacés automatiquement.
Certains ne peuvent pas être recréés ailleurs en l'état de la plateforme. Des travaux supplémentaires sont prévus pour améliorer leur robustesse.
- PostgreSQL (Datalab / Datalake)
- Vault (Datalab / Datalake)
- Prometheus (Datalab / Datalake)
- ElasticSearch (Datalab / Datalake)
- Clickhouse (Datalake)
- Coder (instance) (Datalake)
- Nexus (Datalab / Datalake)
- Redis (Datalab / Datalake)
Certains nécessitent d'indiquer au cluster qu'il faut « oublier » les ressources créées sur ce noeud. - DCR
- Keycloak
Pour recréer ces ressources la commande à jouer est :
kubectl drain <node-name> --force --grace-period=0 --delete-emptydir-data --ignore-daemonsets
Une fois le noeud réintégré au cluster, il faut réactiver son utilisation :
kubectl uncordon <node-name>
¶ Réintégration d'un noeud après une indisponibilité prolongée ou une restauration
Si un noeud reste coupé du cluster trop longtemps ou qu'il est restauré dans un état antérieur, sa copie locale de la base etcd est obsolète. Il échouera à rejoindre le control plane.
On voit cette erreur dans les logs du service k3s:
tocommit(17967124) is out of range [lastIndex(17966221)]. Was the raft log corrupted, truncated, or lost?
La procédure est la suivante:
Arrêter le service et effacer sa copie locale de la base etcd :
systemctl stop k3s
rm -rf /var/lib/rancher/server/db/etcd/
Depuis un des noeuds du control plane, retirer le noeud du cluster :
export ETCDCTL_CACERT=/var/lib/rancher/server/tls/etcd/server-ca.crt ;\
export ETCDCTL_CERT=/var/lib/rancher/server/tls/etcd/client.crt ;\
export ETCDCTL_KEY=/var/lib/rancher/server/tls/etcd/client.key
etcdctl member list #identify the node_id
etcdctl member remove <node_id>
Sur le noeud à réintégrer, éditer le service pour lui indiquer l'adresse d'un noeud actif :
vi /etc/systemd/system/k3s.service
#...
ExecStart=/usr/local/bin/k3s server -server https://<healthy-master-node-hostname>:6443
#...
Recharger la configuration systemd et démarrer le service k3s :
systemctl daemon-reload
systemctl start k3s
Si le noeud échoue à rejoindre le cluster avec une erreur de token, il faut ajouter le chemin du token dans son ExecStart :
ExecStart=/usr/local/bin/k3s server -server https://<healthy-master-node-hostname>:6443 -token-file /var/lib/rancher/server/token
Puis :
systemctl daemon-reload
systemctl start k3s
¶ Indisponibilité d'une bulle sécurisée
¶ Redémarrage via l'interface d'admin
En cas d'indisponibilité d'une bulle sécurisée, la première chose à faire est de la redémarrer via l'interface Arkhn admin. 🔄
¶ Recréation forcée de la DCR
Si l'indisponibilité persiste après le redémarrage de la bulle, il faut supprimer le pod de la DCR pour forcer sa re-création.
Il faut d'abord identifier le pod de la DCR. :
kubectl -n arkhn get po -l "kubevirt.io"=virt-launcher
Le pod a un nom qui suit ce pattern :
virt-launcher-<id-dcr>-xxxxx
Pour supprimer le pod :
kubectl -n arkhn delete po virt-launcher-<id-dcr>-xxxxx