Démarrage et arrêt d’un nœud

Démarrez et arrêtez les nœuds en toute sécurité dans Automation Suite, couvrant le comportement de démarrage et d’arrêt manuels et automatiques.

Cette page explique le comportement de démarrage et d’arrêt manuels et automatiques d’Automation Suite.

Important :

Vous devez toujours procéder en arrêtant un nœud, en effectuant l'opération requise, en attendant que le nœud soit sain, puis en arrêtant l'autre nœud pour effectuer la même opération.

Le tableau suivant décrit différents scénarios que vous pouvez rencontrer lors de l’arrêt de services de cluster ou de nœuds. Le tableau fournit des actions détaillées que vous devez effectuer pour chaque situation, ainsi que des conseils sur la compréhension du comportement attendu en réponse à ces actions.

Scénario	Action	Comportement attendu
Arrêter les services de cluster sur un nœud sans désactiver le nœud, à des fins de maintenance ou pour toute autre raison.	Exécutez manuellement les étapes d'arrêt. Redémarrez les services en utilisant le démarrage manuel ou en redémarrant la machine.	Dans un scénario haute disponibilité, la plupart des services resteront actifs. Le nœud devrait démarrer sans aucun problème et tous les services en panne devraient redémarrer.
Arrêt de tous les services du cluster sans désactiver les nœuds, à des fins de maintenance ou pour toute autre raison.	Sur tous les nœuds, en commençant par les nœuds d'agent, exécutez manuellement les étapes d'arrêt. Redémarrez les services en utilisant le démarrage manuel ou en redémarrant les machines, en commençant par les nœuds de serveur.	Les services deviendront indisponibles. Les nœuds devraient démarrer sans problème.
Arrêt de tous les nœuds.	Si votre portail de gestion de l'hyperviseur (tel que VMware, AWS) permet aux services de s'arrêter en douceur sans mettre fin à la machine, effectuez un arrêt normal. Par défaut, le sous-système système autorise une période d'arrêt des services avant leur arrêt forcé. Cependant, si votre système écrase les temps d'arrêt configurés, cela peut interférer avec un arrêt en douceur. Par exemple, sur AWS, la plate-forme peut forcer l'arrêt d'une machine virtuelle après deux minutes. Les services doivent donc être arrêtés manuellement, car un drainage de nœud peut prendre jusqu'à 5 minutes (il s'agit d'une exigence pour un arrêt en douceur).	Si l’arrêt est en douceur, les nœuds devraient démarrer sans problème. Si le cluster a été arrêté pendant plus de 6 heures et que l'authentification Kerberos est configurée, vous devrez peut-être renouveler les tickets Kerberos après le redémarrage. Pour plus de détails, consultez Récupération de l'authentification Kerberos après le redémarrage de la machine virtuelle.
Arrêt d'un nœud individuel.	Si votre portail de gestion de l'hyperviseur (tel que VMware, AWS) permet aux services de s'arrêter en douceur sans mettre fin à la machine, effectuez un arrêt normal. Par défaut, le sous-système système autorise une période d'arrêt des services avant leur arrêt forcé. Cependant, si votre système écrase les temps d'arrêt configurés, cela peut interférer avec un arrêt en douceur. Par exemple, sur AWS, la plate-forme peut forcer l'arrêt d'une machine virtuelle après deux minutes. Les services doivent donc être arrêtés manuellement, car un drainage de nœud peut prendre jusqu'à 5 minutes (il s'agit d'une exigence pour un arrêt en douceur).	Si le processus d'arrêt n'est pas forcé, le nœud devrait redémarrer sans aucun problème.
Mettre fin de force un nœud de serveur.	Non Applicable.	Dans la plupart des cas, le nœud démarrera, mais il pourra y avoir des problèmes avec certains services qui utilisent des données persistantes. Bien que ces problèmes soient généralement récupérables, la configuration de sauvegardes est fortement recommandée. Le pod Insights ne redémarrera pas tant que le nœud d'origine n'est pas de nouveau en ligne, afin d'éviter toute perte de données potentielle. Si le nœud n'est pas récupérable, contactez l'équipe d'assistance.

Comportement d'arrêt

Lors de l’arrêt, systemd arrête les services dans l’ordre dans lequel ils ont été démarrés. Étant donné que le service node-drain comporte la directive After=rke2-server.service ou After=rke2-agent.service, il exécute sa séquence d’arrêt avant l’arrêt de rke2-service. Cela signifie que dans un système correctement configuré, l’arrêt correct du nœud est une opération sécurisée.

Redémarrage manuel

Si vous prévoyez d’arrêter le service RKE2 et de redémarrer la machine, procédez comme suit :

1. Pour vous assurer que le cluster est sain lors de l'exécution de l'activité de maintenance du nœud, vous devez drainer les charges de travail exécutées sur ce nœud vers d’autres nœuds. Pour drainer le nœud, exécutez la commande suivante :

   systemctl stop node-drain.service
   

2. Arrêtez le processus Kubernetes sur le nœud, selon le type de nœud:

   • Sur un nœud de serveur:

     systemctl stop rke2-server
     

   • Sur les nœuds d'agent:

     systemctl stop rke2-agent
     

3. Mettez fin aux services rke2 et Containerd et tous les processus enfants :

   rke2-killall.sh
   

Pour télécharger le script rke2-killall.sh , reportez-vous à la section Liens de téléchargement des packages d’installation.

Comportement de démarrage

Le rke2-service commence et est suivi de node-drainer et de node-uncordon. node-drainer n’effectue aucune action au démarrage et renvoie simplement la confirmation que le service est actif.

Le node-uncordon ne s’exécute qu’une fois et démarre /opt/node-drain.sh nodestart, ce qui déboucle le nœud. Dans le cadre de la procédure de drainage qui a lieu à l’arrêt, cela boucle le nœud, ce qui le rend non planifiable. Cet état persiste au démarrage du service rke2. Le nœud doit donc être débouclé après le redémarrage de rke2-service.

Démarrage manuel

Le service démarre automatiquement avec Automation Suite. Cependant, si rke2-service était arrêté manuellement, vous devez redémarrer le service en exécutant les commandes suivantes :

1. Démarrez le processus Kubernetes sur le nœud, selon le type de nœud:

   • Sur un nœud de serveur:

     systemctl start rke2-server
     

   • Sur les nœuds d'agent:

     systemctl start rke2-agent
     

2. Une fois le service rke2 démarré, débouclez le nœud pour vous assurer que Kubernetes peut désormais planifier des charges de travail sur ce nœud :

   systemctl restart node-uncordon
   

3. Une fois le nœud démarré, vous devez vider le nœud :

   systemctl start node-drain.service
   

   Important :

   Si vous ignorez cette étape, le service Kubelet pourrait s’arrêter de manière incorrecte si le système est redémarré.

Correction des nœuds du cluster

Lors du correctif ou du redémarrage des nœuds de serveur, l'ordre dans lequel vous appliquez les modifications affecte directement la stabilité du cluster.

Vérifications avant le correctif

Avant de manipuler un nœud, confirmez que le cluster est sain:

1. Confirmez que les trois membres etcd sont sains:

   ETCD_CONTAINER="$(/var/lib/rancher/rke2/bin/crictl ps --name etcd --state Running -q | head -n1)"
   /var/lib/rancher/rke2/bin/crictl exec "$ETCD_CONTAINER" etcdctl \
     --endpoints=https://127.0.0.1:2379 \
     --cacert=/var/lib/rancher/rke2/server/tls/etcd/server-ca.crt \
     --cert=/var/lib/rancher/rke2/server/tls/etcd/server-client.crt \
     --key=/var/lib/rancher/rke2/server/tls/etcd/server-client.key \
     endpoint health --cluster
   

2. Vérifiez les boucles de plantage sur n'importe quel nœud:

   journalctl -u rke2-server --since "2 hours ago" | grep -i "FAILURE\|left-over\|unclean"
   

3. Vérifiez qu’il existe un instantané etcd récent:

   ls -lth /var/lib/rancher/rke2/server/db/snapshots/ | head -5
   

Important :

Ne commencez pas à corriger si un nœud est déjà en boucle de plantage ou si les vérifications de l’état etcd échouent. Résolvez l’instabilité avant de continuer.

Identifier le nœud d’amorçage

Le nœud d’amorçage est généralement le responsable etcd actuel. Pour l'identifier, exécutez la commande suivante et recherchez IS LEADER: true:

ETCD_CONTAINER="$(/var/lib/rancher/rke2/bin/crictl ps --name etcd --state Running -q | head -n1)"
/var/lib/rancher/rke2/bin/crictl exec "$ETCD_CONTAINER" etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/var/lib/rancher/rke2/server/tls/etcd/server-ca.crt \
  --cert=/var/lib/rancher/rke2/server/tls/etcd/server-client.crt \
  --key=/var/lib/rancher/rke2/server/tls/etcd/server-client.key \
  endpoint status --cluster

Ordre des correctifs

Corrigez toujours d'abord le nœud d'amorçage, puis les nœuds secondaires un à la fois.

Important :

Le fait de corriger le nœud d’amorçage garantit d’abord que lorsqu’il tombe en panne, les deux nœuds secondaires maintiennent le quorum et électionnent un nouveau responsable. Le nœud d'amorçage rejoint ensuite en tant que suivi dans un état propre. Le fait de corriger les nœuds secondaires en premier et de laisser le nœud d’amorçage pour la dernière fois peut provoquer une instabilité plus importante si le nœud d’amorçage ne parvient pas à se rejoindre correctement.

Après la correction et le redémarrage de chaque nœud, confirmez qu’il est entièrement de retour avant de passer au nœud suivant:

1. Vérifiez que le statut du nœud est Ready:

   kubectl get nodes
   

2. Confirmez que les trois membres etcd sont sains:

   ETCD_CONTAINER="$(/var/lib/rancher/rke2/bin/crictl ps --name etcd --state Running -q | head -n1)"
   /var/lib/rancher/rke2/bin/crictl exec "$ETCD_CONTAINER" etcdctl \
     --endpoints=https://127.0.0.1:2379 \
     --cacert=/var/lib/rancher/rke2/server/tls/etcd/server-ca.crt \
     --cert=/var/lib/rancher/rke2/server/tls/etcd/server-client.crt \
     --key=/var/lib/rancher/rke2/server/tls/etcd/server-client.key \
     endpoint health --cluster
   

3. Recherchez les erreurs dans les journaux du serveur RKE2:

   journalctl -u rke2-server -n 30
   

Mises à niveau du noyau

Lors de l’exécution d’une mise à niveau du noyau, effacez le magasin d’instantanés du conteneur après avoir exécuté rke2-killall.sh et avant d’appliquer la mise à niveau du noyau. Cela empêche la corruption de l’état du conteneur sur tout nœud, quel que soit l’ordre des correctifs.

Fichiers créés lors de l’installation

Les fichiers d’unité suivants sont créés lors de l’installation :

• rke2-server.service (serveur uniquement): démarre le rke2-server, ce qui démarre le nœud de serveur.
• rke2-agent.service (agent uniquement): démarre le rke2-agent, ce qui démarre le nœud d’agent.
• node-drain.service - Utilisé au moment de l'arrêt. Exécuté avant d’arrêter rke2-agent ou rke2-server et effectue un drainage. A un délai d’attente de 300 secondes.
• node-uncordon.service - Utilisé au démarrage pour déboucler un nœud.
• var-lib-kubelet.mount - Généré automatiquement par le générateur fstab.
• var-lib-rancher-rke2-server-db.mount - Généré automatiquement par le générateur fstab.
• var-lib-rancher.mount - Généré automatiquement par le générateur fstab.

Il n’y a pas de dépendances solides entre les fichiers d’unités. En revanche, node-drain et node-uncordon ont la directive After=rke2-server.service ou After=rke2-agent.service. Cela signifie que ces services démarreront après rke2-server.service.