Gérer les nœuds d'un cluster Kubernetes au quotidien

Pour administrer un cluster Kubernetes, vous devez savoir lister, inspecter, labéliser et tainter vos nœuds. Ce guide couvre les opérations courantes : vérifier leur état, organiser votre flotte avec des labels, utiliser les labels de rôle pour la lisibilité, contrôler le placement des Pods avec des taints, et remplacer un nœud défaillant proprement.

Ce que vous allez apprendre

• Lister et inspecter les nœuds d'un cluster avec kubectl
• Attribuer des labels pour organiser vos nœuds (environnement, zone, type de charge)
• Utiliser les labels de rôle node-role.kubernetes.io/ pour la lisibilité
• Appliquer des taints pour contrôler quels pods peuvent tourner sur un nœud
• Remplacer un nœud défaillant avec le workflow complet

Prérequis

• Un cluster Kubernetes fonctionnel (v1.28+)
• kubectl configuré avec des droits suffisants pour gérer les nœuds
• Avoir suivi le guide Observer la santé du cluster
• Connaissances de base sur les Pods et les taints/tolerations

Comment Kubernetes gère les nœuds

Un nœud est une machine (physique ou virtuelle) qui exécute des pods. Chaque nœud fait tourner un kubelet (l'agent Kubernetes) et un container runtime (containerd, CRI-O). Le kubelet s'enregistre automatiquement auprès du plan de contrôle au démarrage, puis envoie régulièrement un heartbeat pour signaler qu'il est disponible.

Le plan de contrôle maintient un objet Node pour chaque machine. Cet objet contient :

Information	Ce qu'elle décrit
Conditions	État du nœud : Ready, MemoryPressure, DiskPressure, PIDPressure
Capacity / Allocatable	Ressources totales vs ressources disponibles pour les pods
Labels	Métadonnées clé-valeur pour organiser et cibler les nœuds
Taints	Restrictions qui repoussent certains pods
Annotations	Métadonnées internes (utilisées par les contrôleurs, le CNI, etc.)

Glissez pour voir

Lister et inspecter les nœuds

Tout diagnostic de nœud commence ici, et dans cet ordre : la vue d'ensemble d'abord, qui dit lesquels vont mal, puis le détail d'un seul, qui dit pourquoi. Inverser revient à inspecter minutieusement un nœud sain pendant qu'un autre est tombé.

Lister tous les nœuds

kubectl get nodes

NAME         STATUS   ROLES           AGE   VERSION
ks-cp1       Ready    control-plane   42h   v1.37.0
ks-worker1   Ready    <none>          42h   v1.37.0
ks-worker2   Ready    <none>          42h   v1.37.0

La colonne ROLES affiche le contenu du label node-role.kubernetes.io/. Il est courant que seuls les nœuds de control plane aient un rôle explicite, tandis que des workers apparaissent avec ROLES=<none> selon l'outil de déploiement utilisé.

Afficher plus de détails

L'option -o wide ajoute l'IP interne, l'OS, le container runtime et l'architecture :

kubectl get nodes -o wide

Inspecter un nœud en détail

kubectl describe node ks-worker1

Cette commande affiche :

• Les conditions du nœud (Ready, pressures)
• Les labels et annotations
• Les taints actifs
• La capacité et les ressources allouées
• La liste des pods qui tournent sur ce nœud
• Les événements récents

Ne confondez pas les deux blocs que describe affiche : la capacité est ce que la machine possède, les ressources allouées sont ce que les requests des pods ont déjà réservé. C'est le second chiffre qui décide des placements à venir, et un nœud peut refuser un pod tout en paraissant inoccupé, si ses réservations sont hautes et sa consommation réelle basse.

Voir les labels d'un nœud

kubectl get nodes --show-labels

La sortie peut être très longue. Pour filtrer sur un label particulier :

kubectl get nodes -l node-role.kubernetes.io/control-plane

Organiser les nœuds avec des labels

Les labels sont des paires clé-valeur attachées aux objets Kubernetes. Sur les nœuds, ils servent à organiser votre flotte et à contrôler le placement des pods via les nodeSelectors et l'affinité de nœud.

Ajouter un label

Un label se pose sur un nœud déjà en service, sans le redémarrer ni interrompre ce qui y tourne. C'est ce qui rend l'opération sûre : elle ne change rien au placement des Pods existants, seulement aux décisions à venir.

kubectl label node ks-worker1 env=production

Vérification :

kubectl get node ks-worker1 --show-labels | grep env=

Modifier un label existant

Ajoutez --overwrite pour changer la valeur d'un label déjà présent :

kubectl label node ks-worker1 env=staging --overwrite

Supprimer un label

Ajoutez un - après le nom du label :

kubectl label node ks-worker1 env-

Labels courants pour les nœuds

Label	Exemple	Usage
env	production, staging	Séparer les charges par environnement
disktype	ssd, hdd	Placer les pods gourmands en I/O sur SSD
zone	eu-west-1a, rack-3	Répartir les réplicas sur plusieurs zones
team	backend, data	Isoler les workloads par équipe

Glissez pour voir

Kubernetes pose lui-même une série de labels sur chaque nœud à son arrivée, notamment kubernetes.io/hostname, kubernetes.io/arch et kubernetes.io/os. Ils sont précieux parce qu'ils sont fiables sans intervention : un nodeSelector sur kubernetes.io/arch fonctionne sur n'importe quel cluster, là où vos propres labels supposent que quelqu'un ait pensé à les poser.

Utiliser un label pour placer un pod

Une fois le label posé, ajoutez un nodeSelector dans votre pod ou deployment pour cibler ce nœud :

spec:
  nodeSelector:
    env: production

Pour des règles de placement plus fines (préférence plutôt qu'obligation), consultez le guide Affinité, taints et tolerations.

Utiliser les labels de rôle pour la lisibilité

La colonne ROLES de kubectl get nodes reflète les labels node-role.kubernetes.io/.... Ces labels améliorent la lisibilité et peuvent être utilisés par vos conventions et vos outils, mais ne constituent pas à eux seuls un mécanisme de placement ou de sécurité.

Attribuer un rôle

kubectl label node ks-worker1 node-role.kubernetes.io/worker=

La valeur est vide par convention, seul le nom du label compte.

Vérification :

kubectl get nodes

NAME         STATUS   ROLES           AGE   VERSION
ks-cp1       Ready    control-plane   42h   v1.37.0
ks-worker1   Ready    worker          42h   v1.37.0
ks-worker2   Ready    <none>          42h   v1.37.0

Attribuer plusieurs rôles

Un nœud peut avoir plusieurs rôles. Ajoutez simplement un deuxième label :

kubectl label node ks-worker1 node-role.kubernetes.io/monitoring=

Le nœud affichera monitoring,worker dans la colonne ROLES : kubectl trie les rôles par ordre alphabétique, et non dans l'ordre où vous les avez ajoutés. Ne cherchez donc pas de sens à leur position.

Supprimer un rôle

La suppression suit la même syntaxe que pour n'importe quel label, un tiret en suffixe. Le nœud continue de fonctionner exactement comme avant : seule la colonne ROLES change, puisque ces labels ne pilotent aucun placement.

kubectl label node ks-worker1 node-role.kubernetes.io/worker-

Contrôler le placement avec les taints

Un taint est une restriction placée sur un nœud qui repousse les pods. Seuls les pods qui déclarent une toleration correspondante peuvent être planifiés sur un nœud tainté.

Effets disponibles

Trois effets existent, et la différence entre eux se joue sur une seule question : que deviennent les pods déjà en place ? Deux d'entre eux les laissent tranquilles, le troisième les expulse. Se tromper d'effet sur un nœud de production est une erreur qu'on ne fait qu'une fois.

Effet	Comportement
NoSchedule	Empêche les nouveaux pods (sans toleration) d'être planifiés sur le nœud. Les pods déjà présents ne sont pas affectés.
PreferNoSchedule	Le scheduler évite ce nœud mais peut y placer un pod s'il n'y a pas d'alternative.
NoExecute	Empêche le scheduling et évince les pods existants qui n'ont pas la toleration.

Glissez pour voir

Ajouter un taint

kubectl taint nodes ks-worker1 maintenance=planned:NoSchedule

Cela signifie : "ne planifie aucun nouveau pod sur ks-worker1, sauf s'il tolère le taint maintenance=planned".

Vérification :

kubectl describe node ks-worker1 | grep -A 5 Taints

Retirer un taint

Le retrait libère immédiatement le nœud pour les prochains placements, mais il ne rapatrie pas les pods qu'un NoExecute aurait évincés : ceux-là ont été replanifiés ailleurs et y restent. Ajoutez un - à la fin :

kubectl taint nodes ks-worker1 maintenance=planned:NoSchedule-

Taints automatiques du plan de contrôle

Par défaut, les nœuds control-plane ont le taint node-role.kubernetes.io/control-plane:NoSchedule. Ce taint empêche les pods applicatifs d'être planifiés sur le plan de contrôle.

kubectl describe node ks-cp1 | grep Taints

Taints:             node-role.kubernetes.io/control-plane:NoSchedule

NoExecute évince les pods existants

Contrairement à NoSchedule qui ne touche qu'au scheduling futur, NoExecute supprime les pods déjà présents qui n'ont pas la toleration. Utilisez-le avec précaution, uniquement quand vous voulez vider un nœud d'un certain type de pods.

Taints automatiques lors de problèmes

Kubernetes pose lui-même certains taints, liés à l'état du nœud : node.kubernetes.io/not-ready, node.kubernetes.io/unreachable, node.kubernetes.io/memory-pressure, node.kubernetes.io/disk-pressure, node.kubernetes.io/pid-pressure et node.kubernetes.io/unschedulable. Leur effet exact sur la planification et l'éviction dépend du type de taint et des tolerations portées par les Pods.

Remplacer un nœud défaillant

Quand un nœud doit être remplacé, pour panne matérielle, fin de vie ou migration, suivez cette procédure en quatre étapes. Elle reprend celle de Préparer une maintenance.

1. Drainer le nœud : évacuez tous les pods vers d'autres nœuds.

   kubectl drain ks-worker1 --ignore-daemonsets --delete-emptydir-data

   Le drain commence par un cordon automatique, puis évince les pods en respectant les PodDisruptionBudgets.

2. Vérifier que les pods sont repositionnés :

   kubectl get pods -A -o wide | grep ks-worker1

   Seuls les pods de DaemonSets doivent rester sur le nœud.

3. Supprimer l'objet Node :

   kubectl delete node ks-worker1

   Le nœud disparaît de kubectl get nodes. Si la machine d'origine revient en ligne avec le même kubelet et la même identité, elle peut se réenregistrer. Si vous remplacez réellement l'instance, évitez de réutiliser le même nom sans en mesurer les conséquences : Kubernetes suppose qu'un nœud de même nom est le même objet logique.

4. Ajouter le nouveau nœud : installez le kubelet et le container runtime sur la nouvelle machine. Le kubelet s'enregistre automatiquement auprès du plan de contrôle. Vérifiez :

   kubectl get nodes

   Le nouveau nœud apparaît avec le statut Ready après quelques secondes. Réappliquez vos labels et rôles si nécessaire.

Automatiser les labels au démarrage

Les labels personnalisés s'appliquent automatiquement, par la configuration du kubelet, --node-labels, ou par votre outil de provisionnement : kubespray, kubeadm join, Terraform. Pour les labels critiques ou réservés, tenez une convention claire et évitez les modifications manuelles opportunistes.

Annotations sur les nœuds

Les annotations de nœud servent surtout aux composants du cluster et aux outils d'administration. En pratique, pour l'exploitation quotidienne, concentrez-vous d'abord sur les conditions, labels et taints.

Vous pouvez ajouter vos propres annotations pour stocker des métadonnées opérationnelles :

kubectl annotate node ks-worker1 maintenance-contact="ops@example.com"

Certaines annotations historiques encore visibles sur un nœud, comme kubeadm.alpha.kubernetes.io/cri-socket ou node.alpha.kubernetes.io/ttl, sont dépréciées : ne les prenez pas pour référence.

Dépannage

Les symptômes ci-dessous partagent une cause : une restriction posée sur le nœud qu'on a oubliée, ou dont on n'a pas mesuré la portée. Avant de suspecter le cluster, relisez donc les taints et les labels du nœud concerné, ce sont eux qui décident.

Symptôme	Cause probable	Solution
Nœud NotReady après ajout	kubelet ne démarre pas ou ne contacte pas l'API server	Vérifier les logs kubelet : journalctl -u kubelet -f
Nœud sans rôle (<none>)	Label node-role.kubernetes.io/ absent	kubectl label node <nom> node-role.kubernetes.io/worker=
Pod non planifié malgré les resources dispo	Taint actif sans toleration correspondante	kubectl describe node <nom> | grep Taints pour identifier le taint
Drain bloqué	PDB empêche l'éviction ou pod sans contrôleur	Vérifier les PDB (kubectl get pdb -A) ; ajouter --force si nécessaire
Labels disparus après redémarrage	Labels posés en CLI mais pas dans la config kubelet	Configurer --node-labels dans le kubelet ou l'outil de provisioning
kubectl cordon ne suffit pas	Les pods existants restent sur le nœud	cordon bloque uniquement le scheduling. Pour évacuer, utilisez drain.

Glissez pour voir

À retenir

• kubectl get nodes -o wide donne une vue rapide de tous les nœuds avec IP, OS et runtime.
• Les labels organisent votre flotte : environnement, zone, type de disque. Les pods les ciblent via nodeSelector ou l'affinité.
• Les labels de rôle (node-role.kubernetes.io/<role>=) améliorent la lisibilité du cluster, mais ne constituent pas un mécanisme de placement ou de sécurité à eux seuls.
• Les taints repoussent les pods. Trois effets : NoSchedule (bloque le nouveau scheduling), PreferNoSchedule (évite si possible), NoExecute (évince les pods existants).
• Pour remplacer un nœud : drain → delete node → provisionner la nouvelle machine → vérifier l'enregistrement.
• Kubernetes ajoute des taints automatiques liés à l'état du nœud. Leur effet sur le scheduling et l'éviction dépend du type de taint et des tolerations présentes.
• Automatisez les labels personnalisés via la configuration du kubelet ou votre outil de provisioning. Pour les labels critiques, appliquez une convention claire.

Contrôle de connaissances

Sept questions sur ce qui décide vraiment du placement : un label de rôle qui ne décide de rien, un taint dont l'effet change tout, et la capacité d'un nœud, qui n'est pas ce qu'il lui reste.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

7 questions

5 min.

80% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

Pour aller plus loin

• Fiabiliser les applications : Ce qu'il faut poser côté applicatif pour qu'un retrait de nœud passe inaperçu.
• Garantir la disponibilité applicative : Les PodDisruptionBudgets et l'anti-affinité qui protègent le service pendant vos opérations.
• SRE et exploitation Kubernetes : Le cadre SLO et budget d'erreur qui arbitre le bon moment pour intervenir sur un nœud.
• Routine d'exploitation : Le calendrier de vérifications qui garde le parc de nœuds en bon état.

×

📖 Voir la documentation →