DaemonSet Kubernetes : tutoriel, cas d'usage et bonnes pratiques

Tutoriel DaemonSet Kubernetes

Ce tutoriel explique comment créer et utiliser un DaemonSet. Il est adapté de la documentation Kubernetes.

1. Créer un DaemonSet Kubernetes

Pour créer un DaemonSet Kubernetes, définissez-le dans un manifeste YAML avec apiVersion: apps/v1 et kind: DaemonSet. Le manifeste doit inclure les champs Kubernetes standard, comme metadata et spec, ainsi qu'un template de pod sous .spec.template. Le .spec.selector du DaemonSet doit correspondre aux labels attribués au template de pod ; une fois le DaemonSet créé, ce selector ne peut plus être modifié. Kubernetes exige également que la politique de redémarrage du pod soit Always, soit explicitement, soit via la valeur par défaut.

Par exemple, le manifeste suivant crée un DaemonSet simple exécutant un conteneur sur chaque nœud éligible :

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: example-daemonset
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: example
  template:
    metadata:
      labels:
        app.kubernetes.io/name: example
    spec:
      containers:
      - name: pause
        image: registry.k8s.io/pause

Les administrateurs peuvent enrichir le template de pod avec des options comme les resource requests, les montages de volumes, les tolerations, les node selectors et la node affinity. Ces paramètres déterminent comment les pods du DaemonSet s'exécutent et, lorsque des contraintes d'ordonnancement sont spécifiées, quels nœuds sont éligibles pour les héberger. La documentation Kubernetes fournit un exemple de base dans lequel le DaemonSet planifie un pod sur chaque nœud concerné.

2. Déployer un DaemonSet

Une fois le manifeste du DaemonSet créé, déployez-le dans le cluster avec kubectl apply. Si le manifeste est enregistré localement sous le nom daemonset.yaml, exécutez :

kubectl apply -f daemonset.yaml

Kubernetes montre également comment appliquer un DaemonSet directement depuis un manifeste YAML hébergé. Par exemple :

kubectl apply -f https://k8s.io/examples/application/basic-daemonset.yaml

La commande kubectl apply soumet la configuration à l'API Kubernetes, après quoi le contrôleur DaemonSet détermine les nœuds éligibles et crée les pods requis. Lorsque de nouveaux nœuds éligibles rejoignent le cluster, le contrôleur y crée automatiquement des pods DaemonSet. Les pods associés aux nœuds supprimés sont ensuite nettoyés par le garbage collector.

Après le déploiement, les modifications du DaemonSet se gèrent généralement en modifiant le manifeste puis en exécutant à nouveau kubectl apply. Pour les DaemonSets utilisant la stratégie RollingUpdate, toute modification du template de pod déclenche une mise à jour progressive des pods gérés. Kubernetes prend également en charge la stratégie OnDelete lorsque les administrateurs souhaitent que les pods de remplacement ne soient créés qu'après la suppression manuelle des pods existants.

3. Vérifier les pods du DaemonSet

Après avoir déployé un DaemonSet, vérifiez que ses pods s'exécutent sur les nœuds attendus. La documentation Kubernetes recommande de lister les pods avec l'option -o wide, qui affiche le nœud attribué à chaque pod :

kubectl get pods -o wide

Pour un DaemonSet destiné à s'exécuter sur l'ensemble du cluster, la sortie doit afficher un pod DaemonSet sur chaque nœud éligible. La colonne NODE permet de confirmer facilement que les pods sont distribués comme prévu.

Dans les environnements comptant de nombreux workloads, utilisez les labels définis dans le template de pod du DaemonSet pour filtrer les résultats. Pour l'exemple ci-dessus, la commande serait :

kubectl get pods -l app.kubernetes.io/name=example -o wide

Vous pouvez également inspecter la ressource DaemonSet elle-même avec :

kubectl get daemonset example-daemonset

ou utiliser le nom de ressource abrégé :

kubectl get ds example-daemonset

Le statut du DaemonSet aide les administrateurs à comparer le nombre de pods souhaité avec le nombre de pods à jour, prêts et disponibles. Si certains pods ne s'exécutent pas correctement, des commandes comme kubectl describe pod <pod-name> et kubectl logs <pod-name> permettent d'investiguer les problèmes d'ordonnancement ou de conteneur. Le tutoriel DaemonSet de base de Kubernetes vérifie le succès du déploiement en contrôlant que la liste des pods obtenue contient un pod pour chaque nœud concerné.

Bonnes pratiques pour les DaemonSets Kubernetes

1. Dimensionner correctement les requests et limits CPU et mémoire

Définir des requests et limits CPU et mémoire appropriées est essentiel pour la stabilité d'un DaemonSet. Les requests définissent les ressources minimales dont un pod a besoin, tandis que les limits fixent le maximum qu'il peut consommer. Un surdimensionnement gaspille des ressources et peut provoquer des échecs d'ordonnancement sur les nœuds aux ressources limitées. Un sous-dimensionnement expose à l'éviction des pods ou à une dégradation des performances. Analysez le profil de ressources du workload pour déterminer des valeurs par défaut raisonnables, en veillant à ce que chaque pod DaemonSet tienne aisément sur chaque nœud ciblé.

Révisez et ajustez régulièrement les paramètres de ressources à mesure que l'application évolue. Les besoins en ressources peuvent changer avec de nouvelles fonctionnalités, une charge accrue ou des évolutions de l'infrastructure sous-jacente. Dans les environnements Kubernetes dynamiques, un ajustement périodique des requests et limits prévient la contention des ressources et favorise une utilisation efficace du cluster. Intégrez ces revues de ressources à votre processus de gestion des changements pour une optimisation continue.

2. Baser les paramètres de ressources sur l'historique d'utilisation

Les resource requests doivent refléter le comportement réel des pods DaemonSet en production, et non reposer uniquement sur des estimations initiales. Exploitez l'historique des métriques CPU et mémoire issu d'outils comme Prometheus, Grafana ou votre plateforme de monitoring cloud pour identifier l'utilisation habituelle, les pics de demande et les écarts entre nœuds. Définissez des requests suffisamment élevées pour couvrir le fonctionnement normal tout en évitant de réserver inutilement des ressources sur chaque nœud ciblé.

Analysez des métriques basées sur des percentiles sur des périodes représentatives plutôt que des moyennes à court terme. Les requests CPU peuvent souvent être basées sur l'utilisation soutenue avec une marge pour les pics, tandis que les requests mémoire doivent tenir compte des pics observés. Comme l'empreinte de ressources des DaemonSets se multiplie sur tous les nœuds, même de petites améliorations par pod peuvent libérer une capacité significative du cluster.

3. Traiter la mémoire avec plus de prudence que le CPU

Les limits CPU et mémoire ont des modes de défaillance différents dans Kubernetes. Lorsqu'un conteneur atteint sa limite CPU, Kubernetes limite (throttle) sa consommation, ce qui ralentit généralement les traitements. En revanche, lorsqu'un conteneur dépasse sa limite mémoire, il peut être arrêté par le kernel avec une erreur out-of-memory (OOM). Pour les agents de niveau nœud, des redémarrages répétés peuvent créer des trous dans la couverture de logging, de monitoring ou de sécurité.

Définissez les requests et limits mémoire avec une marge suffisante pour les pics temporaires et la croissance du workload. Surveillez les pics de consommation mémoire et les événements OOM avant de réduire les allocations. Pour les agents aux besoins mémoire imprévisibles, une limite mémoire trop restrictive peut être plus pénalisante qu'un surdimensionnement modéré : validez donc les limits par rapport aux usages observés en production.

4. Utiliser la stratégie de mise à jour appropriée

Les DaemonSets prennent en charge les stratégies de mise à jour RollingUpdate et OnDelete. RollingUpdate, la stratégie par défaut, remplace automatiquement les pods existants lorsque le template de pod du DaemonSet change. Des paramètres comme maxUnavailable et maxSurge permettent de contrôler le nombre de pods DaemonSet indisponibles ou ajoutés temporairement pendant une mise à jour.

Utilisez OnDelete lorsque le remplacement des pods doit être contrôlé explicitement. Avec cette stratégie, la mise à jour du template de pod ne remplace pas automatiquement les pods existants ; les administrateurs doivent les supprimer pour que Kubernetes crée des pods à partir du nouveau template. Quelle que soit la stratégie choisie, évaluez l'impact de l'indisponibilité des agents sur la couverture de logging, de monitoring, de réseau ou de sécurité pendant les mises à jour.

5. Surveiller l'efficience en continu à mesure que le cluster évolue

La consommation de ressources d'un DaemonSet croît avec le nombre de nœuds éligibles. Un pod aux ressources modestes sur un seul nœud peut représenter une consommation agrégée importante de CPU et de mémoire dans un grand cluster. Suivez à la fois l'utilisation par pod et le total des ressources consommées par chaque DaemonSet pour comprendre son impact sur la capacité du cluster.

Réévaluez vos DaemonSets lorsque les types de nœuds, les workloads ou la taille du cluster changent. Soyez attentif aux resource requests inutilisées, au throttling CPU, à la pression mémoire, aux événements OOM, aux redémarrages et aux pods qui ne parviennent pas à être planifiés. Un monitoring continu permet d'identifier le moment où les paramètres de ressources ou les règles d'ordonnancement ne correspondent plus aux conditions réelles d'exploitation.

Optimiser l'utilisation des ressources des DaemonSets avec PerfectScale

Comme un DaemonSet place un pod sur chaque nœud éligible, le moindre sur- ou sous-dimensionnement se multiplie à l'échelle du cluster. PerfectScale by DoiT est une plateforme d'optimisation Kubernetes qui se déploie via une seule commande Helm, puis fournit des insights actionnables et une optimisation autonome sur l'ensemble de la stack K8s, afin que les agents de niveau nœud — collecteurs de logs, exporters de monitoring, daemons de sécurité — s'exécutent avec les ressources dont ils ont réellement besoin.

Fonctionnalités clés de PerfectScale :

• Right-sizing autonome des workloads : Podfit offre une vue granulaire de la santé et des coûts du cluster, priorise les zones nécessitant une attention particulière et optimise les workloads de manière autonome grâce à des recommandations de right-sizing basées sur les données, applicables automatiquement.
• Optimisation de l'utilisation des nœuds : Infrafit fournit une visibilité complète sur l'utilisation des nœuds et des insights granulaires qui identifient et éliminent la capacité inutilisée, tout en aidant à sélectionner les bons nœuds pour vos workloads.
• Alignement avec les autoscalers : fonctionne avec HPA, KEDA, Karpenter, Cluster Autoscaler, EKS Auto Mode, Fargate, Node Auto Provisioning et Google Autopilot, avec des recommandations actionnables pour améliorer leurs configurations.
• Alertes en temps réel avec priorisation : une auto-priorisation avancée met en avant les risques de résilience, les pics de coûts et les anomalies les plus critiques avant qu'ils n'affectent les utilisateurs ou la facture cloud, avec des alertes envoyées vers Slack, Datadog, MS Teams ou PagerDuty.
• Rapports de tendances et de gouvernance : le rapport Trends offre une visibilité approfondie sur les métriques de coûts, de gaspillage et de risques dans le temps, par cluster, groupe de nœuds, namespace et workload, au service de la prévision et de l'analyse des causes racines.
• Large compatibilité d'environnements : fonctionne sur les clusters on-premise et cloud, y compris OpenShift, EKS, GKE et AKS, et prend en charge les conteneurs Windows ainsi que les workloads éphémères et de ML.

En savoir plus sur la plateforme PerfectScale