Kubernetes 042 – DaemonSets : principe et demo avec node exporter

TL;DR

Un DaemonSet lance automatiquement un pod sur chaque noeud correspondant. C’est l’objet adapte aux agents d’infrastructure: collecteurs de logs, agents reseau, node exporter, stockage ou securite. Quand un noeud rejoint le cluster, Kubernetes y cree aussi le pod du DaemonSet.

La video de reference

Video: https://www.youtube.com/watch?v=BdXhAvXDqWY

L’episode illustre le DaemonSet avec un cas tres courant: exposer des metriques machine via node exporter.

Pourquoi un DaemonSet ?

Un Deployment cherche un nombre de replicas. Un DaemonSet cherche une presence par noeud. Ce n’est pas le meme objectif.

Pour collecter les metriques de chaque machine, il faut un agent sur chaque machine. Un Deployment a 3 replicas ne garantit pas cela. Un DaemonSet oui.

Exemple minimal

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-exporter
spec:
  selector:
    matchLabels:
      app: node-exporter
  template:
    metadata:
      labels:
        app: node-exporter
    spec:
      hostNetwork: true
      containers:
        - name: node-exporter
          image: prom/node-exporter:latest
          args:
            - --path.rootfs=/host
          ports:
            - containerPort: 9100
              hostPort: 9100
              name: metrics
          volumeMounts:
            - name: root
              mountPath: /host
              readOnly: true
      volumes:
        - name: root
          hostPath:
            path: /

Ce manifest est pedagogique. En production, il faut durcir les permissions et suivre les manifests recommandes.

Observer le DaemonSet

kubectl apply -f node-exporter.yaml
kubectl get daemonset
kubectl get pods -o wide -l app=node-exporter
kubectl describe daemonset node-exporter

La colonne NODE doit montrer un pod par noeud cible.

Noeuds cibles

Par defaut, le DaemonSet vise les noeuds schedulables compatibles. On peut restreindre avec nodeSelector, nodeAffinity ou tolerations.

Exemple simple:

spec:
  template:
    spec:
      nodeSelector:
        monitoring: enabled

Il faut alors labelliser les noeuds:

kubectl label node worker1 monitoring=enabled

Taints et tolerations

Les noeuds control plane portent souvent des taints. Pour y lancer un DaemonSet, il faut une toleration adaptee. Beaucoup d’agents d’infrastructure doivent tourner aussi sur les control planes, mais ce choix doit etre explicite.

Mise a jour d’un DaemonSet

Un DaemonSet supporte les updates progressives. On peut changer l’image puis observer le rollout:

kubectl set image daemonset/node-exporter node-exporter=prom/node-exporter:v1.8.2
kubectl rollout status daemonset/node-exporter

La strategie doit eviter de retirer tous les agents en meme temps.

Cas d’usage classiques

• Collecte de logs avec Fluent Bit ou Vector.
• Monitoring avec node exporter.
• Agents CNI sur chaque noeud.
• Agents de securite.
• Plugins de stockage.

Liens utiles

• Video: https://www.youtube.com/watch?v=BdXhAvXDqWY
• Playlist Kubernetes v2: https://www.youtube.com/playlist?list=PLn6POgpklwWo6wiy2G3SjBubF6zXjksap
• Depot Xavki Kubernetes v2: https://gitlab.com/xavki/tutorials-kubernetes-v2
• DaemonSet: https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/
• Node exporter: https://github.com/prometheus/node_exporter

FAQ

Un DaemonSet cree-t-il un pod par namespace ?

Non. Il cree des pods dans son namespace, repartis sur les noeuds.

Que se passe-t-il quand un nouveau noeud arrive ?

Le controleur DaemonSet cree automatiquement un pod sur ce noeud si les contraintes le permettent.

Peut-on avoir plusieurs DaemonSets ?

Oui, c’est tres courant pour logs, reseau, monitoring et securite.

Erreurs frequentes

• Utiliser un Deployment pour un besoin par noeud.
• Oublier les tolerations pour les noeuds taintes.
• Monter trop largement le host filesystem sans comprendre le risque.
• Ne pas verifier le placement avec -o wide.

Pour pratiquer

Lancez un DaemonSet simple sur un cluster multi-noeuds, ajoutez un label restrictif, puis observez les pods crees ou supprimes selon les labels des noeuds.

Notions et definitions

• Pod: plus petite unite deployable dans Kubernetes.
• Controleur: objet qui maintient un etat attendu, comme Deployment, ReplicaSet, DaemonSet ou StatefulSet.
• Reconciliation: boucle permanente qui compare l’etat reel et l’etat desire.

Ces definitions donnent le vocabulaire minimal pour suivre l’article sans reduire Kubernetes a une simple commande. Chaque notion doit etre reliee a un objet visible avec kubectl ou a un composant du cluster.

Exemple concret

Un Deployment a trois replicas recree automatiquement un pod supprime afin de revenir a l’etat attendu declare dans sa specification.

Cet exemple sert de fil conducteur: il montre quel probleme operationnel Kubernetes cherche a resoudre et quelle ressource permet de le formaliser.

How-to rapide

• Declarer le workload avec un manifest YAML ou une commande kubectl.
• Observer les pods crees et leurs labels.
• Lire les events pour comprendre scheduling, pulls d’images et redemarrages.
• Modifier le controleur plutot que les pods generes directement.

Le how-to est volontairement court: l’idee est d’obtenir un resultat observable, puis d’utiliser les commandes de verification pour comprendre ce qui s’est passe.

Approfondir cet article

Cet episode doit surtout permettre de maitriser le passage d’un conteneur isole a un workload controle par Kubernetes. L’objectif n’est pas seulement de refaire les commandes, mais de comprendre quel objet Kubernetes est cree, quel composant le prend en charge et comment verifier le resultat.

Questions a se poser

• Quel est l’etat desire exprime dans Kubernetes ?
• Quel composant observe cet etat et tente de le reconciler ?
• Quels symptomes montrent que l’objet est cree mais pas encore operationnel ?
• Quelle commande donne l’information la plus fiable pour diagnostiquer ?

Commandes de verification

• kubectl get pods -o wide --show-labels
• kubectl describe pod <pod> pour lire scheduling, events et conditions
• kubectl rollout history deployment/<name> quand un Deployment est concerne

Ces commandes ne sont pas a apprendre par coeur. Elles servent a construire un reflexe: partir de l’objet Kubernetes, lire son etat, puis descendre vers les pods, les events, les logs ou le noeud uniquement si c’est necessaire.

Points de vigilance

• modifier un pod gere par un controleur au lieu de modifier le controleur lui-meme
• ignorer les events alors qu’ils expliquent souvent le probleme
• oublier que les labels sont le lien entre controleurs, pods et Services

Exercice conseille

Lancez un Deployment nginx a trois replicas, supprimez un pod manuellement, puis observez comment le controleur reconcilie l’etat attendu.

Pour valider la comprehension, gardez une trace courte: manifest utilise, commandes lancees, resultat attendu, resultat observe et correction appliquee. Cette methode rend les episodes suivants beaucoup plus faciles a enchainer.

Lien interne conseille

Pour poursuivre la progression, consultez aussi Kubernetes 043 – Installation kubeadm : introduction.

Conclusion

Le DaemonSet est l’objet naturel pour les agents d’infrastructure. Il transforme une exigence operationnelle simple, un agent par noeud, en comportement controle par Kubernetes.