Commandes de base des DaemonSets Kubernetes avec exemples pratiques

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           <none>          10d
logging       fluentd-agent    3         3         3       3            3           <none>          5d
monitoring    node-exporter    3         3         3       3            3           <none>          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           <none>          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       <none>           <none>
node-exporter-fghij   1/1     Running   0          5d    10.244.2.5   worker-2       <none>           <none>
node-exporter-klmno   1/1     Running   0          5d    10.244.3.5   worker-3       <none>           <none>

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         <none>
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.

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 <node-name> | grep Taints, et comparez avec les tolerations du DaemonSet.
• Le nœud est cordonné : kubectl get node <node-name> montre SchedulingDisabled.
• Ressources insuffisantes : kubectl describe node <node-name> | 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 <node-name> 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 <pod-name> -n <namespace> --previous
kubectl describe pod <pod-name> -n <namespace>

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 <pod-name> -n <namespace> | 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 <name> -n <namespace> 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/<name> -n <namespace>.
• Reprenez avec kubectl rollout resume daemonset/<name> -n <namespace> 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 <namespace>.
• [ ] Décrivez le DaemonSet cible : kubectl describe ds <name> -n <namespace>.
• [ ] Exportez le YAML actuel vers une sauvegarde : kubectl get ds <name> -n <namespace> -o yaml > backup.yaml.
• [ ] Vérifiez la stratégie de mise à jour et l’historique des déploiements : kubectl get ds <name> -o jsonpath='{.spec.updateStrategy.type}' et kubectl rollout history ds/<name>.
• [ ] 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/<name> -n <namespace> et confirmez le succès.
• [ ] Vérifiez le statut des Pods sur tous les nœuds : kubectl get pods -l <selector> -o wide -n <namespace>.
• [ ] 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/<name> -n <namespace> et vérifiez à nouveau.

Fiche récapitulative des commandes DaemonSet

Le tableau suivant résume les commandes essentielles pour référence rapide.

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.