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

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

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)

Ce battement se produit toutes les dix secondes, et vous pouvez le constater vous-même en relevant deux fois de suite l'horodatage du bail que le kubelet renouvelle :

kubectl get lease <node> -n kube-node-lease -o jsonpath='{.spec.renewTime}'

Retenez surtout ce qui se passe quand ces battements s'arrêtent, parce que le délai surprend souvent. Mesuré sur le cluster de la formation en arrêtant un nœud : il passe NotReady au bout de 50 secondes, et ses Pods sont replacés ailleurs environ cinq minutes plus tard. Cette lenteur est voulue, un réseau brièvement instable ne devant pas déclencher le déplacement de toutes les applications d'une machine.

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 :

# Le répertoire surveillé se lit dans la configuration du kubelet
grep staticPodPath /var/lib/kubelet/config.yaml

Sortie sur un nœud kubeadm

staticPodPath: /etc/kubernetes/manifests

/etc/kubernetes/manifests/ n'est pas un défaut du kubelet mais la valeur que kubeadm écrit dans staticPodPath. Sans ce champ, le kubelet ne lit aucun manifeste local, et déposer un fichier n'a aucun effet. La nuance compte à l'examen comme en incident : sur un nœud dont vous n'avez pas fait l'installation, c'est la configuration du kubelet qu'il faut lire, pas un chemin supposé.

Les composants du control plane, API Server, etcd, Scheduler et Controller Manager, sont déployés ainsi par kubeadm. C'est exactement ce qui permet de démarrer un cluster alors que l'API Server n'existe pas encore pour les créer.

Cette autonomie a une contrepartie : un Static Pod ne peut pas référencer de ressource de l'API, ni Secret ni ConfigMap. La logique est cohérente, le kubelet lit ces manifestes sans interroger l'API Server, il ne peut donc pas en résoudre les références.

Le piège tient à l'endroit où l'erreur apparaît. Le fichier est accepté à l'écriture, le Pod n'apparaît jamais dans kubectl get pods, et rien ne signale pourquoi. Seuls les journaux du kubelet le disent :

journalctl -u kubelet --no-pager | grep static

Sortie

Could not process manifest file
err="static pods may not reference configmaps"
path="/etc/kubernetes/manifests/test-static.yaml"

Cette restriction vaut sur toutes les versions maintenues : ne comptez pas la contourner.

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 une demande normalisée, et délègue tout le reste au runtime. C'est cette indirection qui permet de changer de runtime sans toucher au kubelet.

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) 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 Engine + cri-dockerd	Docker via un adaptateur CRI	Toujours documenté

Glissez pour voir

C'est dockershim qui a été retiré, pas Docker

La formule « Docker n'est plus supporté » circule beaucoup et elle est inexacte. Ce que Kubernetes a retiré en 1.24, c'est dockershim, l'intégration directe du kubelet avec Docker Engine. Docker Engine reste un runtime documenté, à condition de passer par l'adaptateur cri-dockerd.

Pour un nouveau cluster, préférez tout de même containerd : c'est ce que Docker Engine utilise lui-même en dessous, et cela supprime une couche.

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

Quand kubectl ne suffit plus

Il existe un cas où kubectl ne peut rien pour vous : quand le kubelet lui-même ne répond plus. Le runtime, lui, continue de tourner, et un outil dédié permet de l'interroger directement sur le nœud. C'est un geste d'administration, décrit avec le runtime dans CNI, CSI et CRI.

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

Trois modes, et celui par défaut suffit

kube-proxy sait programmer les règles de trois façons différentes. Le choix ne se pose qu'à grande échelle, au-delà du millier de Services, et le mode iptables reste le défaut sur Linux : c'est celui de votre cluster, et il convient à la grande majorité des installations.

Deux repères à retenir si vous croisez des recommandations anciennes : le mode IPVS est déprécié depuis Kubernetes 1.35, et le remplaçant pour les gros clusters est désormais nftables, disponible en version générale depuis la 1.33. Le détail de ces modes et leur réglage appartiennent au réseau des Pods.

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.

Ce que vous ferez de ces nœuds, plus tard

Un nœud se pilote : on en ajoute quand la charge monte, on en sort un du service pour le mettre à jour, on en retire un définitivement. Ces gestes supposent la répartition des rôles vue ici, et relèvent de l'exploitation plutôt que de l'architecture.

Geste	Ce qu'il fait	Où il est traité
kubectl cordon	le nœud n'accepte plus de nouveaux Pods	Gérer les nœuds
kubectl drain	les Pods existants sont évacués vers les autres nœuds	Gérer les nœuds
kubeadm join	un nouveau nœud rejoint le cluster	Installer avec kubeadm

Glissez pour voir

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 portent uniquement sur ce qui vient d'être expliqué : rôle de chaque composant, modèle en tirage, délais de bascule d'un nœud 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 →