DaemonSets Kubernetes : garantir un Pod sur chaque nœud éligible

Un DaemonSet garantit qu’un Pod s’exécute sur chaque nœud éligible de votre cluster Kubernetes. Contrairement à un Deployment qui répartit un nombre variable de répliques, le DaemonSet assure exactement un Pod par nœud correspondant aux critères de sélection.

Ce guide couvre la création, le ciblage de nœuds spécifiques avec nodeSelector et tolerations, les stratégies de mise à jour, et le dépannage — tout ce qu’il faut pour la certification CKAD.

Ce que vous allez apprendre

• Créer un DaemonSet et observer son déploiement automatique sur tous les nœuds
• Cibler des nœuds spécifiques avec nodeSelector et affinity
• Gérer les nœuds taintés avec tolerations (control-plane, GPU, etc.)
• Mettre à jour un DaemonSet avec les stratégies RollingUpdate et OnDelete
• Diagnostiquer pourquoi un Pod ne s’exécute pas sur un nœud

Qu’est-ce qu’un DaemonSet ?

Un DaemonSet est un contrôleur Kubernetes qui garantit qu’un Pod spécifique tourne sur tous les nœuds éligibles d’un cluster, ou sur un sous-ensemble défini par des règles de sélection.

Analogie

Imaginez un DaemonSet comme un agent de surveillance installé sur chaque poste de travail d’une entreprise. Peu importe combien de postes il y a, ou si de nouveaux postes sont ajoutés : l’agent est automatiquement déployé sur chacun d’eux.

Ce que “nœuds éligibles” signifie

Un DaemonSet ne garantit pas un Pod sur absolument tous les nœuds sans nuance. Il garantit un Pod sur tous les nœuds qui correspondent à :

• nodeSelector : labels requis sur le nœud
• affinity : règles d’affinité plus avancées
• tolerations : tolérance aux taints du nœud
• Contraintes de ressources : CPU/mémoire disponibles

Si un nœud ne satisfait pas ces critères, aucun Pod du DaemonSet n’y sera schedulé.

Comportement automatique

Événement	Action du DaemonSet
Nouveau nœud rejoint le cluster	Un Pod est automatiquement créé sur ce nœud
Nœud supprimé du cluster	Le Pod correspondant est automatiquement supprimé
Nœud devient inéligible (nouveau taint)	Le Pod est évicté si pas de toleration

Glissez pour voir

Cas d’usage courants

Les DaemonSets sont essentiels pour les agents système qui doivent tourner partout :

Catégorie	Exemples
Monitoring	Prometheus Node Exporter, Datadog Agent, Telegraf
Collecte de logs	Fluentd, Fluent Bit, Filebeat, Vector
Réseau (CNI)	Calico, Cilium, Flannel, Weave Net
Stockage (CSI)	NFS CSI Node Plugin, Longhorn, OpenEBS
Sécurité	Falco, Sysdig, Trivy Operator

Glissez pour voir

Composants système Kubernetes

Plusieurs composants système de Kubernetes sont eux-mêmes des DaemonSets : kube-proxy, le CNI (Calico, Cilium), et les node plugins CSI.

Créer un DaemonSet simple

Voici un DaemonSet minimal qui exécute un conteneur busybox affichant un message toutes les 10 secondes :

daemonset-basic.yaml

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: my-daemonset
  labels:
    app: daemon-example
spec:
  selector:
    matchLabels:
      app: daemon-example
  template:
    metadata:
      labels:
        app: daemon-example
    spec:
      containers:
        - name: busybox
          image: busybox:1.37
          command: ["sh", "-c", "while true; do echo 'DaemonSet actif sur $(hostname)'; sleep 10; done"]
          resources:
            requests:
              cpu: 10m
              memory: 16Mi
            limits:
              cpu: 50m
              memory: 32Mi

Appliquer le DaemonSet :

kubectl apply -f daemonset-basic.yaml

Vérifier le déploiement :

kubectl get ds my-daemonset
# NAME           DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
# my-daemonset   3         3         3       3            3           <none>          45s

Les colonnes importantes :

Colonne	Signification
DESIRED	Nombre de nœuds éligibles
CURRENT	Nombre de Pods créés
READY	Nombre de Pods en état Ready
UP-TO-DATE	Pods avec la spec à jour
NODE SELECTOR	Sélecteur de nœuds (si défini)

Glissez pour voir

Voir sur quels nœuds les Pods tournent :

kubectl get pods -l app=daemon-example -o wide
# NAME                 READY   STATUS    NODE
# my-daemonset-7x2km   1/1     Running   node-worker-1
# my-daemonset-9f4np   1/1     Running   node-worker-2
# my-daemonset-kj8rt   1/1     Running   node-control-plane

Cibler certains nœuds seulement

Un DaemonSet peut être limité à un sous-ensemble de nœuds avec nodeSelector ou affinity. C’est utile pour :

• Déployer uniquement sur les nœuds Linux (kubernetes.io/os: linux)
• Cibler un pool spécifique (GPU, infra, edge)
• Exclure les nœuds de développement

Avec nodeSelector

La méthode la plus simple. Le DaemonSet ne crée des Pods que sur les nœuds ayant tous les labels spécifiés.

daemonset-nodeselector.yaml

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: infra-agent
spec:
  selector:
    matchLabels:
      app: infra-agent
  template:
    metadata:
      labels:
        app: infra-agent
    spec:
      nodeSelector:
        kubernetes.io/os: linux
        nodepool: infra
      containers:
        - name: agent
          image: busybox:1.37
          command: ["sh", "-c", "echo 'Agent infra'; sleep infinity"]

Vérifier les labels d’un nœud :

kubectl get node node-worker-1 --show-labels

Ajouter un label à un nœud :

kubectl label node node-worker-1 nodepool=infra

Avec nodeAffinity (plus flexible)

Pour des règles plus complexes (opérateurs In, NotIn, Exists) :

spec:
  template:
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                  - key: kubernetes.io/arch
                    operator: In
                    values:
                      - amd64
                      - arm64

Gérer les nœuds taintés

Par défaut, les Pods ne sont pas schedulés sur les nœuds portant un taint NoSchedule. Pour qu’un DaemonSet s’exécute sur ces nœuds (par exemple les control-plane), vous devez ajouter des tolerations.

Cas courant : control-plane nodes

Les nœuds control-plane portent généralement le taint node-role.kubernetes.io/control-plane:NoSchedule. Pour y déployer un agent de monitoring :

daemonset-controlplane.yaml

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: monitoring-agent
spec:
  selector:
    matchLabels:
      app: monitoring-agent
  template:
    metadata:
      labels:
        app: monitoring-agent
    spec:
      tolerations:
        - key: "node-role.kubernetes.io/control-plane"
          operator: "Exists"
          effect: "NoSchedule"
      containers:
        - name: node-exporter
          image: prom/node-exporter:v1.9.0
          ports:
            - containerPort: 9100
              name: metrics

Tolérer tous les taints (agents critiques)

Pour les agents système qui doivent absolument tourner partout (y compris sur des nœuds avec n’importe quel taint) :

tolerations:
  - operator: "Exists"

À utiliser avec précaution

Cette toleration universelle permet au Pod de tourner même sur des nœuds marqués NoExecute pour maintenance. Réservez-la aux agents vraiment critiques comme les CNI ou les collecteurs de logs.

Vérifier les taints d’un nœud

kubectl describe node node-control-plane | grep -A 5 Taints
# Taints:             node-role.kubernetes.io/control-plane:NoSchedule

Observer l’état d’un DaemonSet

Ces commandes sont essentielles pour le dépannage et l’examen CKAD.

Commandes principales

# Vue d'ensemble des DaemonSets
kubectl get ds

# Détails complets (événements, sélecteur, stratégie)
kubectl describe ds my-daemonset

# Pods du DaemonSet avec leurs nœuds
kubectl get pods -l app=daemon-example -o wide

# État du rollout en cours
kubectl rollout status ds/my-daemonset

# Historique des révisions
kubectl rollout history ds/my-daemonset

Comprendre la sortie de describe

kubectl describe ds my-daemonset

Sections importantes à observer :

Section	Ce qu’elle montre
Selector	Labels utilisés pour matcher les Pods
Node-Selector	Contrainte nodeSelector active
Update Strategy	RollingUpdate ou OnDelete
Pods Status	Répartition Running/Waiting/Failed
Events	Historique de création/mise à jour des Pods

Glissez pour voir

Mettre à jour un DaemonSet

Kubernetes propose deux stratégies de mise à jour pour les DaemonSets.

RollingUpdate (par défaut)

C’est la stratégie par défaut depuis l’API apps/v1. Kubernetes remplace les Pods progressivement, un par un, en respectant les contraintes configurées.

daemonset-rollingupdate.yaml

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: my-daemonset
spec:
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1      # Max de Pods indisponibles pendant la MAJ
      maxSurge: 0            # Pas de Pod supplémentaire créé avant suppression
  selector:
    matchLabels:
      app: daemon-example
  template:
    metadata:
      labels:
        app: daemon-example
    spec:
      containers:
        - name: busybox
          image: busybox:1.37  # Changez cette image pour déclencher un rollout

Paramètres de contrôle :

Paramètre	Description	Valeur par défaut
maxUnavailable	Nombre max de Pods indisponibles pendant la mise à jour	1
maxSurge	Nombre de Pods supplémentaires créés avant suppression (K8s 1.22+)	0
minReadySeconds	Délai avant de considérer un Pod comme Ready	0

Glissez pour voir

Appliquer une mise à jour :

kubectl apply -f daemonset-rollingupdate.yaml

Suivre la progression :

kubectl rollout status ds/my-daemonset
# Waiting for daemon set "my-daemonset" rollout to finish: 1 out of 3 new pods have been updated...
# daemon set "my-daemonset" successfully rolled out

Annuler en cas de problème :

kubectl rollout undo ds/my-daemonset

OnDelete (contrôle manuel)

Avec OnDelete, Kubernetes ne met pas à jour automatiquement les Pods existants. Vous devez les supprimer manuellement pour qu’ils soient recréés avec la nouvelle spec.

spec:
  updateStrategy:
    type: OnDelete

Workflow :

1. Modifier la spec du DaemonSet

   kubectl apply -f daemonset-updated.yaml

2. Les Pods existants ne changent pas (vérifiez avec kubectl get pods)

3. Supprimer manuellement un Pod pour déclencher sa recréation

   kubectl delete pod my-daemonset-7x2km

4. Le nouveau Pod est créé avec la nouvelle spec

Cas d’usage de OnDelete :

• Mise à jour contrôlée nœud par nœud
• Validation manuelle avant chaque remplacement
• Environnements critiques avec approbation requise

Dépannage des DaemonSets

Problèmes courants et solutions

Symptôme	Cause probable	Diagnostic	Solution
DESIRED ≠ CURRENT	Nœud tainté ou contraintes de ressources	kubectl describe ds → Events	Ajouter toleration ou ajuster nodeSelector
Pod Pending	Pas de nœud éligible	kubectl describe pod	Vérifier labels/taints des nœuds
ImagePullBackOff	Image introuvable ou registre inaccessible	kubectl logs <pod>	Vérifier le nom de l’image et les credentials
CrashLoopBackOff	Application qui plante en boucle	kubectl logs <pod> --previous	Corriger l’application ou sa configuration
Pod non créé sur un nœud	NodeSelector ou affinity non satisfaits	kubectl get node --show-labels	Ajouter les labels requis au nœud

Glissez pour voir

Commandes de diagnostic

# Voir pourquoi un DaemonSet n'a pas le bon nombre de Pods
kubectl describe ds my-daemonset

# Identifier les nœuds sans Pod du DaemonSet
kubectl get nodes -o wide
kubectl get pods -l app=daemon-example -o wide

# Comparer nœuds et Pods
kubectl get nodes --no-headers | wc -l    # Nombre de nœuds
kubectl get pods -l app=daemon-example --no-headers | wc -l  # Nombre de Pods

# Vérifier un nœud spécifique
kubectl describe node node-worker-2 | grep -E "Taints|Conditions" -A 3

Exemple de résolution : Pod manquant sur un nœud tainté

Symptôme : 3 nœuds, mais seulement 2 Pods DaemonSet.

kubectl get ds my-daemonset
# DESIRED   CURRENT   READY
# 2         2         2

Diagnostic :

kubectl describe ds my-daemonset
# Events:
#   Warning  FailedCreate  DaemonSet controller  0/3 nodes are available:
#   1 node(s) had untolerated taint {gpu: "true"}

Solution :

tolerations:
  - key: "gpu"
    operator: "Equal"
    value: "true"
    effect: "NoSchedule"

DaemonSet vs Deployment vs StatefulSet

Choisir la bonne ressource est essentiel pour la CKAD. Voici un comparatif :

Critère	DaemonSet	Deployment	StatefulSet
Nombre de Pods	1 par nœud éligible	N répliques (variable)	N répliques ordonnées
Identité des Pods	Anonyme	Anonyme	Stable (pod-0, pod-1…)
Stockage	Généralement local/hostPath	PVC partagé ou sans état	PVC dédié par Pod
Cas d’usage	Agents système, CNI, logs	Applications stateless, APIs	Bases de données, queues
Scaling	Automatique (suit les nœuds)	kubectl scale ou HPA	kubectl scale
Mise à jour	RollingUpdate ou OnDelete	RollingUpdate	RollingUpdate ou OnDelete

Glissez pour voir

Quand choisir un DaemonSet ?

• Vous avez besoin d’un agent sur chaque nœud (ou sous-ensemble)
• L’application doit accéder aux ressources locales du nœud (logs, métriques, réseau)
• Le nombre de répliques doit suivre automatiquement le nombre de nœuds

Quand NE PAS utiliser un DaemonSet ?

• Votre application ne dépend pas du nœud → Deployment
• Vous avez besoin d’identités stables et de stockage persistant → StatefulSet
• Vous voulez scaler indépendamment du nombre de nœuds → Deployment + HPA

À retenir

1. Un DaemonSet garantit un Pod sur chaque nœud éligible, pas sur tous les nœuds sans distinction
2. L’éligibilité dépend des nodeSelector, affinity, tolerations et des ressources disponibles
3. La stratégie de mise à jour par défaut est RollingUpdate (pas OnDelete)
4. Utilisez maxUnavailable pour contrôler le rythme des mises à jour
5. Les tolerations sont nécessaires pour les nœuds control-plane ou taintés
6. kubectl describe ds est votre meilleur ami pour diagnostiquer les problèmes
7. Choisissez DaemonSet pour les agents système, Deployment pour les applications scalables

Contrôle de connaissances

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

7 questions

5 min.

90% 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

Prochaines étapes

Pods Kubernetes Comprendre l'unité de base de Kubernetes

StatefulSets Gérer des applications avec état et identité stable

Taints et Tolerations Contrôler le placement des Pods sur les nœuds

Troubleshooting Kubernetes Diagnostiquer et résoudre les problèmes courants

×

📖 Voir la documentation →