Un Deployment à trois replicas ne dit rien sur leur répartition : les trois peuvent atterrir sur le même nœud, ou sur trois nœuds différents, selon ce que le scheduler décide (couvert dans l’article sur les contraintes de répartition). Un DaemonSet répond à un besoin structurellement différent : garantir la présence d’exactement un pod sur chaque nœud éligible, sans exception et sans configuration de replicas à gérer.

Pas de champ replicas, le nombre de nœuds décide

Un DaemonSet n’a pas de champ replicas : son nombre de pods est entièrement dicté par le nombre de nœuds qui correspondent à ses critères.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: log-collector
spec:
  selector:
    matchLabels:
      app: log-collector
  template:
    metadata:
      labels:
        app: log-collector
    spec:
      containers:
        - name: collector
          image: log-collector:1.4

Ajouter un nœud au cluster crée automatiquement un nouveau pod du DaemonSet dessus, sans intervention manuelle ; retirer un nœud supprime son pod avec lui. C’est cette propriété qui rend un DaemonSet adapté aux agents d’infrastructure (collecte de logs, monitoring, CNI, plugins de stockage) : leur couverture doit suivre la taille réelle du cluster, pas un chiffre fixé une fois et jamais révisé.

Ce que le site utilise déjà en DaemonSet, sans le nommer

Deux composants déjà couverts sur ce site tournent en DaemonSet sans que l’article correspondant ne l’explicite. Le speaker de MetalLB en mode Layer 2 doit s’exécuter sur chaque nœud susceptible de répondre aux requêtes ARP pour une IP attribuée : un DaemonSet garantit cette couverture automatiquement. Le composant engine-image de Longhorn qui gère le stockage local de chaque nœud suit le même modèle, pour une raison identique : un service qui doit exister sur chaque nœud, sans exception, correspond exactement à ce qu’un DaemonSet garantit.

Cibler un sous-ensemble de nœuds, pas tous

Un DaemonSet ne s’exécute pas nécessairement sur la totalité du cluster : un nodeSelector ou une affinité de nœud le restreint à un sous-ensemble précis.

spec:
  template:
    spec:
      nodeSelector:
        workload-type: gpu

Ce DaemonSet ne tourne alors que sur les nœuds portant le label workload-type: gpu, utile pour un agent de monitoring GPU qui n’a aucune raison d’exister sur un nœud sans GPU. Combiné à une toleration correspondante, un DaemonSet peut aussi cibler des nœuds normalement repoussés par un taint, exactement le cas d’un agent qui doit surveiller un nœud dédié malgré la répulsion posée pour le reste des workloads.

Les mises à jour respectent l’ordre, pas le parallélisme total

Une mise à jour de DaemonSet (nouvelle image, nouvelle config) suit par défaut la stratégie RollingUpdate, un nœud à la fois, jamais tous simultanément : maxUnavailable contrôle combien de nœuds peuvent être temporairement sans agent pendant la transition. Pour un agent de logs ou de monitoring, une brève absence pendant la mise à jour est généralement acceptable ; pour un composant réseau critique, maxUnavailable: 1 reste le choix le plus prudent malgré une mise à jour plus lente sur un grand cluster.

À retenir

Un DaemonSet garantit une couverture par nœud plutôt qu’un nombre de replicas fixé, sans champ replicas à gérer et avec une adaptation automatique à chaque changement de taille du cluster. C’est le modèle derrière la plupart des agents d’infrastructure, y compris deux composants déjà couverts sur ce site (MetalLB, Longhorn) sans que le mécanisme sous-jacent n’ait jamais été nommé. nodeSelector et les tolerations permettent de cibler un sous-ensemble de nœuds précis, utile dès qu’une migration Kubernetes introduit des nœuds à usage spécialisé.