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

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é), l’API Server attend un délai de 40 secondes (node-monitor-grace-period) avant de marquer le Node comme NotReady. Après 5 minutes supplémentaires (pod-eviction-timeout), les Pods sont évacués vers d’autres Nodes.

Les probes : surveiller la santé des conteneurs

Le kubelet exécute trois types de probes pour surveiller les conteneurs :

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

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

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
  imagePullPolicy: IfNotPresent  # Défaut si tag présent

Déboguer avec crictl

L’outil crictl permet d’interagir directement avec le runtime CRI :

# 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

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

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 (performant)

Mode optimisé utilisant le module IP Virtual Server du noyau Linux.

Avantages :

• Performance constante O(1) avec hash tables
• Supporte plus d’algorithmes de load balancing
• Idéal pour les grands clusters (> 1000 Services)

Inconvénients :

• Nécessite les modules IPVS installés
• Légèrement plus complexe à déboguer

# Voir les règles IPVS
ipvsadm -Ln

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

Ajouter un Node au 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

# É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

# É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

# 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

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

# 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

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

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 est le runtime par défaut depuis Kubernetes 1.24
• Le kube-proxy gère le routage réseau des Services (iptables ou IPVS)
• kube-proxy s’exécute en DaemonSet sur tous les Nodes
• Un Node NotReady signifie que le kubelet n’envoie plus de heartbeat
• Utilisez cordon → drain → maintenance → uncordon pour la maintenance

Prochaines étapes

Architecture Kubernetes Vue globale du cluster et interactions entre composants

Le Control Plane Comprendre l'API Server, etcd, Scheduler et Controller Manager

Les Pods L'unité de base que le kubelet gère sur chaque Node

Les Services Comment kube-proxy route le trafic vers vos Pods

×

📖 Voir la documentation →