Kubernetes daemonSets

De wiki.nexiat.fr
Aller à la navigation Aller à la recherche
Fiche express
Type Contrôleur de workload
Garantie Un Pod par nœud éligible
Cas d'usage Agents de nœud : monitoring, logs, réseau
Voir aussi Kubernetes scheduling · Kubernetes taint

Un DaemonSet est un contrôleur qui garantit qu'une copie d'un Pod tourne sur chaque nœud du cluster (ou sur un sous-ensemble de nœuds sélectionné), et la maintient automatiquement au fil des évolutions du cluster : tout nouveau nœud ajouté reçoit le Pod, tout nœud retiré voit le sien nettoyé.

Usage

kubectl create -f mon-daemonset.yml
kubectl get pods -o wide   # un Pod par nœud éligible
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: agent-monitoring
spec:
  selector:
    matchLabels:
      app: agent-monitoring
  template:
    metadata:
      labels:
        app: agent-monitoring
    spec:
      containers:
        - name: agent
          image: agent-monitoring:latest

Cas d'usage typiques : agents de collecte de métriques ou de logs, plugins réseau (CNI), agents de sécurité — tout ce qui doit tourner au niveau du nœud plutôt qu'être répliqué arbitrairement.

DaemonSet vs Deployment/ReplicaSet

Critère DaemonSet Deployment / ReplicaSet
But Assurer qu'un Pod tourne sur chaque nœud éligible, utile pour les agents qui doivent fonctionner au niveau du nœud Assurer un nombre de réplicas donné, sans lien avec le nombre de nœuds
Gestion des Pods Gère directement le placement d'un Pod par nœud Répartit les réplicas selon le scheduler, sans notion de « un par nœud »
Scalabilité et disponibilité Se met à l'échelle automatiquement avec le nombre de nœuds du cluster Se met à l'échelle selon le nombre de réplicas déclaré
Type d'objet Contrôleur qui crée et gère des Pods Contrôleur qui crée et gère des Pods (via ReplicaSet)

Interaction avec les taints

Par défaut, un DaemonSet est soumis aux mêmes règles de placement que n'importe quel Pod, y compris les taints des nœuds. Il est cependant fréquent qu'un DaemonSet ait besoin de tourner partout, y compris sur des nœuds normalement réservés (control-plane, nœuds en maintenance) : on lui ajoute alors explicitement des tolerations correspondantes. Voir Kubernetes taint pour le détail des effets (NoSchedule, PreferNoSchedule, NoExecute) et des tolerations associées.

Voir aussi