Exploitation de Kubelet en production : une liste de contrôle pratique avec des exemples concrets

Introduction

Kubelet est l'agent au niveau du nœud qui transforme les spécifications de conteneurs en charges de travail en cours d'exécution sur chaque nœud Kubernetes. Lorsque kubelet échoue, les pods s'arrêtent, l'état du nœud se dégrade et la capacité du cluster s'érode silencieusement. Cet article fournit une liste de contrôle opérationnelle axée sur la production pour kubelet, construite autour de commandes concrètes, de sorties attendues et d'étapes de récupération. Il s'adresse aux développeurs, consultants DevOps et équipes techniques de startups qui doivent passer d'un symptôme observé à une correction vérifiée sans conjectures.

La liste de contrôle est structurée autour de la sécurité opérationnelle : observer avant de changer, limiter le rayon d'impact, utiliser des valeurs fictives au lieu de secrets, vérifier le résultat et documenter comment récupérer si l'état attendu n'est pas atteint. Chaque section comprend une commande d'observation en lecture seule, un changement minimal viable, un signal de vérification et un chemin de récupération. Nous couvrirons l'inventaire de version et d'environnement, les chemins de configuration sûrs, les diagnostics, les modes de défaillance et une liste de contrôle opérationnelle condensée que vous pouvez adapter à vos propres runbooks.

À la fin, vous disposerez d'un processus reproductible pour garder kubelet en bonne santé en production, que vous gériez cinq nœuds ou cinq cents.

Inventaire de version et d'environnement

Avant de toucher à kubelet, vous devez savoir ce que vous exécutez et où. Commencez par un inventaire en lecture seule de la version de kubelet et de l'environnement d'exploitation du nœud. Cela évite les drapeaux incompatibles, les configurations non prises en charge et les mises à niveau accidentelles.

Observation en lecture seule

Sur n'importe quel nœud, exécutez :

kubelet --version

Sortie attendue sur une version récente de Kubernetes :

Kubernetes v1.29.2

Documentez cette version pour chaque nœud. Si vous utilisez un service Kubernetes géré comme EKS, GKE ou AKS, la version de kubelet peut être gérée pour vous. Vous pouvez toujours l'interroger via le champ status.nodeInfo.kubeletVersion du nœud.

Vérification de version à l'échelle du cluster

Utilisez kubectl pour lister tous les nœuds et leurs versions de kubelet :

kubectl get nodes -o custom-columns='NAME:.metadata.name,KUBELET_VERSION:.status.nodeInfo.kubeletVersion'

Exemple de sortie :

NAME           KUBELET_VERSION
node-1         v1.29.2
node-2         v1.28.5
node-3         v1.29.2

Si les versions diffèrent de manière significative (plus d'un écart de version mineure par rapport au plan de contrôle), planifiez une mise à niveau progressive avant d'apporter d'autres modifications à kubelet. Un écart de version au-delà de la fenêtre prise en charge provoque des problèmes de compatibilité d'API et est une cause racine courante des plantages de kubelet.

Topologie de déploiement

Identifiez comment kubelet est déployé sur le nœud : en tant que service systemd, un binaire statique géré par kubeadm, ou un conteneur dans une configuration kubelet-in-docker. Le nom du service est généralement kubelet. Vérifiez son état :

systemctl status kubelet --no-pager

Sortie attendue lorsqu'il est en bonne santé :

● kubelet.service - kubelet: The Kubernetes Node Agent
     Loaded: loaded (/etc/systemd/system/kubelet.service; enabled; vendor preset: enabled)
     Active: active (running) since Tue 2024-05-14 10:22:31 UTC; 2 days ago
       Docs: https://kubernetes.io/docs/
   Main PID: 1337 (kubelet)
      Tasks: 15 (limit: 1152)
     Memory: 120.5M
     CGroup: /system.slice/kubelet.service

Notez la ligne Active: active (running) et la durée de fonctionnement. Si le service n'est pas en cours d'exécution ou est en boucle de crash, passez à la section Modes de défaillance et récupération.

Emplacement du fichier de configuration

Kubelet lit la configuration depuis un fichier, généralement /var/lib/kubelet/config.yaml, et les drapeaux de ligne de commande depuis /var/lib/kubelet/kubeadm-flags.env (sur les clusters kubeadm). Vérifiez que le fichier existe et examinez son contenu :

ls -l /var/lib/kubelet/config.yaml
cat /var/lib/kubelet/config.yaml

Un config.yaml de production minimal pourrait ressembler à ceci :

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
cgroupDriver: systemd
clusterDNS:
- 10.96.0.10
clusterDomain: cluster.local
maxPods: 110

Ne modifiez jamais ce fichier directement sans sauvegarde. Utilisez la procédure décrite dans la section Chemin de configuration sûr.

Prérequis

Avant tout changement, confirmez que vous disposez de :

• Accès shell au nœud avec les privilèges sudo ou root.
• Une sauvegarde récente de /var/lib/kubelet/ (incluant config.yaml, les certificats kubelet éventuels et le fichier kubeadm-flags.env).
• La version exacte de kubelet que vous exécutez, afin de consulter la documentation correspondante.
• Une fenêtre de maintenance ou une stratégie de cordon/drain, car le redémarrage de kubelet peut brièvement perturber les battements de cœur du nœud.

Rayon d'impact et récupération

Toutes les commandes d'inventaire sont en lecture seule et ont un rayon d'impact négligeable. Si vous modifiez accidentellement un fichier, restaurez à partir de la sauvegarde et redémarrez kubelet avec :

sudo systemctl restart kubelet

Puis vérifiez avec :

systemctl status kubelet --no-pager

Chemin de configuration sûr

Les changements de configuration de kubelet sont une cause majeure d'instabilité des nœuds. Utilisez un processus contrôlé : observer, modifier un élément ciblé, valider et documenter la récupération.

Observer la configuration effective actuelle

Kubelet utilise activement une combinaison de drapeaux et du fichier de configuration. Vous pouvez extraire la configuration effective via l'endpoint /configz de kubelet (nécessite l'accès au serveur d'API et --enable-debugging-handlers=true). Depuis une machine avec kubectl et un accès réseau au port kubelet du nœud (10250 par défaut), exécutez :

kubectl proxy --port=8001 &
curl -s http://localhost:8001/api/v1/nodes/<NODE_NAME>/proxy/configz | jq .

Remplacez <NODE_NAME> par le nom réel de votre nœud, par exemple node-1. Cela renvoie la configuration effective complète en JSON. Documentez les valeurs actuelles avant tout changement, en particulier cgroupDriver, maxPods, evictionHard et systemReserved.

Changement minimal viable : exemple - ajuster les seuils d'éviction

Supposons que vous souhaitiez définir un seuil d'éviction personnalisé pour prévenir la pression sur le nœud. Modifiez /var/lib/kubelet/config.yaml (après sauvegarde) pour inclure :

evictionHard:
  memory.available: "500Mi"
  nodefs.available: "10%"
  nodefs.inodesFree: "5%"

Puis redémarrez kubelet :

sudo systemctl restart kubelet

Vérification

Vérifiez que kubelet a démarré sans erreur et que la nouvelle configuration est chargée :

journalctl -u kubelet -n 50 --no-pager | grep -i eviction

Attendez-vous à voir les paramètres d'éviction dans le journal de démarrage, ou utilisez à nouveau l'endpoint /configz pour confirmer les valeurs.

Retour en arrière

Si kubelet ne démarre pas ou si le nœud devient NotReady, annulez le changement :

sudo cp /var/lib/kubelet/config.yaml.bak /var/lib/kubelet/config.yaml
sudo systemctl restart kubelet

Conservez toujours une sauvegarde horodatée :

sudo cp /var/lib/kubelet/config.yaml /var/lib/kubelet/config.yaml.bak.$(date +%Y%m%d)

Discipline des valeurs fictives

Dans tout exemple de configuration, remplacez les valeurs réelles par des valeurs fictives explicites dans la documentation. Par exemple, n'écrivez pas une adresse IP réelle pour clusterDNS ; utilisez 10.96.0.10 uniquement comme exemple et dites aux lecteurs de substituer leur propre IP DNS du CIDR de service. Il en va de même pour les certificats, les jetons et les identifiants du fournisseur cloud.

Vérification et diagnostics

Un diagnostic efficace repose sur l'examen des journaux, la vérification de l'état du nœud et l'observation au niveau des pods. Cette section vous donne des commandes concrètes et des signaux attendus pour isoler les problèmes de kubelet.

Vérifier l'état du nœud

Exécutez :

kubectl get nodes

Si un nœud affiche NotReady, inspectez ses conditions :

kubectl describe node <NODE_NAME>

Recherchez les événements KubeletNotReady et le message de la condition Ready. Un message courant est PLEG is not healthy, indiquant un problème avec le Pod Lifecycle Event Generator, souvent dû à des problèmes de runtime de conteneur.

Inspecter les journaux de kubelet

Si le nœud est NotReady ou si les pods échouent, lisez les journaux de kubelet avec :

journalctl -u kubelet --since "10 minutes ago" --no-pager

Filtrez les erreurs :

journalctl -u kubelet --since "1 hour ago" --no-pager | grep -i 'error\|failed'

Sortie attendue en bonne santé : peu ou pas d'erreurs. Recherchez des schémas récurrents comme :

• Failed to start ContainerManager - peut indiquer une mauvaise configuration du pilote cgroup.
• PLEG is not healthy - souvent causé par des problèmes de Docker ou containerd.
• Failed to get system container stats - vérifiez cAdvisor et les limites de ressources.

Vérifier la santé du runtime de conteneur

Kubelet dépend du runtime de conteneur (containerd, CRI-O ou Docker). Vérifiez l'état du runtime. Pour containerd :

sudo crictl info

La sortie attendue inclut la version du runtime et son état. Si le runtime ne répond pas, kubelet perd la capacité de gérer les pods.

Diagnostics au niveau des pods

Si des pods sont bloqués en ContainerCreating ou CrashLoopBackOff, décrivez le pod :

kubectl describe pod <POD_NAME> -n <NAMESPACE>

Regardez la section Events. Exemple d'événement :

Warning  FailedCreatePodSandBox  2m    kubelet  Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox

Cela indique une défaillance du plugin CNI, pas de kubelet lui-même, mais c'est souvent signalé comme un problème de kubelet.

Utiliser crictl pour l'introspection du runtime

Listez les conteneurs en cours d'exécution via le runtime :

sudo crictl ps

Listez les pods connus du runtime :

sudo crictl pods

Comparez cette liste avec kubectl get pods --all-namespaces pour repérer les conteneurs orphelins ou les sandbox manquants.

Modes de défaillance et récupération

Les défaillances de kubelet se répartissent en quelques catégories courantes. Chacune nécessite un chemin de diagnostic et une stratégie de récupération différents.

Mode de défaillance 1 : service kubelet non exécuté

Symptôme : le nœud affiche NotReady, systemctl status kubelet indique inactive (dead) ou failed.

Diagnostic :

systemctl status kubelet --no-pager
journalctl -u kubelet -n 100 --no-pager

Causes courantes et corrections :

• Erreur de syntaxe de configuration : validez /var/lib/kubelet/config.yaml avec un linter YAML.
• Binaire manquant : vérifiez que /usr/bin/kubelet existe et a les permissions d'exécution.
• Unité systemd mal configurée : vérifiez que /etc/systemd/system/kubelet.service correspond à votre méthode d'installation.

Récupération : corrigez le problème sous-jacent, puis démarrez kubelet :

sudo systemctl start kubelet

Mode de défaillance 2 : kubelet en cours d'exécution mais nœud NotReady

Symptôme : le processus kubelet est actif, mais kubectl get nodes affiche NotReady.

Diagnostic :

kubectl describe node <NODE_NAME>
journalctl -u kubelet --since "10 minutes ago" --no-pager

Causes courantes :

• Plugin réseau non prêt : assurez-vous que les pods CNI sont en cours d'exécution et que les interfaces réseau ont des adresses IP.
• Pression disque : vérifiez df -h sur le nœud ; si le système de fichiers racine est utilisé à plus de 85 %, kubelet peut évincer des pods et marquer le nœud NotReady. Corrigez en nettoyant le disque ou en étendant le stockage.
• Certificat expiré : le certificat client de kubelet peut expirer. Vérifiez la validité du certificat :

sudo openssl x509 -in /var/lib/kubelet/pki/kubelet-client-current.pem -noout -dates

S'il est expiré, kubelet ne peut pas s'authentifier auprès du serveur d'API. Renouvelez les certificats (souvent via kubeadm certs renew ou la rotation automatique).

Mode de défaillance 3 : boucle de crash de kubelet

Symptôme : kubelet redémarre à plusieurs reprises ; systemctl status kubelet affiche activating (auto-restart).

Diagnostic :

journalctl -u kubelet -n 200 --no-pager | grep -i 'panic\|fatal'

Causes courantes :

• Version de runtime de conteneur incompatible : assurez-vous que la version CRI du runtime correspond au support de la version Kubernetes.
• Fichiers d'état corrompus : les fichiers dans /var/lib/kubelet/ peuvent être corrompus. Déplacez-les (dans un répertoire de sauvegarde) et redémarrez kubelet ; kubelet les recréera.
• Bug dans la version de kubelet : vérifiez les problèmes connus pour votre version Kubernetes et envisagez une mise à niveau.

Mode de défaillance 4 : PLEG n'est pas sain

Symptôme : le nœud passe périodiquement à NotReady, les journaux affichent PLEG is not healthy.

Cela indique que kubelet ne peut pas obtenir les événements de cycle de vie des pods auprès du runtime, souvent en raison de lenteurs ou de bugs du runtime. Examinez les métriques et journaux du runtime de conteneur, et envisagez de redémarrer le runtime :

sudo systemctl restart containerd

Vérifiez ensuite que kubelet récupère.

Vérification de la récupération

Après toute action de récupération, confirmez que le nœud redevient Ready :

kubectl wait --for=condition=Ready node/<NODE_NAME> --timeout=60s

Vérifiez ensuite que les pods sont replanifiés et en cours d'exécution.

Liste de contrôle opérationnelle

Utilisez cette liste de contrôle lors de la maintenance de routine, de la réponse aux incidents, ou avant/après les mises à niveau du cluster. Chaque élément est concret et inclut la commande à exécuter.

Exemple de flux de travail : vérification kubelet avant mise à niveau

Avant de mettre à niveau kubelet ou le système d'exploitation du nœud, exécutez cette séquence :

1. Isolez le nœud pour empêcher de nouveaux pods :

kubectl cordon <NODE_NAME>

1. Drainez les pods (en respectant les PodDisruptionBudgets) :

kubectl drain <NODE_NAME> --ignore-daemonsets --delete-emptydir-data

1. Sauvegardez la configuration de kubelet :

sudo cp -r /var/lib/kubelet /var/lib/kubelet.backup.$(date +%Y%m%d)

1. Effectuez la mise à niveau selon votre guide de mise à niveau Kubernetes.

1. Dé-isolez le nœud :

kubectl uncordon <NODE_NAME>

1. Vérifiez que le nœud est Ready :

kubectl get nodes

1. Vérifiez les journaux de kubelet pour les erreurs après la mise à niveau :

journalctl -u kubelet --since "5 minutes ago" --no-pager

Vérifications de cohérence après un changement de configuration

Si vous avez modifié la configuration de kubelet, exécutez ces vérifications supplémentaires :

• Pour la planification des pods : kubectl run test-pod --image=busybox --restart=Never -- sleep 10 puis vérifiez qu'il se termine.
• Pour les limites de ressources : kubectl describe node <NODE_NAME> | grep -A5 Allocated resources pour voir la pression.

Conclusion

L'exploitation de kubelet en production exige une approche méthodique : connaître votre version et votre environnement, effectuer un changement ciblé à la fois, vérifier avec des commandes concrètes et toujours disposer d'un chemin de récupération testé. La liste de contrôle de cet article vous donne une base, mais adaptez-la aux spécificités de votre cluster, telles que votre runtime de conteneur, votre plugin CNI et votre fournisseur cloud.

Un flux de travail technique fiable rend la défaillance visible, protège les valeurs sensibles, limite les changements à la ressource prévue et définit la vérification de la récupération avant qu'un incident ne force la décision. En appliquant ces pratiques, vous réduisez les temps d'arrêt, prévenez la dérive de configuration et maintenez la santé du cluster à grande échelle.

Comme prochaine étape, choisissez une vérification à faible risque dans la liste de contrôle, exécutez-la sur un nœud de test et enregistrez les résultats. Mettez ensuite en œuvre les étapes de sauvegarde et de retour en arrière pour les changements de configuration de kubelet. Passez en revue les dépendances de votre environnement : compatibilité de version du serveur d'API Kubernetes, limites du système d'exploitation du nœud et certificats gérés par kubeadm. Avec ces habitudes, vous garderez kubelet en bon état de fonctionnement et vos charges de travail stables.