Repository navigation
DaemonSets
ii02735 edited this page Oct 12, 2026
·
1 revision
Un DaemonSet garantit qu'une copie d'un Pod tourne sur chaque noeud du cluster (ou sur un sous-ensemble, via nodeSelector / affinités / tolerations).
- Nouveau noeud ajouté au cluster → le DaemonSet ajoute le Pod automatiquement.
- Noeud retiré du cluster → le DaemonSet supprime le Pod.
- Comme un ReplicaSet, le DaemonSet maintient les Pods (redémarrage en cas de plantage) et supporte les mises à jour progressives (
RollingUpdate).
Pour tout ce qui doit tourner sur chaque noeud, en général des agents d'infrastructure :
- la collecte de logs (Fluentd, Filebeat, Promtail…) ;
- les métriques de noeud (node-exporter de Prometheus) ;
- le réseau (le plugin CNI : Calico, Flannel, Cilium…) ;
- le stockage (démons de stockage distribué, Rook…) ;
- l'équilibrage et le proxy réseau (kube-proxy, envoy…) ;
- la sécurité / l'observabilité (agents de scan, d'APM…).
À l'inverse, une application métier ordinaire (API, frontend) ne doit pas être un DaemonSet : c'est le rôle d'un Deployment.
Par défaut, le Pod est créé sur tous les noeuds. Pour le restreindre :
-
nodeSelector: n'utilise que les noeuds portant certains labels (ex.disktype: ssd) ; -
affinités de noeud (
affinity.nodeAffinity) : règles plus riches (In, NotIn, Exists…) ; - tolerations : permet de scheduler sur des noeuds taintés, notamment les noeuds maîtres.
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: node-exporter
labels:
app: node-exporter
spec:
selector:
matchLabels:
app: node-exporter
updateStrategy:
type: RollingUpdate
template:
metadata:
labels:
app: node-exporter
spec:
nodeSelector:
kubernetes.io/os: linux
containers:
- name: node-exporter
image: prom/node-exporter
ports:
- containerPort: 9100Le manifeste ressemble beaucoup à celui d'un Deployment — les différences notables : il n'y a pas de replicas (le DaemonSet en déduit le nombre du nombre de noeuds), et on peut ajouter des tolerations pour les noeuds particuliers.
Comme pour un Deployment, la stratégie par défaut est RollingUpdate :
- les Pods sont remplacés noeud par noeud (paramétrable via
maxUnavailable) ; - la stratégie
OnDeleteattend, elle, la suppression manuelle d'un Pod pour le recréer avec la nouvelle version.
-
ReplicaSet / Deployment :
Nréplicas, répartis n'importe où dans le cluster. - DaemonSet : un Pod par noeud, pas de notion de compteur de réplicas (le Pod « suit » le noeud).
- Lister les DaemonSets :
kubectl get daemonsets(oukubectl get ds) - Obtenir les détails :
kubectl describe ds node-exporter - Voir sur quel noeud tourne chaque Pod :
kubectl get pods -o wide - Redémarrer les Pods :
kubectl rollout restart daemonset/node-exporter - Supprimer un DaemonSet et ses Pods :
kubectl delete daemonset node-exporter
Kubernetes (k8s)
- Accueil
- Vue d'ensemble
- Les containers
- L'orchestration
- L'architecture de k8s
- Les composants de k8s
- Noeud maître vs noeud esclave
- Les namespaces
- Les pods
- Les sondes et le cycle de vie
- Les ReplicaSets
- Les Deployments
- Les Jobs
- Les CronJobs
- Les DaemonSets
- Les StatefulSets
- Les ConfigMaps et Secrets
- Les volumes persistants (PV & PVC)
- Les Services
- Les Ingress
- Le Gateway API
- La mise à l'échelle
- Le RBAC
- Helm
- kubectl