## Introduction Les DaemonSets Kubernetes garantissent qu’une copie d’un Pod spécifique s’exécute sur tous (ou certains) nœuds d’un cluster. Ils sont couramment utilisés pour les agents de collecte de journaux, les exportateurs de surveillance, les daemons de stockage et les composants réseau au niveau des nœuds. Lorsqu’un DaemonSet se comporte mal, les opérateurs ont besoin d’une approche systématique pour observer l’état actuel, identifier les écarts, apporter des modifications minimales et vérifier la récupération. Cet article fournit des commandes kubectl pratiques pour les opérations quotidiennes sur les DaemonSets. Pour chaque scénario, vous verrez la commande exacte, une sortie attendue réaliste, les signaux d’échec et les étapes de récupération. L’accent est mis sur la sécurité opérationnelle : toujours inspecter avant de modifier, utiliser des commandes en lecture seule pour le diagnostic et n’appliquer des changements que lorsque leur portée et leur chemin de retour arrière sont compris. Après avoir lu, vous serez en mesure de : - Confirmer la version du DaemonSet et l’environnement avec kubectl version et kubectl cluster-info . - Lister et décrire un DaemonSet et ses Pods avec l’étiquetage et le filtrage de sortie. - Vérifier l’historique et le statut des déploiements. - Mettre à jour un DaemonSet en utilisant kubectl apply , kubectl edit ou kubectl set image , et revenir en arrière si nécessaire. - Supprimer un DaemonSet proprement, y compris ses Pods. - Diagnostiquer les modes de défaillance courants tels que les Pods non planifiables, les boucles de crash et les incompatibilités de sélecteur de nœud. - Utiliser une fiche récapitulative concise pour référence rapide. Tous les exemples supposent que kubectl est installé et configuré pour votre cluster. Remplacez les noms de ressources et les espaces de noms par vos propres valeurs. ## Inventaire de version et d’environnement Avant d’interagir avec un DaemonSet, vérifiez que vos versions client et serveur sont compatibles et recueillez des informations de base sur le cluster. Commandes : kubectl version --short kubectl cluster-info kubectl get nodes Exemple de sortie : Client Version: v1.28.2 Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3 Server Version: v1.28.2 Kubernetes control plane is running at https://192.168.49.2:8443 CoreDNS is running at https://192.168.49.2:8443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy NAME STATUS ROLES AGE VERSION minikube Ready control-plane 10d v1.28.2 Points clés à vérifier : - Les versions mineures du client et du serveur doivent être à une version mineure près selon la politique de compatibilité de version Kubernetes. - Tous les nœuds doivent être dans l’état Ready . Si un nœud est NotReady , les Pods du DaemonSet sur ce nœud ne seront pas planifiés ou seront évincés. - Pour les clusters gérés (EKS, GKE, AKS), l’état des nœuds peut être agrégé ; utilisez kubectl get nodes -o wide pour plus de détails. Découverte de l’environnement pour un DaemonSet : Utilisez kubectl get daemonsets --all-namespaces pour voir tous les DaemonSets et leurs espaces de noms. kubectl get daemonsets --all-namespaces Exemple de sortie : NAMESPACE NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE kube-system kube-proxy 1 1 1 1 1 10d logging fluentd-agent 3 3 3 3 3 5d monitoring node-exporter 3 3 3 3 3 5d Si le DaemonSet attendu est manquant, vérifiez l’espace de noms et la méthode de déploiement. Pour les outils installés via Helm, utilisez helm list -A pour confirmer que la release existe. ## Lister et décrire les DaemonSets ### Lister tous les DaemonSets dans l’espace de noms courant kubectl get daemonsets Exemple de sortie : NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE node-exporter 3 3 3 3 3 5d ### Lister les DaemonSets dans tous les espaces de noms kubectl get daemonsets --all-namespaces ### Décrire un DaemonSet spécifique Décrire un DaemonSet montre sa configuration, les événements récents et son état. C’est la première étape de diagnostic lorsque quelque chose ne va pas. kubectl describe daemonset node-exporter -n monitoring Sections clés dans la sortie : - Selector: étiquettes utilisées pour correspondre aux Pods. - Node-Selector: nœuds où les Pods sont planifiés. - Tolerations: autorisent la planification sur des nœuds marqués. - Update Strategy: RollingUpdate ou OnDelete. - Events: événements récents de planification ou de mise à jour qui peuvent révéler des problèmes. ### Afficher les étiquettes et sélecteurs du DaemonSet kubectl get daemonset node-exporter -n monitoring -o yaml kubectl get daemonset node-exporter -n monitoring -o jsonpath='{.spec.selector.matchLabels}' Exemple de sortie : {"app":"node-exporter"} ### Lister les Pods appartenant à un DaemonSet kubectl get pods -l app=node-exporter -n monitoring -o wide Exemple de sortie : NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES node-exporter-abcde 1/1 Running 0 5d 10.244.1.5 worker-1 node-exporter-fghij 1/1 Running 0 5d 10.244.2.5 worker-2 node-exporter-klmno 1/1 Running 0 5d 10.244.3.5 worker-3 Observez si un Pod existe pour chaque nœud prévu. Si un nœud n’a pas de Pod, vérifiez les marques (taints), les étiquettes et les tolérances du DaemonSet. ## Visualiser la configuration et le YAML du DaemonSet Pour comprendre exactement ce que fait un DaemonSet, inspectez sa définition YAML complète. kubectl get daemonset node-exporter -n monitoring -o yaml Enregistrez-la dans un fichier pour l’édition ou la sauvegarde : kubectl get daemonset node-exporter -n monitoring -o yaml > node-exporter-ds.yaml Examinez les champs clés : - spec.template.spec.containers[].image : l’image du conteneur et son étiquette. - spec.updateStrategy : RollingUpdate ou OnDelete . - spec.minReadySeconds : nombre minimal de secondes pendant lesquelles un Pod doit être prêt avant d’être considéré comme disponible. - spec.revisionHistoryLimit : nombre d’anciens ReplicaSets à conserver pour revenir en arrière. ## Vérifier l’historique et le statut des déploiements Les DaemonSets prennent en charge les mises à jour progressives, comme les Deployments. Pour vérifier qu’une mise à jour s’est terminée avec succès, utilisez les commandes de déploiement. ### Vérifier le statut du déploiement kubectl rollout status daemonset/node-exporter -n monitoring Sortie réussie : daemonset "node-exporter" successfully rolled out Si le déploiement est bloqué, la commande peut expirer ou afficher des messages comme : Waiting for daemon set "node-exporter" rollout to finish: 2 of 3 updated pods are available... ### Voir l’historique des déploiements kubectl rollout history daemonset/node-exporter -n monitoring Exemple de sortie : daemonset.apps/node-exporter REVISION CHANGE-CAUSE 1 2 kubectl set image daemonset/node-exporter node-exporter=prom/node-exporter:v1.6.1 --record=true Remarque : --record=true est déprécié dans les versions récentes ; la cause du changement n’est plus stockée automatiquement. Pour voir les détails d’une révision spécifique : kubectl rollout history daemonset/node-exporter -n monitoring --revision=2 ## Mettre à jour un DaemonSet Les mises à jour peuvent être effectuées via kubectl apply , kubectl edit ou kubectl set image . Vérifiez toujours la stratégie de mise à jour d’abord. ### Vérifier la stratégie de mise à jour kubectl get daemonset node-exporter -n monitoring -o jsonpath='{.spec.updateStrategy.type}' Exemple de sortie : RollingUpdate ### Appliquer un changement de manifeste Modifiez le fichier YAML que vous avez enregistré précédemment, ou appliquez-en un nouveau : kubectl apply -f node-exporter-ds.yaml Ensuite, surveillez le déploiement avec kubectl rollout status daemonset/node-exporter -n monitoring . ### Mettre à jour l’image du conteneur avec kubectl set image kubectl set image daemonset/node-exporter node-exporter=prom/node-exporter:v1.7.0 -n monitoring Exemple de sortie : daemonset.apps/node-exporter image updated Vérifiez que la nouvelle image est utilisée : kubectl get daemonset node-exporter -n monitoring -o jsonpath='{.spec.template.spec.containers[0].image}' ### Modifier l’objet en direct kubectl edit daemonset node-exporter -n monitoring Cela ouvre l’objet dans votre éditeur par défaut. Les changements sont appliqués lors de l’enregistrement, et un déploiement démarre si la stratégie de mise à jour est RollingUpdate. ## Revenir en arrière sur un DaemonSet Si une mise à jour introduit des problèmes, revenez à une révision précédente. ### Revenir à la révision précédente kubectl rollout undo daemonset/node-exporter -n monitoring Exemple de sortie : daemonset.apps/node-exporter rolled back ### Revenir à une révision spécifique kubectl rollout undo daemonset/node-exporter -n monitoring --to-revision=1 Après le retour en arrière, vérifiez le statut et les versions des Pods : kubectl rollout status daemonset/node-exporter -n monitoring kubectl get pods -l app=node-exporter -n monitoring -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[0].image}{"\n"}{end}' ## Supprimer un DaemonSet La suppression d’un DaemonSet supprime le contrôleur DaemonSet et, par défaut, tous les Pods qu’il a créés. ### Supprimer le DaemonSet et ses Pods kubectl delete daemonset node-exporter -n monitoring Exemple de sortie : daemonset.apps "node-exporter" deleted ### Supprimer uniquement le DaemonSet sans supprimer les Pods Utilisez --cascade=orphan pour laisser les Pods s’exécuter. Cela est rarement souhaitable mais peut être utile lors d’une migration. kubectl delete daemonset node-exporter -n monitoring --cascade=orphan Les Pods orphelins continueront à s’exécuter, mais ils ne seront plus gérés par un DaemonSet. Vous pouvez les adopter plus tard avec un nouveau contrôleur ou les supprimer manuellement.

Question rapide 2 sur 2 Quelle est la principale différence entre un Deployment et un DaemonSet selon le passage ? - Les Deployments sont utilisés pour des services au niveau des nœuds, tandis que les DaemonSets sont pour des services sans état - Les DaemonSets sont utilisés pour les composants du plan de contrôle, tandis que les Deployments sont pour les nœuds de travail - Les Deployments sont utilisés pour des services sans état où la mise à l'échelle est plus importante, tandis que les DaemonSets sont utilisés lorsqu'une copie d'un Pod doit s'exécuter sur tous ou certains hôtes - Il n'y a aucune différence ; ils sont interchangeables

Le passage explique que les Deployments sont pour les services sans état où la mise à l'échelle compte, tandis que les DaemonSets sont pour des fonctionnalités au niveau des nœuds qui doivent s'exécuter sur tous ou certains nœuds.

## Commandes de diagnostic pour les Pods de DaemonSet Lorsque les Pods ne s’exécutent pas correctement, utilisez les commandes suivantes pour recueillir des informations. ### Vérifier le statut des Pods kubectl get pods -l app=node-exporter -n monitoring -o wide Recherchez les statuts non Running : Pending , CrashLoopBackOff , ImagePullBackOff , Evicted , etc. ### Décrire un Pod problématique kubectl describe pod node-exporter-abcde -n monitoring Parties clés de la sortie : - Events: montrent les événements récents de planification et de cycle de vie, tels que les échecs de tirage d’image ou les ressources insuffisantes. - Conditions: indiquent l’état de préparation du Pod et d’autres statuts. - Tolerations: montrent quelles marques le Pod tolère. ### Voir les journaux kubectl logs node-exporter-abcde -n monitoring Pour un Pod en boucle de crash, obtenez les journaux de l’instance de conteneur précédente : kubectl logs node-exporter-abcde -n monitoring --previous ### Exécuter des commandes dans le conteneur kubectl exec -it node-exporter-abcde -n monitoring -- /bin/sh Ensuite, exécutez des commandes de diagnostic comme ps aux , df -h ou cat /etc/hostname . ## Modes de défaillance courants et récupération ### Défaillance 1 : Les Pods du DaemonSet ne sont pas planifiés sur certains nœuds Symptôme : kubectl get pods -l app=node-exporter -o wide montre moins de Pods que de nœuds. Causes possibles et vérifications : - Incompatibilité de sélecteur de nœud : kubectl get ds node-exporter -o yaml | grep -A5 nodeSelector . - Marques et tolérances : kubectl describe node | grep Taints , et comparez avec les tolerations du DaemonSet. - Le nœud est cordonné : kubectl get node montre SchedulingDisabled . - Ressources insuffisantes : kubectl describe node | grep -A10 "Allocated resources" . Récupération : - Ajustez le sélecteur de nœud ou les tolérances dans la spécification du DaemonSet et appliquez. - Décordonnez le nœud avec kubectl uncordon s’il est cordonné. - Libérez des ressources ou ajustez les demandes. ### Défaillance 2 : Pods en CrashLoopBackOff Symptôme : kubectl get pods montre CrashLoopBackOff ou de nombreux redémarrages. Diagnostic : kubectl logs -n --previous kubectl describe pod -n Recherchez les codes de sortie et les messages d’erreur. Causes courantes : mauvaise configuration, dépendances manquantes, arguments de commande incorrects. Récupération : - Corrigez la configuration et mettez à jour le DaemonSet. - Si l’image est mauvaise, revenez à une version précédente. ### Défaillance 3 : ImagePullBackOff Symptôme : Pods bloqués en ImagePullBackOff ou ErrImagePull . Diagnostic : kubectl describe pod -n | grep -A5 Events Vérifiez que le nom et l’étiquette de l’image sont corrects et que le nœud peut accéder au registre (réseau, informations d’identification). Récupération : - Corrigez la référence de l’image. - Si vous utilisez un registre privé, assurez-vous que les imagePullSecrets sont définis dans la spécification du DaemonSet. - Revenez en arrière si nécessaire. ### Défaillance 4 : Mise à jour progressive bloquée Symptôme : kubectl rollout status se bloque et tous les Pods ne sont pas mis à jour. Diagnostic : - kubectl describe daemonset -n pour les événements. - Vérifiez le statut des Pods sur les nœuds individuels ; souvent dû à de nouveaux Pods non planifiables (voir Défaillance 1). - Vérifiez les paramètres maxUnavailable et minReadySeconds . Récupération : - Résolvez le problème sous-jacent de planification ou de Pod. - Si nécessaire, mettez en pause le déploiement : kubectl rollout pause daemonset/ -n . - Reprenez avec kubectl rollout resume daemonset/ -n après correction. ## Liste de contrôle des opérations Utilisez cette liste de contrôle avant et après les opérations sur les DaemonSets pour réduire les risques. Avant tout changement : - [ ] Vérifiez la santé du cluster : kubectl get nodes tous Ready. - [ ] Listez les DaemonSets actuels : kubectl get ds -n . - [ ] Décrivez le DaemonSet cible : kubectl describe ds -n . - [ ] Exportez le YAML actuel vers une sauvegarde : kubectl get ds -n -o yaml > backup.yaml . - [ ] Vérifiez la stratégie de mise à jour et l’historique des déploiements : kubectl get ds -o jsonpath='{.spec.updateStrategy.type}' et kubectl rollout history ds/ . - [ ] Comprenez le sélecteur de nœud et les tolérances pour garantir que les Pods seront planifiés comme prévu. Après tout changement : - [ ] Exécutez kubectl rollout status ds/ -n et confirmez le succès. - [ ] Vérifiez le statut des Pods sur tous les nœuds : kubectl get pods -l -o wide -n . - [ ] Consultez les journaux des nouveaux Pods pour les erreurs d’exécution. - [ ] Vérifiez le comportement de l’application (par exemple, point de terminaison de métriques, journaux collectés). - [ ] En cas d’échec, revenez en arrière avec kubectl rollout undo ds/ -n et vérifiez à nouveau. ## Fiche récapitulative des commandes DaemonSet Le tableau suivant résume les commandes essentielles pour référence rapide.

Opération	Commande
Lister les DaemonSets dans l’espace de noms courant	`kubectl get daemonsets`
Lister les DaemonSets dans tous les espaces de noms	`kubectl get daemonsets --all-namespaces`
Décrire un DaemonSet	`kubectl describe daemonset <name> -n <namespace>`
Obtenir le YAML d’un DaemonSet	`kubectl get daemonset <name> -n <namespace> -o yaml`
Vérifier le statut du déploiement	`kubectl rollout status daemonset/<name> -n <namespace>`
Voir l’historique des déploiements	`kubectl rollout history daemonset/<name> -n <namespace>`
Mettre à jour l’image	`kubectl set image daemonset/<name> <container>=<new-image> -n <namespace>`
Revenir à la version précédente	`kubectl rollout undo daemonset/<name> -n <namespace>`
Supprimer un DaemonSet	`kubectl delete daemonset <name> -n <namespace>`
Lister les Pods appartenant à un DaemonSet	`kubectl get pods -l <selector> -n <namespace>`
Obtenir les journaux d’un Pod de DaemonSet	`kubectl logs <pod-name> -n <namespace>`
Exécuter une commande dans un Pod	`kubectl exec -it <pod-name> -n <namespace> -- /bin/sh`

## Conclusion Maîtriser les commandes DaemonSet est essentiel pour quiconque opère des clusters Kubernetes. En suivant l’approche structurée de cet article, vous pouvez inspecter, mettre à jour et récupérer des DaemonSets en toute confiance tout en minimisant les risques. Commencez toujours par des commandes en lecture seule pour observer l’état actuel, effectuez un changement ciblé à la fois et vérifiez le résultat avec le statut de déploiement et les vérifications de Pods. Conservez des sauvegardes des définitions YAML et comprenez les procédures de retour en arrière. Avec ces pratiques, vous pouvez maintenir les services au niveau des nœuds fluides dans tout votre cluster.