Fonctionnement des Worker Nodes Kubernetes

Les Worker Nodes sont les machines qui exécutent vos applications conteneurisées dans un cluster Kubernetes. Ce guide vous explique comment fonctionnent leurs trois composants essentiels, kubelet, kube-proxy et le container runtime, et comment les administrer au quotidien.

Ce que vous apprendrez :

• Le rôle de chaque composant et leurs interactions
• Comment le kubelet communique avec l'API Server (modèle pull)
• L'interface CRI qui standardise l'exécution des conteneurs
• Les commandes pour surveiller, drainer et dépanner vos nœuds

Vue d'ensemble d'un Worker Node

Un Worker Node est une machine (physique ou virtuelle) où s'exécutent les Pods. Chaque nœud contient trois composants qui collaborent pour faire tourner vos applications :

Composant	Rôle	Communique avec
kubelet	Agent principal, gère les Pods	API Server (pull), CRI
kube-proxy	Gère les règles réseau pour les Services	API Server (watch Endpoints)
Container Runtime	Exécute les conteneurs	kubelet via CRI

Glissez pour voir

Point clé

Tous les composants du Worker Node communiquent avec l'API Server via le modèle pull : ils interrogent régulièrement l'API Server pour obtenir l'état désiré, plutôt que de recevoir des ordres poussés.

Le kubelet : l'agent principal

Le kubelet est le composant le plus important d'un Worker Node. C'est lui qui transforme les spécifications de Pods reçues de l'API Server en conteneurs réellement exécutés sur la machine.

Ce que fait le kubelet

Ces quatre missions se déroulent en boucle continue, pas une seule fois au démarrage. Le kubelet compare en permanence l'état désiré reçu de l'API Server avec l'état réel des conteneurs sur sa machine, et agit dès qu'un écart apparaît. C'est ce qui explique qu'un conteneur tué à la main avec docker kill ou crictl stop réapparaisse quelques secondes plus tard : le kubelet a constaté la disparition et l'a corrigée.

1. Watch l'API Server pour les Pods assignés à son Node
2. Crée/supprime les conteneurs via le runtime (CRI)
3. Surveille la santé des conteneurs (probes)
4. Reporte l'état du Node et des Pods à l'API Server

Communication avec l'API Server

Le kubelet utilise le modèle pull : il établit une connexion persistante avec l'API Server et watch les changements concernant son Node.

# Le kubelet watch les Pods pour son Node
GET /api/v1/pods?fieldSelector=spec.nodeName=worker-1&watch=true

Avantage du modèle pull

Si l'API Server est temporairement indisponible, le kubelet continue de faire tourner les Pods existants. Il ne peut simplement pas recevoir de nouvelles instructions. C'est une résilience majeure de l'architecture Kubernetes.

Le heartbeat : signaler l'état du Node

Le kubelet envoie régulièrement un heartbeat à l'API Server pour signaler que le Node est vivant. Ce heartbeat contient :

• L'état du Node (Ready, NotReady, Unknown)
• Les ressources disponibles (CPU, mémoire, disque)
• Les conditions (DiskPressure, MemoryPressure, PIDPressure)

# Fréquence par défaut : toutes les 10 secondes
--node-status-update-frequency=10s

Node NotReady

Si le kubelet cesse d'envoyer des heartbeats (crash, réseau coupé), le kube-controller-manager attend NodeMonitorGracePeriod, dont la valeur par défaut est de 50 secondes depuis Kubernetes 1.32, avant de marquer le Node comme NotReady. Il pose alors un taint node.kubernetes.io/not-ready ou node.kubernetes.io/unreachable. Les Pods portent une tolérance implicite de 300 secondes sur ces taints, d'où l'éviction observée environ 5 minutes plus tard. L'ancien indicateur --pod-eviction-timeout du controller manager n'existe plus : le mécanisme repose désormais entièrement sur les taints.

Les probes : surveiller la santé des conteneurs

Le kubelet exécute trois types de probes pour surveiller les conteneurs. La distinction à retenir tient dans la colonne Action si échec : livenessProbe tue et redémarre, readinessProbe se contente de retirer le Pod des destinations de trafic sans y toucher. Configurer une livenessProbe trop agressive sur une application lente à répondre sous charge produit donc exactement l'inverse de l'effet recherché, un redémarrage en pleine montée de trafic. La startupProbe existe précisément pour ce cas : elle suspend les deux autres tant que l'application n'a pas fini de démarrer.

Probe	Objectif	Action si échec
livenessProbe	Le conteneur est-il vivant ?	Redémarre le conteneur
readinessProbe	Le conteneur peut-il recevoir du trafic ?	Retire des Endpoints
startupProbe	Le conteneur a-t-il démarré ?	Bloque liveness/readiness

Glissez pour voir

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  periodSeconds: 10
  failureThreshold: 3  # Après 3 échecs → redémarrage

Static Pods : Pods locaux sans API Server

Le kubelet peut aussi créer des Static Pods à partir de manifests locaux, sans passer par l'API Server :

# Chemin par défaut des manifests statiques
/etc/kubernetes/manifests/

# Exemple : pod.yaml dans ce dossier sera créé automatiquement

Utilisation des Static Pods

Les composants du Control Plane (API Server, etcd, Scheduler, Controller Manager) sont souvent déployés comme Static Pods par kubeadm. Cela permet de bootstrapper un cluster même sans API Server fonctionnel.

Le CRI : Container Runtime Interface

Le CRI (Container Runtime Interface) est l'interface standardisée entre le kubelet et le runtime de conteneurs. Introduite dans Kubernetes 1.5, elle permet de changer de runtime sans modifier le kubelet.

Flux d'exécution d'un conteneur

Le point à retenir de cet enchaînement est que le kubelet ne crée jamais un conteneur lui-même. Il émet des appels gRPC normalisés et délègue tout le reste. Cette indirection en trois sauts, kubelet vers containerd, containerd vers shim, shim vers runc, explique pourquoi un redémarrage de containerd ne tue pas les conteneurs en cours : chaque conteneur est rattaché à son propre processus shim, indépendant du démon.

1. L'API Server notifie le kubelet qu'un Pod doit tourner sur ce Node

2. Le kubelet appelle le runtime via CRI (gRPC) pour :

   • Télécharger l'image (si absente)
   • Créer le conteneur
   • Démarrer le conteneur

3. Le runtime (containerd) délègue au shim qui appelle runc

4. runc crée le conteneur avec les namespaces et cgroups Linux

Runtimes compatibles CRI

Kubernetes ne livre aucun runtime : la colonne « Défaut depuis » désigne le choix retenu par les distributions et les installateurs, pas un composant intégré au projet. Ce qui a changé en 1.24, c'est la suppression de dockershim, le pont interne qui permettait au kubelet de piloter Docker sans passer par CRI. containerd s'est imposé comme choix par défaut de kubeadm, des offres managées et de la plupart des distributions ; CRI-O reste le runtime de référence sur OpenShift.

Runtime	Description	Défaut depuis
containerd	Léger, production-ready, projet CNCF	K8s 1.24+
CRI-O	Conçu spécifiquement pour Kubernetes	Alternative
Docker + cri-dockerd	Docker via un shim CRI (déprécié)	Avant K8s 1.24

Glissez pour voir

Docker déprécié depuis Kubernetes 1.24

Depuis Kubernetes 1.24, Docker n'est plus supporté nativement. Si vous utilisez Docker, vous devez installer cri-dockerd comme shim. Préférez containerd pour les nouveaux clusters.

imagePullPolicy : quand télécharger les images

Le kubelet respecte la politique imagePullPolicy pour décider quand télécharger les images :

Policy	Comportement
IfNotPresent	Pull si l'image n'existe pas localement (défaut)
Always	Pull à chaque création de conteneur (défaut pour :latest)
Never	Ne pull jamais, utilise uniquement le cache local

Glissez pour voir

containers:
- name: app
  image: nginx:1.25@sha256:a484819eb60211f5299034ac80f6a681b06f89e65866ce91f356ed7c72af059c
  imagePullPolicy: IfNotPresent  # Défaut si tag présent

Déboguer avec crictl

L'outil crictl permet d'interagir directement avec le runtime CRI, sans passer par l'API Server. C'est l'outil de dernier recours : quand kubectl ne répond plus ou qu'un conteneur meurt trop vite pour apparaître dans les logs du Pod, crictl reste disponible sur la machine. Il s'exécute en root directement sur le nœud et voit tous les conteneurs, y compris les conteneurs de pause et les Static Pods du Control Plane que kubectl peut ne pas montrer.

# Lister les conteneurs
crictl ps

# Lister les images
crictl images

# Logs d'un conteneur
crictl logs <container-id>

# Exécuter une commande dans un conteneur
crictl exec -it <container-id> sh

kube-proxy : le gestionnaire réseau

kube-proxy gère les règles réseau qui permettent aux Services de fonctionner. Il s'exécute sur chaque Node du cluster (en tant que DaemonSet).

Ce que fait kube-proxy

Une précision importante : kube-proxy ne voit pas passer le trafic. Malgré son nom, il ne se comporte pas comme un proxy applicatif dans le chemin des paquets ; il se contente de programmer le noyau Linux pour que celui-ci réécrive les adresses de destination. Le routage effectif est donc assuré par le noyau, ce qui explique qu'un kube-proxy arrêté ne coupe pas immédiatement les connexions existantes, les règles déjà installées continuant de s'appliquer.

1. Watch les Services et Endpoints via l'API Server
2. Configure les règles réseau pour router le trafic vers les bons Pods
3. Load balance le trafic entre les Pods d'un même Service

Modes de fonctionnement

Le choix du mode se pose surtout à grande échelle, quand le nombre de Services dépasse le millier. Attention toutefois à ne pas reprendre les recommandations d'il y a quelques années : le mode IPVS est déclaré déprécié depuis Kubernetes 1.35, et le remplaçant recommandé pour les gros clusters est désormais le mode nftables, passé en disponibilité générale en Kubernetes 1.33. Le mode iptables reste le défaut sur Linux, par souci de compatibilité, et convient à la grande majorité des clusters.

iptables (défaut)

Mode par défaut depuis longtemps. Configure les règles dans la table NAT du noyau Linux.

Avantages :

• Simple et mature
• Compatible avec tous les systèmes Linux
• Fonctionne bien avec les CNI (Calico, Flannel)

Inconvénients :

• Performance linéaire O(n) avec le nombre de Services
• Peut devenir lent avec des milliers de Services

# Voir les règles iptables créées par kube-proxy
iptables -t nat -L KUBE-SERVICES -n

IPVS (déprécié)

Mode optimisé utilisant le module IP Virtual Server du noyau Linux. Il a longtemps été la réponse aux limites d'iptables sur les grands clusters, mais il est déprécié depuis Kubernetes 1.35 : ne bâtissez plus de nouveau cluster dessus.

Avantages :

• Performance constante O(1) avec tables de hachage
• Supporte plus d'algorithmes de répartition de charge

Inconvénients :

• Déprécié en amont, sans évolution à attendre
• Nécessite les modules IPVS installés
• Plus complexe à déboguer

# Voir les règles IPVS
ipvsadm -Ln

nftables (recommandé à l'échelle)

Mode passé en disponibilité générale en Kubernetes 1.33. Il programme le sous-système nftables du noyau, successeur d'iptables, et remplace la longue liste de règles par une verdict map unique.

Avantages :

• Latence en O(1) quel que soit le nombre de Services
• Successeur officiel d'iptables côté noyau Linux
• Trajectoire de maintenance claire en amont

Inconvénients :

• Pas activé par défaut, il faut le déclarer explicitement
• Demande un noyau raisonnablement récent
• Certains greffons CNI supposent encore des règles iptables

# Voir les règles nftables posées par kube-proxy
nft list table kube-proxy

kube-proxy en DaemonSet

kube-proxy s'exécute comme un DaemonSet : un Pod sur chaque Node du cluster. Cela garantit que tous les Nodes peuvent router le trafic vers les Services.

# Voir le DaemonSet kube-proxy
kubectl get ds -n kube-system kube-proxy

# Voir les Pods kube-proxy sur tous les nœuds
kubectl get pods -n kube-system -l k8s-app=kube-proxy -o wide

Alternatives à kube-proxy

Certains CNI avancés comme Cilium ou Calico eBPF peuvent remplacer kube-proxy en gérant le routage des Services directement avec eBPF. Cela offre de meilleures performances.

Administration des Worker Nodes

Les opérations qui suivent supposent un cluster installé avec kubeadm. Sur une offre managée (EKS, GKE, AKS) ou sur k3s, l'ajout et la suppression de nœuds passent par les outils du fournisseur ; en revanche, tout ce qui concerne la surveillance, le cordon et le drain reste identique, puisque ce sont des opérations de l'API Kubernetes.

Ajouter un Node au cluster

Le jeton généré à l'étape 1 est un secret d'amorçage valable 24 heures par défaut. La commande affiche également une empreinte du certificat de l'autorité du cluster : ce n'est pas un détail cosmétique, c'est ce qui permet au nouveau nœud de vérifier qu'il rejoint bien le bon Control Plane et non un serveur usurpé. Ne diffusez jamais la ligne complète sur un canal partagé, elle donne à qui la détient le droit de faire entrer une machine dans votre cluster.

1. Sur le Control Plane, générez un token d'enregistrement :

   kubeadm token create --print-join-command

2. Sur le nouveau Node, exécutez la commande affichée :

   kubeadm join <control-plane>:6443 --token <token> \
     --discovery-token-ca-cert-hash sha256:<hash>

3. Vérifiez que le Node est Ready :

   kubectl get nodes

Surveiller un Node

Ces quatre commandes vont du plus synthétique au plus détaillé. kubectl get nodes répond à la seule question binaire, le nœud est-il Ready. Quand il ne l'est pas, describe donne la réponse dans le bloc Conditions : DiskPressure, MemoryPressure et PIDPressure y indiquent une saturation de ressource, tandis qu'un Ready à Unknown pointe vers un problème de communication avec l'API Server plutôt que vers la machine elle-même. La dernière commande sur les événements est celle qu'on oublie, alors qu'elle date précisément le moment du basculement.

# État général des nœuds
kubectl get nodes

# Détails d'un nœud (conditions, ressources, Pods)
kubectl describe node <nom-du-node>

# Pods sur un nœud spécifique
kubectl get pods --all-namespaces --field-selector spec.nodeName=<nom-du-node>

# Événements liés au nœud
kubectl get events --field-selector involvedObject.kind=Node,involvedObject.name=<nom-du-node>

Surveiller le kubelet

Le kubelet est un service systemd ordinaire, pas un conteneur : il ne peut donc pas se diagnostiquer avec kubectl. Quand un nœud passe NotReady, le journal journalctl -u kubelet est la source d'information de référence, et il faut s'y connecter en SSH sur la machine concernée. Le fichier /var/lib/kubelet/config.yaml mérite un regard au passage : c'est lui, et non la ligne de commande, qui porte l'essentiel de la configuration effective sur les clusters récents.

# État du service kubelet
systemctl status kubelet

# Logs en temps réel
journalctl -u kubelet -f

# Configuration du kubelet
cat /var/lib/kubelet/config.yaml

Surveiller le runtime

Une remarque sur crictl : il exige de connaître le socket du runtime, généralement /run/containerd/containerd.sock. S'il reste muet ou renvoie une erreur de connexion, l'outil interroge probablement le mauvais point d'entrée, ce qui se règle avec la variable CONTAINER_RUNTIME_ENDPOINT ou le fichier /etc/crictl.yaml. Un systemctl status containerd en échec alors que le kubelet tourne encore explique presque toujours un nœud qui bascule NotReady sans raison apparente côté Kubernetes.

# Avec crictl (containerd, CRI-O)
crictl ps        # Conteneurs en cours
crictl images    # Images disponibles

# État du service containerd
systemctl status containerd

Maintenance d'un Node

Cette séquence en quatre temps est la seule façon propre d'intervenir sur un nœud en production. cordon et drain sont volontairement séparés : le premier arrête l'arrivée de nouveaux Pods et n'a aucun effet visible pour les utilisateurs, le second déplace la charge et peut provoquer des coupures. Si des PodDisruptionBudget sont définis, drain respecte les seuils et attend, il peut donc rester bloqué plusieurs minutes ; c'est le comportement attendu, pas un blocage à contourner avec --force.

1. Cordon : empêcher la planification de nouveaux Pods

   kubectl cordon <nom-du-node>

2. Drain : évacuer les Pods existants vers d'autres Nodes

   kubectl drain <nom-du-node> --ignore-daemonsets --delete-emptydir-data

3. Effectuer la maintenance (mise à jour, reboot, etc.)

4. Uncordon : réactiver la planification

   kubectl uncordon <nom-du-node>

Attention avec drain

kubectl drain supprime les Pods du Node. Les Pods gérés par des Deployments ou ReplicaSets seront recréés sur d'autres Nodes. Les Pods "orphelins" (créés manuellement) seront perdus sauf si vous utilisez --force.

Supprimer un Node du cluster

L'ordre de ces trois commandes n'est pas interchangeable. Supprimer l'objet Node avant d'avoir drainé laisse des Pods orphelins encore en exécution sur la machine, invisibles pour le Control Plane, qui continueront de consommer des ressources et d'écrire sur le réseau. L'étape kubeadm reset s'exécute sur le nœud concerné, pas sur le Control Plane, et nettoie la configuration locale ; elle ne supprime ni les règles de filtrage ni le répertoire /etc/cni/net.d, qu'il faut traiter à part avant de réutiliser la machine.

# 1. Évacuer les Pods
kubectl drain <nom-du-node> --ignore-daemonsets --delete-emptydir-data

# 2. Supprimer le Node de l'API
kubectl delete node <nom-du-node>

# 3. Sur le Node, réinitialiser kubeadm (optionnel)
kubeadm reset

Dépannage des Worker Nodes

Ces cinq symptômes se répartissent en deux niveaux qu'il ne faut pas confondre. Les deux premiers concernent le nœud et se diagnostiquent en SSH sur la machine, avec journalctl et df. Les trois suivants concernent les Pods et se traitent entièrement avec kubectl, sans jamais toucher au nœud. Commencez toujours par identifier le niveau : redémarrer un kubelet parce que des Pods sont en CrashLoopBackOff déplace le problème sans le résoudre.

Symptôme	Cause probable	Solution
Node NotReady	kubelet arrêté ou crash	systemctl restart kubelet
Node NotReady + DiskPressure	Disque plein	Nettoyer /var/lib/containerd/
Pods en Pending	Pas de Node avec ressources suffisantes	Ajouter un Node ou libérer des ressources
Pods en ImagePullBackOff	Image introuvable ou registry inaccessible	Vérifier le nom de l'image et les credentials
Pods en CrashLoopBackOff	Conteneur qui crashe au démarrage	kubectl logs <pod> pour voir l'erreur

Glissez pour voir

# Diagnostic rapide d'un Node NotReady
kubectl describe node <nom-du-node> | grep -A5 Conditions

# Vérifier les logs kubelet
journalctl -u kubelet --since "10 minutes ago" | grep -i error

Contrôle de connaissances

Les questions ci-dessous portent uniquement sur ce qui vient d'être expliqué : rôle de chaque composant, modèle pull, délais de bascule d'un Node et séquence de maintenance. Si une réponse vous échappe, la section correspondante plus haut contient l'explication.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

10 questions

5 min.

70% 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

À retenir

• Le kubelet est l'agent principal qui gère les Pods sur chaque Node
• Le kubelet communique avec l'API Server via le modèle pull (watch)
• Le CRI standardise la communication kubelet ↔ runtime de conteneurs
• containerd s'est imposé comme runtime par défaut des distributions après le retrait de dockershim en Kubernetes 1.24
• Le kube-proxy programme le noyau pour router les Services : iptables par défaut, nftables recommandé à grande échelle, IPVS déprécié depuis 1.35
• kube-proxy s'exécute en DaemonSet sur tous les Nodes
• Un Node NotReady signifie que le kubelet n'envoie plus de heartbeat depuis plus de 50 secondes, l'éviction des Pods suit environ 5 minutes plus tard
• Utilisez cordon → drain → maintenance → uncordon pour la maintenance

Pour aller plus loin

• CNI, CSI et CRI : Les trois interfaces par lesquelles le kubelet délègue réseau, stockage et exécution.
• Haute disponibilité : Ce qui change côté nœuds quand le control plane passe à trois instances.
• Installer avec kubeadm : La jointure d'un worker au cluster, commande par commande.
• Gérer les nœuds : Les labels, taints et remplacements de nœud au quotidien.

×

📖 Voir la documentation →