Concepts avancés des DaemonSets Kubernetes : planification, mises à jour, gestion des ressources et dépannage avec exemples pratiques

Les DaemonSets Kubernetes garantissent qu'une copie d'un Pod s'exécute sur tous les nœuds du cluster ou sur certains d'entre eux. Ce guide va au-delà des bases pour couvrir les mécanismes internes avancés des DaemonSets, les subtilités de planification, les stratégies de mise à jour, la gestion des ressources et le dépannage opérationnel. Nous allons suivre un exemple réaliste d'exécution d'un agent de surveillance de nœud en tant que DaemonSet, avec des commandes concrètes, des configurations et des étapes de vérification.

Introduction

Les DaemonSets sont un contrôleur de charge de travail essentiel dans Kubernetes. Bien que de nombreuses équipes les utilisent pour la collecte de journaux, la surveillance ou les plugins de stockage, peu exploitent pleinement leurs capacités avancées. Comprendre les mécanismes internes des DaemonSets aide les opérateurs à éviter les pièges courants tels que des Pods s'exécutant sur des nœuds non prévus, des tempêtes de mises à jour ou des conflits de ressources. Ce guide propose une analyse approfondie des concepts avancés des DaemonSets, notamment l'affinité de nœuds, les stratégies de déploiement, la gestion des ressources et les diagnostics. À la fin, vous serez en mesure de concevoir des DaemonSets robustes, efficaces et faciles à exploiter en production.

Nous utiliserons un scénario pratique : le déploiement d'un agent de surveillance de nœud (comme l'exportateur de nœuds Prometheus) en tant que DaemonSet. Les principes s'appliquent à tout service au niveau du nœud.

Inventaire de la version et de l'environnement

Avant de mettre en œuvre les fonctionnalités avancées des DaemonSets, vérifiez la version de votre cluster et votre environnement. Certaines fonctionnalités, comme rollingUpdate avec maxSurge et maxUnavailable, nécessitent Kubernetes 1.12 ou plus. D'autres, comme podAffinity ou topologySpreadConstraints, ont évolué au fil des versions. Vérifiez la version de votre serveur d'API :

kubectl version --short

Sortie attendue (exemple) :

Client Version: v1.24.3
Server Version: v1.25.2

Assurez-vous que kubectl est configuré avec les autorisations RBAC appropriées pour les DaemonSets (cluster-admin ou équivalent). Testez la connectivité :

kubectl get nodes

Exemple de sortie :

NAME     STATUS   ROLES                  AGE   VERSION
node-1   Ready    control-plane,master   10d   v1.25.2
node-2   Ready    <none>                 10d   v1.25.2
node-3   Ready    <none>                 10d   v1.25.2

Si votre cluster a des rôles de nœuds mixtes ou des teintes (taints), identifiez-les car les DaemonSets doivent tolérer ces teintes pour planifier des Pods sur certains nœuds. Par exemple, les nœuds du plan de contrôle ont souvent une teinte node-role.kubernetes.io/control-plane. Vous pouvez lister les teintes :

kubectl get nodes -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints

Exemple de sortie :

NAME     TAINTS
node-1   [map[effect: NoSchedule key: node-role.kubernetes.io/control-plane]]
node-2   <none>
node-3   <none>

Enfin, notez le runtime de conteneur et toutes les ressources au niveau du nœud auxquelles vous devez accéder. Pour notre agent de surveillance, nous monterons des chemins du système de fichiers hôte, donc les paramètres de sécurité du Pod doivent le permettre.

Chemin de configuration sûr

La configuration avancée d'un DaemonSet implique plusieurs domaines clés : la planification sur les nœuds, la stratégie de mise à jour, la gestion des ressources et la sécurité. Nous mettrons en œuvre chaque étape de manière incrémentale, en vérifiant au fur et à mesure.

Étape 1 : DaemonSet de base avec sélecteur de nœud et tolérances

Commencez par un DaemonSet minimal qui cible tous les nœuds Linux. Nous utiliserons un sélecteur de nœud basé sur kubernetes.io/os: linux et ajouterons des tolérances pour les teintes courantes afin de garantir que l'agent s'exécute partout. Enregistrez le manifeste suivant sous daemonset-basic.yaml :

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-agent
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: node-agent
  template:
    metadata:
      labels:
        app: node-agent
    spec:
      nodeSelector:
        kubernetes.io/os: linux
      tolerations:
        - key: node-role.kubernetes.io/control-plane
          operator: Exists
          effect: NoSchedule
        - key: node-role.kubernetes.io/master
          operator: Exists
          effect: NoSchedule
      containers:
        - name: agent
          image: quay.io/prometheus/node-exporter:v1.3.1
          ports:
            - containerPort: 9100
              name: metrics
          resources:
            requests:
              cpu: 100m
              memory: 64Mi
            limits:
              cpu: 200m
              memory: 128Mi
          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            runAsNonRoot: true
            runAsUser: 65534

Appliquez et vérifiez :

kubectl create namespace monitoring
kubectl apply -f daemonset-basic.yaml
kubectl get daemonset node-agent -n monitoring

Sortie attendue :

NAME          DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
node-agent    3         3         3       3            3           <none>          10s

Étape 2 : Planification avancée avec affinité de nœud

Les sélecteurs de nœud sont simples mais limités. Utilisez nodeAffinity pour des règles plus expressives, comme la planification sur des nœuds avec des étiquettes spécifiques ou l'exclusion d'autres. Par exemple, supposons que nous voulions éviter les nœuds dans un pool préemptible. Étiquetez d'abord les nœuds en conséquence (si ce n'est pas déjà fait) :

kubectl label node node-2 node-pool=regular
kubectl label node node-3 node-pool=regular
kubectl label node node-1 node-pool=control-plane

Mettez ensuite à jour la spécification du DaemonSet pour inclure affinity.nodeAffinity :

spec:
  template:
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                  - key: node-pool
                    operator: In
                    values: [regular, control-plane]
      nodeSelector: {}
      tolerations: ...  # comme avant

Appliquez le changement :

kubectl apply -f daemonset-basic.yaml

Vérifiez l'état du déploiement :

kubectl rollout status daemonset node-agent -n monitoring

Sortie attendue :

daemon set "node-agent" successfully rolled out

Étape 3 : Stratégie de mise à jour progressive

Par défaut, les DaemonSets utilisent RollingUpdate avec maxUnavailable: 1 et maxSurge: 0. Cela signifie qu'un nœud à la fois est mis à jour, garantissant la disponibilité. Pour les grands clusters, vous pouvez vouloir des mises à jour plus rapides. Configurez explicitement la stratégie de mise à jour. Dans notre DaemonSet, ajoutez :

spec:
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 0

C'est la valeur par défaut, mais être explicite documente l'intention. Si votre DaemonSet n'est pas critique et que vous avez de la capacité de réserve, vous pourriez définir maxUnavailable: 2 ou maxSurge: 1 (nécessite K8s 1.22+ pour le surge). Pour l'instant, gardez un à la fois. Appliquez et observez le déploiement :

kubectl apply -f daemonset-basic.yaml
kubectl get pods -n monitoring -o wide --watch

Observez le remplacement contrôlé : les anciens Pods sont terminés après que les nouveaux Pods deviennent prêts.

Étape 4 : Gestion des ressources et priorité

Les Pods de DaemonSet peuvent être gourmands en ressources. Définissez soigneusement les requêtes et les limites. Dans notre exemple, les requêtes sont modestes. Envisagez également de définir un priorityClassName pour garantir que les Pods de DaemonSet soient planifiés même sous pression de ressources. Créez une PriorityClass si elle n'existe pas :

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: node-agent-priority
value: 1000000
globalDefault: false
description: "Priorité pour les agents de nœud"

Ajoutez ensuite priorityClassName: node-agent-priority au modèle de Pod. Appliquez les deux.

Étape 5 : Sécurité du Pod et accès à l'hôte

Pour accéder aux métriques de l'hôte, notre conteneur peut avoir besoin de lire /proc et /sys. L'exportateur de nœuds s'exécute généralement en tant que root ou avec des capacités. Nous avons utilisé un utilisateur non root, ce qui peut limiter les fonctionnalités. Si vous avez besoin de montages hostPath, ajoutez-les et ajustez securityContext. Pour la démonstration, nous restons simples, mais soyez conscient des normes de sécurité des Pods. Dans les clusters avec Pod Security Admission, vous devrez peut-être définir des étiquettes de namespace sur pod-security.kubernetes.io/enforce=privileged ou utiliser une politique personnalisée.

Vérification et diagnostics

Après le déploiement, vérifiez que les Pods de DaemonSet s'exécutent correctement sur chaque nœud attendu.

Vérifiez l'état du DaemonSet :

kubectl get ds node-agent -n monitoring -o wide

La sortie attendue montre DESIRED, CURRENT, READY, etc., et NODE SELECTOR/AFFINITY si défini.

Assurez-vous que chaque nœud a un Pod :

kubectl get pods -n monitoring -o wide --selector=app=node-agent

Exemple :

NAME              READY   STATUS    RESTARTS   AGE    IP          NODE
node-agent-abcde   1/1     Running   0          2m     10.0.1.10   node-1
node-agent-fghij   1/1     Running   0          2m     10.0.2.10   node-2
node-agent-klmno   1/1     Running   0          2m     10.0.3.10   node-3

Comparez avec la liste des nœuds : chaque nœud prêt doit avoir un Pod (sauf exclusion par planification).

Vérifiez les journaux de l'agent :

kubectl logs daemonset/node-agent -n monitoring --tail=10

Cela renvoie les journaux d'un Pod aléatoire. Pour vérifier un Pod spécifique :

kubectl logs node-agent-abcde -n monitoring

Vérifiez le point de terminaison des métriques :

Redirigez le port vers un Pod :

kubectl port-forward pod/node-agent-abcde 9100:9100 -n monitoring

Puis dans un autre terminal :

curl localhost:9100/metrics | head

La sortie attendue inclut des lignes comme :

# HELP node_cpu_seconds_total Seconds the CPUs spent in each mode.
# TYPE node_cpu_seconds_total counter
node_cpu_seconds_total{cpu="0",mode="idle"} 12345.67

Décrivez le DaemonSet pour vérifier les événements :

kubectl describe ds node-agent -n monitoring

Recherchez des événements indiquant des échecs de planification ou d'autres problèmes.

Modes de défaillance et récupération

Les DaemonSets peuvent échouer de plusieurs manières. Les problèmes courants incluent :

Échecs de planification : Un nœud peut ne pas recevoir de Pod s'il a des teintes non tolérées, ou si les règles de sélecteur de nœud/affinité l'excluent. Vérifiez l'état du DaemonSet : DESIRED > CURRENT indique des Pods manquants.
Erreurs d'extraction d'image : Si l'image est incorrecte ou le registre inaccessible, les Pods seront en ImagePullBackOff. Vérifiez kubectl describe pod pour plus de détails.
CrashLoopBackOff : Le conteneur démarre mais se termine à plusieurs reprises. Inspectez les journaux et ajustez la commande ou les ressources.
Mise à jour bloquée : Une mise à jour progressive peut se bloquer si un nouveau Pod ne devient jamais prêt. Cela peut se produire en raison d'un échec de sonde de préparation ou de contraintes de ressources. Vérifiez kubectl rollout status et les états des Pods.
Cordon/drain de nœud : Si un nœud est cordonné, les Pods de DaemonSet peuvent quand même être planifiés (sauf si la teinte node.kubernetes.io/unschedulable est ajoutée). Comprenez le cycle de vie des nœuds.

Retour en arrière

Pour annuler une mise à jour de DaemonSet, revenez au manifeste précédent ou utilisez kubectl rollout undo :

kubectl rollout undo daemonset node-agent -n monitoring

Cela fonctionne si vous avez l'historique des déploiements activé (les DaemonSets prennent en charge l'historique depuis 1.15). Vérifiez l'historique des déploiements :

kubectl rollout history daemonset node-agent -n monitoring

Puis annulez vers une révision spécifique si nécessaire :

kubectl rollout undo daemonset node-agent -n monitoring --to-revision=2

Suppression forcée

Si un DaemonSet est bloqué, vous devrez peut-être le supprimer et le réappliquer. Utilisez --cascade=orphan pour garder les Pods en cours d'exécution temporairement, puis supprimez les Pods manuellement :

kubectl delete ds node-agent -n monitoring --cascade=orphan
kubectl delete pods -n monitoring -l app=node-agent

Ensuite, réappliquez le manifeste corrigé.

Vérification de la récupération

Après le retour en arrière, vérifiez que le DaemonSet est de nouveau sain :

kubectl rollout status daemonset node-agent -n monitoring
kubectl get ds node-agent -n monitoring

La sortie attendue montre READY égal à DESIRED.

Liste de contrôle des opérations

Utilisez cette liste de contrôle pour les opérations et revues régulières des DaemonSets.

Tâche	Commande/Action	Résultat attendu
Vérifier l'état du DaemonSet	`kubectl get ds -n monitoring`	DESIRED égal à CURRENT et READY
Vérifier la distribution des Pods	`kubectl get pods -n monitoring -o wide`	Un Pod par nœud éligible
Vérifier les Pods en attente	`kubectl get pods -n monitoring --field-selector=status.phase=Pending`	Aucun Pod listé
Examiner les événements récents	`kubectl describe ds node-agent -n monitoring`	Aucun événement d'avertissement
Inspecter les journaux pour les erreurs	`kubectl logs daemonset/node-agent -n monitoring --tail=50`	Aucun motif d'erreur répété
Valider l'utilisation des ressources	`kubectl top pods -n monitoring -l app=node-agent`	CPU/Mémoire dans les limites
Vérifier l'historique des déploiements	`kubectl rollout history daemonset node-agent -n monitoring`	Plusieurs révisions disponibles
Tester la mise à jour avec un canari	Ajouter temporairement un sélecteur de nœud pour cibler un seul nœud, mettre à jour, puis étendre	Déploiement réussi sur le nœud canari

Effectuez cette liste de contrôle après tout changement de cluster, mise à niveau ou incident.

Pièges courants et comment les éviter

La gestion des DaemonSets fait souvent trébucher les équipes de manière prévisible. Voici les erreurs les plus fréquentes et comment les éviter.

Ignorer les teintes sur les nouveaux nœuds

Ce qui se passe mal : Un nouveau nœud est ajouté avec une teinte que le DaemonSet ne tolère pas. Le DaemonSet n'y planifie jamais de Pod, ce qui conduit à une infrastructure non surveillée. Cela se produit généralement lorsque les équipes ajoutent des groupes de mise à l'échelle automatique ou remplacent des nœuds sans examiner les teintes.

Comment l'éviter : Incluez des tolérances larges pour les teintes courantes de rôle de nœud et de matériel dans votre spécification DaemonSet. Auditez régulièrement les nœuds et les teintes avec kubectl get nodes -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints. Configurez une alerte si DESIRED dépasse CURRENT dans kubectl get ds.

Stratégies de mise à jour trop agressives

Ce qui se passe mal : Définir maxUnavailable: 100% ou maxSurge: 100% pour accélérer les mises à jour peut entraîner le remplacement simultané de tous les Pods, provoquant une brève panne du service au niveau du nœud. Pour les agents critiques comme les expéditeurs de journaux ou les plugins CNI, cela perturbe l'observabilité ou le réseau.

Comment l'éviter : Utilisez la valeur par défaut maxUnavailable: 1 pour les DaemonSets critiques. Si vous avez besoin de mises à jour plus rapides, testez d'abord avec un nœud canari (voir liste de contrôle) et surveillez l'état du déploiement.

Négliger les requêtes et limites de ressources

Ce qui se passe mal : Sans requêtes de ressources, le planificateur peut placer les Pods de DaemonSet sur des nœuds déjà sous pression. Sans limites, un agent incontrôlable peut consommer le CPU ou la mémoire du nœud, affectant d'autres charges de travail.

Comment l'éviter : Définissez toujours resources.requests et limits appropriés pour l'agent. Utilisez régulièrement kubectl top pods pour vérifier l'utilisation réelle. Envisagez priorityClassName pour garantir la planification.

Oublier de mettre à jour les politiques de sécurité des Pods

Ce qui se passe mal : Dans les clusters avec Pod Security Admission (PSA) ou les anciennes PodSecurityPolicy (PSP), les Pods de DaemonSet qui nécessitent un accès privilégié (par exemple, monter /proc de l'hôte) ne démarrent pas lorsque les politiques de namespace sont appliquées. Cela se manifeste par CreateContainerConfigError ou un refus d'admission.

Comment l'éviter : Examinez les capacités requises pour votre agent. Utilisez le moindre privilège possible, mais si l'accès à l'hôte est nécessaire, étiquetez le namespace avec le niveau PSA approprié (par exemple, pod-security.kubernetes.io/enforce=privileged pour le namespace de surveillance). Documentez clairement les exceptions.

Oublier les effets du cordon ou du drain de nœud

Ce qui se passe mal : Lorsqu'un nœud est cordonné, beaucoup supposent que les Pods de DaemonSet n'y seront pas planifiés, mais les DaemonSets contournent le drapeau non planifiable à moins que le nœud n'ait la teinte node.kubernetes.io/unschedulable. Inversement, lors d'un drain, les Pods de DaemonSet sont souvent ignorés par kubectl drain à moins que --ignore-daemonsets ne soit défini, ce qui crée une confusion sur les Pods restants.

Comment l'éviter : Comprenez les sémantiques de cordon par rapport aux teintes. Utilisez kubectl drain --ignore-daemonsets lors de l'évacuation des charges de travail régulières, et supprimez manuellement les Pods de DaemonSet si nécessaire. Documentez les procédures de maintenance des nœuds dans les runbooks.

Planification avancée avec contraintes de répartition topologique

Au-delà de l'affinité de nœud, considérez topologySpreadConstraints pour répartir uniformément les Pods de DaemonSet entre les domaines de défaillance comme les zones. Bien qu'un DaemonSet place déjà un Pod par nœud, les contraintes de répartition deviennent utiles lorsque vous avez plusieurs DaemonSets qui ne devraient pas cohabiter, ou lorsque les nœuds sont regroupés en zones logiques. Par exemple, pour répartir notre agent de surveillance entre les zones de disponibilité :

spec:
  template:
    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              app: node-agent

Cela garantit que si les zones ont un nombre inégal de nœuds, le planificateur essaie de maintenir le nombre de Pods dans chaque zone à un près les uns des autres. Appliquez et vérifiez avec kubectl get pods -n monitoring -o wide --sort-by=.spec.nodeName.

Surveillance et alertes pour les DaemonSets

Pour garder les DaemonSets sains, intégrez-les dans votre pile de surveillance. Voici les métriques clés à suivre (en utilisant Prometheus comme exemple) :

kube_daemonset_status_desired_number_scheduled vs kube_daemonset_status_current_number_scheduled : Alertez si desired > current pendant plus de 5 minutes.
kube_daemonset_status_number_ready : Doit être égal à desired.
kube_daemonset_status_updated_number_scheduled : Pendant les mises à jour, cela diffère temporairement ; surveillez les déploiements bloqués.
Taux de redémarrage des Pods : rate(kube_pod_container_status_restarts_total{namespace="monitoring"}[5m]) > 0 indique une instabilité.

Configurez des alertes avec ces expressions et routez-les vers votre rotation d'astreinte. Révisez les seuils d'alerte trimestriellement pour éviter le bruit.

Durcissement de la sécurité

La sécurité des DaemonSets va au-delà de Pod Security Admission. Considérez ces pratiques :

Exécuter en non-root : Définissez toujours runAsNonRoot: true sauf si absolument nécessaire. Notre exemple d'exportateur de nœuds utilise UID 65534 (nobody), ce qui fonctionne pour les métriques de base mais peut nécessiter root pour certains collecteurs.
Utiliser un système de fichiers racine en lecture seule : Définissez readOnlyRootFilesystem: true pour empêcher toute altération.
Supprimer les capacités : Utilisez capabilities.drop: ["ALL"] et ajoutez uniquement celles nécessaires. Pour l'exportateur de nœuds, vous pouvez avoir besoin de CAP_SYS_TIME pour certains collecteurs ; testez soigneusement.
Limiter l'utilisation de hostPath : Préférez hostPath avec type spécifié (par exemple, Directory ou File) et évitez de monter des chemins sensibles comme /etc/kubernetes sauf si nécessaire.
Politiques réseau : Appliquez des NetworkPolicies au namespace pour restreindre le trafic vers et depuis les Pods de DaemonSet.

Par exemple, un contexte de sécurité durci pour notre agent :

securityContext:
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  runAsNonRoot: true
  runAsUser: 65534
  capabilities:
    drop: ["ALL"]
    add: ["CAP_SYS_TIME"]

Testez minutieusement dans un cluster de staging avant d'appliquer en production.

Conclusion

Les concepts avancés des DaemonSets permettent un contrôle précis des charges de travail au niveau des nœuds dans Kubernetes. En utilisant l'affinité de nœud, les tolérances, des stratégies de mise à jour explicites et la gestion des ressources, vous pouvez garantir une opération fiable et efficace. Ce guide a démontré une mise en œuvre pratique avec un agent de surveillance, couvrant la configuration, la vérification, la récupération en cas d'échec et une liste de contrôle opérationnelle. Utilisez ces modèles comme base pour vos propres DaemonSets, en les adaptant à votre environnement et à vos exigences.

Pour en savoir plus, consultez la documentation officielle des DaemonSets Kubernetes et la référence API pour plus de détails sur tous les champs.