Kubernetes DaemonSet: Tutorial, Use Cases und Best Practices

Kubernetes-DaemonSet-Tutorial

Dieses Tutorial erklärt, wie Sie ein DaemonSet erstellen und damit arbeiten. Es basiert auf der Kubernetes-Dokumentation.

1. Ein Kubernetes DaemonSet erstellen

Um ein Kubernetes DaemonSet zu erstellen, definieren Sie es in einem YAML-Manifest mit apiVersion: apps/v1 und kind: DaemonSet. Das Manifest muss Standard-Kubernetes-Felder wie metadata und spec enthalten sowie ein Pod-Template unter .spec.template. Der .spec.selector des DaemonSets muss mit den Labels des Pod-Templates übereinstimmen; nach der Erstellung des DaemonSets kann dieser Selektor nicht mehr geändert werden. Kubernetes verlangt außerdem, dass die Restart-Policy des Pods auf Always gesetzt ist – entweder explizit oder über die Standardeinstellung.

Das folgende Manifest erstellt beispielsweise ein einfaches DaemonSet, das auf jedem passenden Node einen Container ausführt:

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

Administratoren können das Pod-Template um Optionen wie Resource Requests, Volume Mounts, Tolerations, Node-Selektoren und Node Affinity erweitern. Diese Einstellungen bestimmen, wie die DaemonSet-Pods laufen und – sofern Scheduling-Einschränkungen definiert sind – welche Nodes als Host infrage kommen. Die Kubernetes-Dokumentation zeigt ein einfaches Beispiel, in dem das DaemonSet auf jedem passenden Node einen Pod einplant.

2. Ein DaemonSet bereitstellen

Sobald das DaemonSet-Manifest erstellt ist, stellen Sie es mit kubectl apply im Cluster bereit. Ist das Manifest lokal als daemonset.yaml gespeichert, führen Sie aus:

kubectl apply -f daemonset.yaml

Die Kubernetes-Dokumentation zeigt auch, wie sich ein DaemonSet direkt aus einem gehosteten YAML-Manifest anwenden lässt. Zum Beispiel:

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

Der Befehl kubectl apply übermittelt die Konfiguration an die Kubernetes-API. Anschließend ermittelt der DaemonSet-Controller die passenden Nodes und erstellt die erforderlichen Pods. Treten weitere passende Nodes dem Cluster bei, erstellt der Controller automatisch DaemonSet-Pods für sie. Pods entfernter Nodes werden anschließend per Garbage Collection bereinigt.

Nach der Bereitstellung lassen sich Änderungen am DaemonSet in der Regel verwalten, indem Sie das Manifest anpassen und erneut kubectl apply ausführen. Bei DaemonSets mit der Strategie RollingUpdate lösen Änderungen am Pod-Template ein Rolling Update der verwalteten Pods aus. Kubernetes unterstützt außerdem die Update-Strategie OnDelete, wenn Ersatz-Pods erst erstellt werden sollen, nachdem die vorhandenen manuell gelöscht wurden.

3. DaemonSet-Pods überprüfen

Prüfen Sie nach der Bereitstellung eines DaemonSets, ob seine Pods auf den erwarteten Nodes laufen. Die Kubernetes-Dokumentation empfiehlt, Pods mit der Option -o wide aufzulisten, die den jedem Pod zugewiesenen Node mit ausgibt:

kubectl get pods -o wide

Bei einem DaemonSet, das im gesamten Cluster laufen soll, sollte die Ausgabe auf jedem passenden Node einen DaemonSet-Pod zeigen. Anhand der Spalte NODE lässt sich leicht bestätigen, dass die Pods wie erwartet verteilt sind.

In Umgebungen mit vielen Workloads können Sie die Ergebnisse über die im Pod-Template des DaemonSets definierten Labels einschränken. Für das obige Beispiel lautet der Befehl:

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

Sie können auch die DaemonSet-Ressource selbst inspizieren:

kubectl get daemonset example-daemonset

oder den abgekürzten Ressourcennamen verwenden:

kubectl get ds example-daemonset

Der DaemonSet-Status hilft Administratoren, die gewünschte Anzahl an Pods mit der Anzahl der aktuellen, einsatzbereiten und verfügbaren Pods zu vergleichen. Laufen einzelne Pods nicht korrekt, lassen sich mit Befehlen wie kubectl describe pod <pod-name> und kubectl logs <pod-name> Scheduling- oder Container-Probleme untersuchen. Das grundlegende DaemonSet-Tutorial von Kubernetes verifiziert eine erfolgreiche Bereitstellung, indem es prüft, ob die resultierende Pod-Liste für jeden passenden Node genau einen Pod enthält.

Best Practices für Kubernetes DaemonSets

1. CPU- und Memory-Requests und -Limits richtig dimensionieren

Passende CPU- und Memory-Requests und -Limits sind entscheidend für die Stabilität eines DaemonSets. Requests definieren die Mindestressourcen, die ein Pod benötigt, während Limits das Maximum festlegen, das er verbrauchen darf. Überdimensionierung verschwendet Ressourcen und kann auf Nodes mit knappen Ressourcen zu Scheduling-Fehlern führen. Unterdimensionierung riskiert Pod-Evictions oder Leistungseinbußen. Analysieren Sie das Ressourcenprofil des Workloads, um sinnvolle Standardwerte zu bestimmen, sodass jeder DaemonSet-Pod problemlos auf jeden anvisierten Node passt.

Überprüfen und justieren Sie die Ressourceneinstellungen regelmäßig, wenn sich die Anwendung weiterentwickelt. Der Ressourcenbedarf kann sich durch neue Features, höhere Last oder Änderungen an der zugrunde liegenden Infrastruktur verändern. In dynamischen Kubernetes-Umgebungen verhindert das regelmäßige Feintuning von Requests und Limits Ressourcenkonflikte und unterstützt eine effiziente Cluster-Auslastung. Integrieren Sie Ressourcen-Reviews in Ihr Change-Management, um kontinuierlich zu optimieren.

2. Ressourceneinstellungen auf historische Nutzungsdaten stützen

Resource Requests sollten widerspiegeln, wie sich DaemonSet-Pods unter realen Workloads verhalten, statt sich nur auf erste Schätzungen zu verlassen. Nutzen Sie historische CPU- und Memory-Metriken aus Tools wie Prometheus, Grafana oder Ihrer Cloud-Monitoring-Plattform, um typische Nutzung, Lastspitzen und Unterschiede zwischen Nodes zu erkennen. Setzen Sie Requests hoch genug für den Normalbetrieb, ohne auf jedem anvisierten Node unnötig Ressourcen zu reservieren.

Betrachten Sie perzentilbasierte Metriken über repräsentative Zeiträume statt kurzfristiger Durchschnittswerte. CPU-Requests lassen sich oft an der dauerhaften Nutzung mit Spielraum für Lastspitzen ausrichten, während Memory-Requests die beobachteten Spitzen berücksichtigen sollten. Da sich der Ressourcen-Fußabdruck eines DaemonSets über alle Nodes vervielfacht, können schon kleine Verbesserungen an den Pro-Pod-Einstellungen erhebliche Cluster-Kapazität freisetzen.

3. Memory konservativer behandeln als CPU

CPU- und Memory-Limits haben in Kubernetes unterschiedliche Fehlerbilder. Erreicht ein Container sein CPU-Limit, drosselt Kubernetes seine CPU-Nutzung, was in der Regel zu langsamerer Verarbeitung führt. Überschreitet ein Container jedoch sein Memory-Limit, kann er vom Kernel mit einem Out-of-Memory-Fehler (OOM) beendet werden. Bei Node-Level-Agents können wiederholte Neustarts Lücken in der Logging-, Monitoring- oder Security-Abdeckung verursachen.

Setzen Sie Memory-Requests und -Limits mit genügend Puffer für temporäre Spitzen und wachsende Workloads. Beobachten Sie Memory-Spitzenwerte und OOM-Ereignisse, bevor Sie Zuweisungen reduzieren. Bei Agents mit unvorhersehbarem Memory-Bedarf kann ein restriktives Memory-Limit mehr Störungen verursachen als eine moderate Überdimensionierung – validieren Sie Limits daher anhand realer Nutzungsmuster in der Produktion.

4. Die passende Update-Strategie wählen

DaemonSets unterstützen die Update-Strategien RollingUpdate und OnDelete. RollingUpdate, die Standardstrategie, ersetzt vorhandene Pods automatisch, wenn sich das Pod-Template des DaemonSets ändert. Mit Einstellungen wie maxUnavailable und maxSurge lässt sich steuern, wie viele DaemonSet-Pods während eines Updates nicht verfügbar sind oder temporär hinzugefügt werden.

Verwenden Sie OnDelete, wenn der Pod-Austausch explizit kontrolliert werden muss. Bei dieser Strategie ersetzt eine Änderung am Pod-Template vorhandene Pods nicht automatisch; Administratoren müssen sie löschen, bevor Kubernetes Pods aus dem neuen Template erstellt. Unabhängig von der gewählten Strategie sollten Sie bedenken, wie sich nicht verfügbare Agents während eines Updates auf Logging, Monitoring, Netzwerk oder Security-Abdeckung auswirken.

5. Effizienz bei Cluster-Änderungen kontinuierlich überwachen

Der Ressourcenverbrauch eines DaemonSets wächst mit der Zahl der passenden Nodes. Ein Pod, der auf einem einzelnen Node nur moderate Ressourcen nutzt, kann in einem großen Cluster in Summe erheblichen CPU- und Memory-Verbrauch verursachen. Verfolgen Sie sowohl die Nutzung pro Pod als auch die Gesamtressourcen jedes DaemonSets, um dessen Auswirkungen auf die Cluster-Kapazität zu verstehen.

Bewerten Sie DaemonSets neu, wenn sich Node-Typen, Workloads oder die Clustergröße ändern. Achten Sie auf ungenutzte Resource Requests, CPU-Throttling, Memory Pressure, OOM-Ereignisse, Neustarts und Pods, die sich nicht einplanen lassen. Kontinuierliches Monitoring hilft zu erkennen, wann Ressourceneinstellungen oder Scheduling-Regeln nicht mehr zu den tatsächlichen Betriebsbedingungen passen.

DaemonSet-Ressourcennutzung mit PerfectScale optimieren

Da ein DaemonSet auf jedem passenden Node einen Pod platziert, vervielfacht sich selbst eine geringe Über- oder Unterdimensionierung über das gesamte Cluster. PerfectScale by DoiT ist eine Kubernetes-Optimierungsplattform, die sich mit einem einzigen Helm-Befehl bereitstellen lässt und anschließend umsetzbare Erkenntnisse und autonome Optimierung über den gesamten K8s-Stack liefert – damit Node-Level-Agents wie Log-Collectors, Monitoring-Exporter und Security-Daemons mit genau den Ressourcen laufen, die sie tatsächlich benötigen.

Zentrale Funktionen von PerfectScale:

• Autonomes Workload-Right-Sizing: Podfit bietet einen granularen Blick auf Zustand und Kosten des Clusters, priorisiert die Bereiche mit Handlungsbedarf und optimiert Workloads autonom – mit datenbasierten Right-Sizing-Empfehlungen, die sich automatisch anwenden lassen.
• Optimierung der Node-Auslastung: Infrafit bietet umfassende Transparenz über die Node-Auslastung und granulare Einblicke, die ungenutzte Node-Kapazitäten identifizieren und beseitigen, und hilft bei der Auswahl der richtigen Nodes für Ihre Workloads.
• Abstimmung mit Autoscalern: Arbeitet mit HPA, KEDA, Karpenter, Cluster Autoscaler, EKS Auto Mode, Fargate, Node Auto Provisioning und Google Autopilot zusammen – inklusive umsetzbarer Empfehlungen zur Verbesserung der jeweiligen Konfiguration.
• Echtzeit-Alerts mit Priorisierung: Fortschrittliche Auto-Priorisierung macht die folgenreichsten Resilienzrisiken, Kostenspitzen und Anomalien sichtbar, bevor sie Nutzer oder die Cloud-Rechnung treffen – mit Alerts in Slack, Datadog, MS Teams oder PagerDuty.
• Trend- und Governance-Reporting: Der Trends-Report bietet detaillierte Einblicke in Kosten-, Waste- und Risikometriken im Zeitverlauf – über Cluster, Node-Gruppen, Namespaces und Workloads hinweg – und unterstützt Prognosen sowie Root-Cause-Analysen.
• Breite Umgebungsunterstützung: Läuft auf On-Premise- und Cloud-Clustern, darunter OpenShift, EKS, GKE und AKS, und unterstützt Windows-basierte Container ebenso wie ephemere und ML-Workloads.

Mehr über die PerfectScale-Plattform erfahren