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

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.
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 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 en cours d’exécution sur le nœud du serveur :

   systemctl start rke2-server

2. Démarrez le processus Kubernetes en cours d’exécution sur le nœud du serveur :

   systemctl start rke2-agent

3. 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

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

   systemctl start node-drain.service

   Important :

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

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 en cours d’exécution sur le nœud du serveur :

   systemctl stop rke2-server

3. Arrêtez le processus Kubernetes en cours d’exécution sur le nœud d’agent :

   systemctl stop rke2-agent

4. Forcez l’arrêt des services rke2 et containerd et tous les processus enfants :

   rke2-killall.sh

   Il devrait déjà se trouver dans le chemin d’accès, mais, il se trouve dans /bin/rke2-killall.sh.

Fichiers créés lors de l’installation

1. 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-service.