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

Lister et inspecter les nœuds

Lister tous les nœuds

kubectl get nodes

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

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

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

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

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.34.3
ks-worker1   Ready    worker          42h   v1.34.3
ks-worker2   Ready    <none>          42h   v1.34.3

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 worker,monitoring dans la colonne ROLES.

Supprimer un rôle

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

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.

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

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

Taints automatiques lors de problèmes

Kubernetes ajoute automatiquement 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 le scheduling et l’éviction dépend du type de taint et des tolerations présentes sur les Pods.

Remplacer un nœud défaillant

Quand un nœud doit être remplacé (panne matérielle, fin de vie, migration), suivez ce workflow en 4 étapes. Il reprend le workflow de maintenance détaillé dans le guide Préparer une maintenance.

Drainer le nœud : évacuez tous les pods vers d’autres nœuds.
Fenêtre de terminal
```
kubectl drain ks-worker1 --ignore-daemonsets --delete-emptydir-data
```
Le drain commence par un cordon automatique, puis évince les pods en respectant les PodDisruptionBudgets.
Vérifier que les pods sont repositionnés :
Fenêtre de terminal
```
kubectl get pods -A -o wide | grep ks-worker1
```
Seuls les pods de DaemonSets doivent rester sur le nœud.
Supprimer l’objet Node :
Fenêtre de terminal
```
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 maîtriser les implications : Kubernetes suppose qu’un nœud de même nom représente le même objet logique.
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 :
Fenêtre de terminal
```
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.

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 que vous pouvez voir sur un nœud (comme kubeadm.alpha.kubernetes.io/cri-socket ou node.alpha.kubernetes.io/ttl) sont d’ailleurs dépréciées et ne doivent pas être utilisées comme référence.

Dépannage

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

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

Prochaines étapes

Préparer une maintenance de cluster Workflow cordon → drain → uncordon avec PodDisruptionBudgets

Mettre à jour un cluster Kubernetes Stratégie d'upgrade, ordre des composants, rollback

Observer la santé du cluster 5 commandes pour vérifier nœuds, pods et ressources

Affinité, taints et tolerations Contrôle avancé du placement des pods

Scheduling avancé NodeSelector, affinité, topologie et priorité

Hub Opérer Kubernetes Tous les guides d'exploitation au quotidien