Maintenance d’un nœud

Introduction

Dans un environnement Kubernetes de production, les nœuds doivent souvent faire l’objet d’opérations de maintenance. Le défi consiste à effectuer ces opérations sans perturber inutilement les charges de travail.

Imaginez que le nœud soit une chambre d’hôtel et que les pods soient des clients. Si vous devez rénover la chambre, vous ne pouvez pas simplement y entrer pendant que les clients dorment. Vous devez suivre un processus courtois et sûr.

Dans ce lab, vous apprendrez le processus standard de maintenance d’un nœud :

• Cordon (Ne pas déranger) : placez sur la porte un panneau indiquant « Pas de nouveaux clients ». L’hôtel (le scheduler) cesse d’envoyer de nouvelles personnes dans cette chambre.
• Drain (Évacuer) : demandez courtoisement aux clients actuels de partir et déplacez-les vers une autre chambre disponible.
• Maintenance : effectuez les opérations nécessaires, comme la rénovation.
• Uncordon (Rouvrir) : retirez le panneau et autorisez à nouveau la planification.

Vous travaillerez avec un cluster Minikube local pour simuler ce processus.

Marquer le nœud comme non planifiable

Avant d’effectuer toute opération de maintenance, nous devons nous assurer que le scheduler Kubernetes ne place aucun nouveau pod sur le nœud concerné. Cette opération s’appelle le « cordon ». Elle revient à placer sur la porte de la chambre d’hôtel un panneau « Ne pas déranger » ou « Hors service ».

Il s’agit d’une décision de planification, et non d’un arrêt. Un nœud marqué comme non planifiable peut rester sain et continuer à exécuter ses pods existants. Kubernetes le marque simplement comme indisponible pour les nouveaux placements afin que vous puissiez commencer la maintenance de manière contrôlée.

Commencez par identifier le nom du nœud. Exécutez la commande suivante :

kubectl get nodes

Vous devriez voir un seul nœud (par exemple, minikube) avec l’état Ready.

Pour marquer le nœud comme non planifiable, utilisez la commande cordon. Nous utiliserons une substitution de commande $() pour récupérer automatiquement le nom du nœud :

kubectl cordon $(kubectl get nodes -o jsonpath='{.items[0].metadata.name}')

Vérifiez ensuite à nouveau l’état du nœud :

kubectl get nodes

L’état devrait passer à Ready,SchedulingDisabled. Cela confirme que le nœud est maintenant marqué comme non planifiable. Aucun nouveau pod ne sera planifié sur ce nœud, mais les pods existants continuent de fonctionner normalement.

Évacuer le nœud

Le cordon empêche uniquement la planification de nouveaux pods. Des applications sont toujours en cours d’exécution sur le nœud. Pour les retirer en toute sécurité, utilisez la commande drain.

Cette commande évacue les pods. Kubernetes constate alors que le nombre souhaité de réplicas (2) n’est plus atteint et tente de créer de nouveaux remplaçants sur d’autres nœuds disponibles.

Le terme évacuer est important ici. L’objectif de drain n’est pas d’arrêter brutalement les applications. La commande demande aux charges de travail de quitter le nœud selon un processus pris en compte par Kubernetes, afin que les contrôleurs puissent les remplacer et que les règles d’arrêt soient respectées. C’est pourquoi drain est plus sûr que la suppression manuelle de processus choisis au hasard sur le nœud.

Exécutez la commande drain. Dans cet environnement, nous devons ajouter quelques options pour forcer l’évacuation :

• --ignore-daemonsets : certains pods système (DaemonSets) sont liés au nœud et ne peuvent pas être déplacés. Nous les ignorons.
• --delete-emptydir-data : si un pod utilise un stockage temporaire local, l’évacuation supprimera ces données. Nous confirmons que cette suppression est acceptable.
• --force : cette option est nécessaire pour supprimer les pods qui ne sont pas gérés par un ReplicationController, un ReplicaSet, un Job, un DaemonSet ou un StatefulSet, comme storage-provisioner dans Minikube.

kubectl drain $(kubectl get nodes -o jsonpath='{.items[0].metadata.name}') --ignore-daemonsets --delete-emptydir-data --force

La sortie indiquera que les pods sont en cours d’évacuation.

Remarque : dans ce lab Minikube à nœud unique, lorsque vous évacuez l’unique nœud, les pods seront évacués, puis passeront à l’état Pending. Cela se produit parce qu’il n’y a « aucune autre chambre dans l’hôtel » où les déplacer. Dans un véritable cluster comportant plusieurs nœuds, ils seraient immédiatement déplacés vers un nœud sain.

Vérifier l’état

Après avoir évacué le nœud, il est important de vérifier ce qui est arrivé à nos applications.

Cette étape de vérification vous apprend une habitude importante de l’administration de clusters : ne vous arrêtez pas après avoir exécuté une commande de maintenance. Inspectez toujours le résultat de la planification du point de vue de la charge de travail. Une opération de maintenance n’est réussie que si les applications sont placées là où elles doivent l’être.

Vérifiez l’état de vos pods :

kubectl get pods

Comme indiqué précédemment, les pods devraient probablement être à l’état Pending.

Pour comprendre pourquoi ils sont dans cet état, demandez des informations à Kubernetes. Affichez la description de l’un des pods :

kubectl describe pod $(kubectl get pods -o jsonpath='{.items[0].metadata.name}')

Recherchez la section Events en bas de la sortie. Vous devriez voir un message similaire à « 0/1 nodes are available: 1 node(s) are unschedulable. »

Cela confirme que l’évacuation a réussi. Le scheduler souhaite exécuter le pod, mais respecte le panneau « Ne pas déranger » placé sur l’unique nœud disponible.

Réactiver la planification du nœud

Imaginez que vous avez terminé votre « rénovation » (mise à niveau du système d’exploitation ou maintenance). Il est temps de rouvrir la chambre et de remettre le nœud en service.

uncordon supprime simplement le blocage de la planification. La commande ne force pas l’envoi immédiat de pods sur le nœud. Elle indique au scheduler que le nœud peut de nouveau être sélectionné pour de futurs placements ; la réconciliation normale prend ensuite le relais.

Pour cela, utilisez la commande uncordon. Elle retire le panneau « Ne pas déranger ».

kubectl uncordon $(kubectl get nodes -o jsonpath='{.items[0].metadata.name}')

Vérifiez maintenant l’état du nœud :

kubectl get nodes

L’état devrait redevenir Ready : l’étiquette SchedulingDisabled doit avoir disparu.

Enfin, vérifiez à nouveau vos pods. Le nœud étant de nouveau disponible, le scheduler Kubernetes devrait maintenant placer les pods Pending sur ce nœud.

kubectl get pods

Vous devriez les voir passer de Pending à ContainerCreating, puis finalement à Running.

Résumé

Dans ce lab, vous avez mis en pratique le cycle de maintenance sécurisé d’un nœud Kubernetes. Vous avez appris à :

1. Marquer un nœud comme non planifiable (cordon) pour empêcher la planification de nouveaux pods (Ne pas déranger).
2. Évacuer un nœud (drain) pour retirer en toute sécurité les charges de travail en cours d’exécution.
3. Réactiver la planification d’un nœud (uncordon) pour le remettre en service.

Ces commandes sont essentielles pour les administrateurs système qui doivent garantir une haute disponibilité. Elles permettent de réparer l’infrastructure sans provoquer d’interruption pour vos applications — dans un cluster comportant plusieurs nœuds, bien entendu !