Le kubelet est un agent qui s’exécute sur chaque nœud (worker ou master) d’un cluster Kubernetes. Il n’est pas lancé dans un conteneur, mais fonctionne en tant que service système (géré souvent par systemd).
Sa mission principale : garantir que les pods (et donc les conteneurs du pod) qui doivent tourner sur le nœud local sont bien présents, sains, et selon la configuration attendue (le “podSpec”).
Fonctionnement global
- Enregistrement du nœud : le kubelet enregistre le nœud auprès de l’API server pour qu’il soit reconnu dans le cluster.kubernetes.io+1
- Lecture du podSpec : récupère la description des pods à lancer, principalement depuis l’API server, mais aussi depuis des fichiers ou endpoints HTTP (utile pour les “static pods”).
- Mise en conformité : s’assure que les containers sont créés/modifiés/supprimés pour correspondre au podSpec.kubernetes.io
- Surveillance/contrôle : exécute et surveille les probes (liveness, readiness, startup), monte les volumes, supervise l’état et la santé du nœud et des pods, expose un endpoint pour logs/exec.armosec.io+1
- Reporting : remonte régulièrement l’état du nœud et des pods auprès de l’API server.
Tableau synthétique
| Fonction | Explication |
|---|---|
| Démarrage du kubelet | Agent système (daemon, via systemd) qui tourne sur chaque nœud, non dans un conteneur. |
| Enregistrement du nœud | Le nœud est signalé à l’API server pour être intégré au cluster. |
| Lecture du podSpec | Récupère les définitions de pods depuis l’API server, un fichier ou un endpoint HTTP (pour les static pods)kubernetes.io+2. |
| Gestion des conteneurs | Crée, modifie ou supprime les conteneurs pour chaque pod selon son podSpec. |
| Probes (liveness/readiness/startup) | Surveille l’état des conteneurs pour détecter pannes ou problèmes d’application. |
| Montage de volumes | Monte les volumes nécessaires aux pods (via CSI). |
| Récupération de l’état | Utilise cAdvisor et CRI pour collecter les infos de santé/status, reportées ensuite à l’API serverarmosec.io+1. |
| Interface Container Runtime (CRI) | Passe par CRI (gRPC) pour lancer les containers via le runtime (containerd, CRI-O…). |
| Interface stockage (CSI) | Utilise CSI pour configurer les block volumes ou disques persistants. |
| Interface réseau (CNI) | Utilise un plugin CNI pour attribuer une IP au pod et configurer le routage réseau du pod. |
| Static Pods | Peut gérer des pods locaux indépendamment de l’API server (utile pour démarrer le control plane). |
| Exposition de logs/exec | Fournit un accès HTTP/stream pour logs et exécution de commandes dans les containers. |
| linkedin.com+6 |
Éclaircissements
- Kubelet = chef d’orchestre local : sur chaque nœud, c’est le composant qui fait le lien entre la description théorique d’un pod et sa réalité concrète sur le serveur. Rien ne s’exécute sur un nœud sans l’action du kubelet.
- CRI, CSI, CNI = adaptateurs universels : le kubelet n’exécute pas lui-même les conteneurs, ne monte pas les disques, ni ne configure le réseau, mais emploie différentes interfaces standards pour déléguer ces tâches à des plugins spécialisés et interchangeables.
- Static Pods = pods “hors contrôle” : contrairement aux pods ordinaires créés via l’API server, les static pods sont déclenchés par la simple présence d’un manifest YAML sur le disque du nœud. Parfait pour démarrer l’infrastructure essentielle du cluster même sans API server entièrement opérationnel.linkedin.com+1
- Cycle de vie du pod : le kubelet lance, surveille (probes), redémarre si besoin, et arrête les conteneurs. Il s’assure que leur état corresponde à la déclaration YAML—c’est le garant de l’exécution locale.
Exemples concrets pour mieux comprendre
- Déploiement d’un pod classique : vous appliquez un manifeste sur l’API server. Le kubelet de chaque nœud voit s’il doit héberger ce pod et, si oui, lance le/les containers décrits selon la podSpec.
- Static pods au boot du cluster : pour initialiser un cluster (ex : kubeadm), les composants principaux (API server, scheduler…) sont eux-mêmes des static pods générés via des manifests placés dans
/etc/kubernetes/manifests.kubernetes.io+1 - Réseau et stockage : le kubelet n’a pas à gérer le détail technique – il fait appel au plugin réseau (CNI) et stockage (CSI) configurés pour allouer l’IP et monter un disque à chaque nouveau pod.