DaemonSet Kubernetes : un Pod par nœud avec Node Exporter

Un DaemonSet Kubernetes permet de maintenir un Pod sur chaque nœud éligible du cluster. C’est le modèle adapté aux agents qui doivent observer ou équiper chaque machine : collecte de métriques, collecte de logs ou composants réseau. Avec Node Exporter, le besoin devient concret : chaque nœud expose ses propres métriques système pour que Prometheus puisse les collecter.

Table des matières

TL;DR

Un DaemonSet exprime une couverture des nœuds, plutôt qu’un nombre fixe de réplicas.
Kubernetes vise un Pod du DaemonSet par nœud éligible ; l’ajout d’un nœud éligible entraîne la création d’un nouveau Pod.
Node Exporter expose les métriques du système, généralement sur le port HTTP 9100, à l’adresse /metrics.
Le chapitre 042-daemonset fournit un manifeste node-exporter dans le namespace monitoring.
Les sélecteurs de nœuds, les taints, les tolerations et les ressources disponibles expliquent pourquoi tous les nœuds ne reçoivent pas forcément un Pod opérationnel.
Déployer l’exporter ne configure pas automatiquement la collecte Prometheus.

La vidéo de référence : Kubernetes 042 et les DaemonSets

Cet article accompagne la vidéo de xavki Kubernetes 042 — DaemonSets : c’est quoi ? démo (node exporter), dans la playlist Kubernetes.

Publié le 1er novembre 2026, cet épisode dure 18 min 41 s. Sa description l’inscrit dans une formation progressive pour débuter avec Kubernetes et renvoie aux supports du dépôt.

Le README du dépôt référence cet épisode. Son support concret est le fichier 042-daemonset/notes.txt, qui contient le manifeste YAML de Node Exporter. Malgré son extension .txt, il s’agit bien d’une définition Kubernetes.

Le fil conducteur est simple : comprendre pourquoi un agent de supervision doit suivre les machines du cluster, puis lire les champs qui permettent à cet agent conteneurisé d’observer son hôte.

DaemonSet Kubernetes : c’est quoi exactement ?

Un DaemonSet est une ressource Kubernetes dont le contrôleur maintient des Pods sur tout ou partie des nœuds. La documentation Kubernetes cite notamment les agents de logs, les agents de supervision et certains démons de stockage.

Pour une application web, on peut vouloir trois instances, indépendamment du nombre de machines. Pour un agent système, on veut plutôt couvrir chaque machine concernée. La différence est importante : trois instances d’un agent ne garantissent pas qu’un cluster de trois nœuds soit observé nœud par nœud.

Le DaemonSet définit donc un état cible lié à la topologie du cluster. Si un nouveau nœud devient éligible, le contrôleur crée le Pod correspondant. Si un Pod est supprimé alors que son nœud reste éligible, le contrôleur cherche à le remplacer.

Il s’agit d’un état désiré, pas d’une garantie instantanée de disponibilité. Une image introuvable, un manque de ressources ou une erreur de démarrage peuvent empêcher un Pod d’être prêt. Pendant certaines mises à jour, le nombre de Pods peut aussi différer temporairement de la formule simplifiée « un par nœud ».

DaemonSet, Deployment ou StatefulSet : lequel choisir ?

Le bon objet dépend de ce que l’on souhaite maintenir : un nombre d’instances, une identité stable ou une couverture des nœuds.

Ressource	Intention principale	Exemple
Deployment	Maintenir un nombre souhaité de Pods interchangeables	API HTTP avec plusieurs réplicas
StatefulSet	Maintenir des identités stables et, selon la configuration, un stockage associé	Application distribuée avec instances identifiées
DaemonSet	Maintenir un Pod sur chaque nœud éligible	Node Exporter ou agent de logs

Un DaemonSet n’est donc pas un Deployment auquel on aurait donné autant de réplicas qu’il existe de nœuds. Le nombre de nœuds évolue, et la répartition d’un Deployment dépend de ses règles de placement. Le DaemonSet exprime directement le besoin de présence locale.

Découvrez Formation et cours complet Helm, c'est partie !!!

À l’inverse, une application métier n’a généralement pas besoin de multiplier ses instances à chaque ajout de machine. Dans ce cas, un Deployment et un dimensionnement adapté restent un modèle plus naturel.

Pourquoi déployer Node Exporter avec un DaemonSet ?

Node Exporter expose des métriques matérielles et système : CPU, mémoire, interfaces réseau, disques et systèmes de fichiers, selon les collecteurs activés et le système d’exploitation.

Chaque agent doit lire les données de la machine sur laquelle il s’exécute. La représentation logique est la suivante :

Nœud Linux A → Pod Node Exporter A → métriques du nœud A
Nœud Linux B → Pod Node Exporter B → métriques du nœud B
Nœud Linux C → Pod Node Exporter C → métriques du nœud C

Prometheus interroge chaque cible sur /metrics.

Node Exporter expose les données ; Prometheus les interroge et les stocke. Le DaemonSet déploie l’agent ; il ne crée ni serveur Prometheus ni tableau de bord Grafana.

Le manifeste du chapitre ne contient d’ailleurs ni Service, ni configuration de collecte, ni ServiceMonitor. Ces composants relèvent d’une étape supplémentaire.

Lire le manifeste DaemonSet du chapitre 042

Le nom, le namespace et les labels

Voici le début du manifeste, repris du support du chapitre :

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-exporter
  namespace: monitoring
  labels:
    name: node-exporter
spec:
  selector:
    matchLabels:
      name: node-exporter
  template:
    metadata:
      labels:
        name: node-exporter

spec.selector.matchLabels sélectionne les Pods gérés par le DaemonSet. Les labels du template doivent correspondre à ce sélecteur. Le label placé dans metadata.labels, au niveau de l’objet DaemonSet, sert quant à lui à identifier l’objet lui-même.

Ce sélecteur ne choisit pas les nœuds. Pour sélectionner des machines, on utilise notamment nodeSelector ou une affinité de nœud dans spec.template.spec.

Le namespace monitoring est référencé, mais sa création ne figure pas dans le fichier. Il doit donc exister avant l’application du manifeste.

Les espaces de noms de l’hôte et le port 9100

Le template du chapitre contient :

hostPID: true
hostIPC: true
hostNetwork: true
containers:
  - name: node-exporter
    image: prom/node-exporter:latest
    ports:
      - containerPort: 9100
        protocol: TCP
    securityContext:
      privileged: true

hostPID partage l’espace des identifiants de processus de l’hôte ; hostIPC partage celui des communications interprocessus ; hostNetwork utilise le réseau de l’hôte. Ce sont les choix du manifeste pédagogique, pas des propriétés intrinsèques d’un DaemonSet.

Le port 9100 correspond au port HTTP par défaut de Node Exporter. La déclaration containerPort ne crée pas un Service. Avec hostNetwork, l’écoute de l’application utilise le réseau du nœud : il faut donc tenir compte d’un éventuel autre processus déjà à l’écoute sur ce port.

De même, privileged: true est un choix explicite de ce support. Il ne faut pas en déduire que tous les DaemonSets ou tous les déploiements Node Exporter exigent ce mode.

Les volumes hostPath et les chemins de collecte

Le fichier monte les répertoires /proc, /sys, /dev et la racine / de l’hôte dans le conteneur. Les arguments indiquent notamment :

args:
  - --path.procfs
  - /host/proc
  - --path.sysfs
  - /host/sys

Le chemin /host/proc est le chemin vu dans le conteneur, relié au /proc de l’hôte par un volume hostPath. Même principe pour /host/sys.

Cette correspondance est essentielle. Un exporter qui observe seulement l’environnement de son conteneur ne fournit pas nécessairement la vue système attendue. Le README officiel de Node Exporter insiste sur ce point pour les déploiements conteneurisés.

Adapter le support historique aux versions actuelles de Node Exporter

Le manifeste source constitue le support de l’épisode. Avant de le rejouer avec une image actuelle, trois éléments méritent une adaptation explicite.

L’image utilise latest. Ce tag ne fixe pas une version. Pour une démonstration reproductible, choisir une version publiée, contrôler son aide et conserver ce tag ou son digest dans le manifeste utilisé.

Le filtre de systèmes de fichiers utilise une ancienne option. Le support contient --collector.filesystem.ignored-mount-points, tandis que la documentation actuelle décrit --collector.filesystem.mount-points-exclude. Le nom accepté doit être vérifié pour la version retenue.

La racine est montée sur /rootfs, mais aucun argument --path.rootfs n’apparaît. La documentation officielle demande de faire correspondre cet argument au montage de la racine de l’hôte.

Pour une version exposant les options actuelles, le bloc d’arguments adapté à ces chemins peut être :

args:
  - --path.procfs=/host/proc
  - --path.sysfs=/host/sys
  - --path.rootfs=/rootfs
  - '--collector.filesystem.mount-points-exclude=^/(sys|proc|dev|host|etc)($|/)'

Ce bloc est une adaptation documentaire, pas une citation du manifeste d’origine. Les guillemets YAML encadrent la chaîne sans ajouter de guillemets littéraux à l’expression régulière. Le périmètre d’exclusion doit rester cohérent avec les systèmes de fichiers que l’on veut observer.

Découvrez Comment créer des namespaces et des déployments kubernetes avec un fichier texte ??

Déployer et vérifier le DaemonSet avec kubectl

Les commandes suivantes constituent un parcours de lecture et de vérification fondé sur le manifeste et sur la documentation de création des DaemonSets. Elles n’ont pas été exécutées sur un cluster pour cet article.

Prérequis : un cluster avec des nœuds Linux adaptés à cet exporter, un contexte kubectl fonctionnel et les droits nécessaires dans monitoring.

Depuis la racine du dépôt, préparer une copie du manifeste :

cp 042-daemonset/notes.txt /tmp/node-exporter-daemonset.yaml
kubectl get nodes -o wide
kubectl get namespace monitoring

Si le namespace n’existe pas :

kubectl create namespace monitoring

Dans la copie, fixer l’image choisie et adapter les arguments comme expliqué précédemment. Pour un cluster mixte, on peut aussi ajouter ce sélecteur sous spec.template.spec afin de cibler Linux :

nodeSelector:
  kubernetes.io/os: linux

Appliquer ensuite la copie préparée :

kubectl apply -f /tmp/node-exporter-daemonset.yaml
kubectl -n monitoring rollout status daemonset/node-exporter
kubectl -n monitoring get daemonset node-exporter
kubectl -n monitoring get pods -l name=node-exporter -o wide

La sortie du DaemonSet permet de comparer DESIRED, CURRENT et READY. La liste des Pods avec -o wide montre le nœud associé à chacun.

Il faut observer à la fois le nombre de Pods et leur placement. Trois Pods prêts ne suffisent pas, à eux seuls, à expliquer quels nœuds sont couverts ou pourquoi un autre nœud est exclu.

Consulter les métriques d’un Pod

Pour un test local, sélectionner un Pod prêt et ouvrir un transfert de port vers celui-ci :

kubectl -n monitoring get pods -l name=node-exporter
kubectl -n monitoring port-forward pod/NOM_DU_POD 19100:9100

Remplacer NOM_DU_POD par le nom obtenu. Dans un second terminal :

curl -fsS http://127.0.0.1:19100/metrics

Cette vérification porte sur une seule instance. Elle confirme que cet endpoint répond, mais ne prouve ni la couverture de tous les nœuds ni la configuration de Prometheus. Le guide Prometheus consacré à Node Exporter présente la collecte et les premières métriques à explorer.

Pourquoi un DaemonSet n’a-t-il pas de Pod sur tous les nœuds ?

« Un Pod par nœud » signifie en pratique « un Pod par nœud éligible ». Plusieurs mécanismes entrent en jeu.

Un nodeSelector ou une affinité peut limiter la couverture. Une taint peut empêcher le placement en l’absence de toleration correspondante. Les nœuds de contrôle portent souvent une taint NoSchedule ; le manifeste du chapitre ne déclare aucune toleration pour cette taint.

Kubernetes ajoute automatiquement certaines tolerations aux Pods de DaemonSet, notamment pour des conditions de nœud décrites dans la documentation officielle. Cela ne signifie pas que toutes les taints sont ignorées.

Pour comprendre un écart, commencer par les objets et leurs événements :

kubectl -n monitoring describe daemonset node-exporter
kubectl -n monitoring get pods -l name=node-exporter -o wide
kubectl -n monitoring describe pod NOM_DU_POD
kubectl describe node NOM_DU_NOEUD

Si un Pod est en CrashLoopBackOff, consulter ses logs :

kubectl -n monitoring logs NOM_DU_POD --previous

Dans ce chapitre, une option Node Exporter non reconnue est une piste concrète à vérifier. Un Pod Pending appelle plutôt une lecture des événements de placement et des contraintes. Enfin, si aucun Pod n’a été créé, les événements du DaemonSet peuvent révéler un refus de création.

Liens utiles

FAQ : DaemonSet Kubernetes et Node Exporter

Peut-on définir replicas dans un DaemonSet ?

Non. Le nombre souhaité dépend des nœuds éligibles. Le champ replicas d’un Deployment n’est pas le mécanisme de dimensionnement d’un DaemonSet.

Un DaemonSet s’exécute-t-il forcément sur les nœuds de contrôle ?

Non. Le placement dépend notamment des taints et des tolerations. Le manifeste du chapitre ne prévoit pas explicitement de toleration pour les taints habituelles des nœuds de contrôle.

Que se passe-t-il quand on ajoute un nœud au cluster ?

Si ce nœud est éligible, le contrôleur DaemonSet crée un Pod pour lui. Le démarrage effectif dépend ensuite du téléchargement de l’image, des ressources disponibles et de la validité de la configuration.

Le namespace monitoring limite-t-il le DaemonSet à certains nœuds ?

Non. Le namespace organise les ressources Kubernetes ; il ne constitue pas un sélecteur de machines. La sélection des nœuds se configure dans le template du Pod.

Node Exporter remplace-t-il Prometheus ?

Non. Node Exporter expose les métriques du système. Prometheus les collecte et les conserve. Un exporter opérationnel peut exister sans qu’aucun serveur Prometheus ne l’interroge encore.

Faut-il reprendre tel quel le manifeste historique avec latest ?

Pour le rejouer aujourd’hui, il faut vérifier la version de l’image et ses arguments. Le fichier utilise une ancienne option de filtrage et monte la racine sur /rootfs sans configurer --path.rootfs. Ces points sont explicités dans la section d’adaptation.

Conclusion

Le DaemonSet répond à un besoin précis : faire suivre un agent aux nœuds du cluster. L’exemple Node Exporter permet de relier ce mécanisme Kubernetes à une utilisation concrète, la collecte des métriques système de chaque machine.

Pour lire correctement le chapitre 042, retenir trois questions : quels nœuds sont éligibles, quelles données de l’hôte l’exporter observe-t-il, et qui collecte les métriques exposées ? Elles permettent de distinguer le placement des Pods, la configuration de l’agent et la chaîne de supervision.

Transparence IA

Ce contenu a été partiellement rédigé ou structuré avec l aide d outils d intelligence artificielle, puis relu, corrigé et complété par l auteur avant publication.