Fluentd Kubernetes DaemonSet: Clusterweite Log-Sammlung
Fluentd-Daemonset für Kubernetes und sein Docker-Image. Dies liegt daran, dass die Anzahl der automatisierten Builds auf hub.docker.com begrenzt war.
Auf einen Blick
- Was ist das?
- Was das Repository fluent/fluentd-kubernetes-daemonset tatsächlich enthält: Debian-basierte Fluentd-Images für Kubernetes, wie ihre Tags aufgebaut sind und wo das README aufhört.
- Für wen ist es gedacht?
- Nutzer sollten Probleme über GitHub Issues melden, nicht über DockerHub-Kommentare, und Pull Requests sollten Vorlagendateien aktualisieren, da docker-image-Dateien generiert werden. Das README liefert keine Leistungszahlen, Sicherheitszusicherungen oder Produktionsergebnisse; diese müssen gegen eine echte Bereitstellung verifiziert werden.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 14 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Ruby, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 14. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Fluentd daemonset Images für Kubernetes
Dieses Repository stellt ein Fluentd daemonset für Kubernetes und das Docker-Image bereit, das das daemonset ausführt. Das README beginnt mit dem Hinweis, dass README.md selbst aus templates/README.md.erb generiert wird, Änderungen also an der Vorlagendatei vorgenommen werden sollten. Das Projekt ist in Ruby geschrieben, unter Apache-2.0 lizenziert und sein Standardzweig ist master. Zum Zeitpunkt der Repository-Metadaten hatte es 1.296 Sterne, 969 Forks und 17 offene Issues. Beim fluent/fluentd-kubernetes-daemonset ist der Kubernetes-Kontext der Prüfpunkt. Vergleiche DaemonSet, ConfigMap, Container-Logs und die angegebenen Fluentd-Parameter. Ein kleiner Namespace mit absichtlich fehlerhaften und gültigen Logzeilen zeigt, ob Sammlung, Pufferung und Weiterleitung wie erwartet zusammenspielen.
Image-Varianten und Tag-Konventionen
Das README listet unterstützte Tags für Debian-basierte Images in drei Gruppen auf: Multi-Arch, x86_64 und arm64. Jede Variante kombiniert eine Fluentd-Version mit einem Ziel-Plugin: azureblob, cloudwatch, datadog, elasticsearch7, elasticsearch8, elasticsearch9, forward, gcs, graylog, kafka, kafka2, kinesis, logentries, loggly, logzio, opensearch, papertrail, s3 und syslog. Tags sehen aus wie v1.19.3-debian-azureblob-1.1, und ein v1-debian-PLUGIN-Tag verweist auf das neueste v1-Image. Das README empfiehlt, in der Produktion strikte Tags zu verwenden, um unerwartete Updates zu vermeiden. Beim fluent/fluentd-kubernetes-daemonset ist der Kubernetes-Kontext der Prüfpunkt. Vergleiche DaemonSet, ConfigMap, Container-Logs und die angegebenen Fluentd-Parameter. Ein kleiner Namespace mit absichtlich fehlerhaften und gültigen Logzeilen zeigt, ob Sammlung, Pufferung und Weiterleitung wie erwartet zusammenspielen.
Build-Prozess zu GitHub Actions umgezogen
Seit v1.17.0 wurde der Build-Prozess für Container-Images von automatischen Builds auf hub.docker.com zu GitHub Actions migriert, weil hub.docker.com eine Begrenzung der Anzahl automatischer Builds hatte. Das README stellt fest, dass es jetzt keine Begrenzung der Build-Pipelines gibt. Es dokumentiert auch Einschränkungen für v1.16.5 und ältere Images: papertrail- und syslog-Images werden nicht mehr veröffentlicht, und logentries-, loggly-, logzio- und s3-arm64-Images werden nicht mehr veröffentlicht. Nutzer, die diese Images benötigen, können sie aus den gepflegten Dockerfiles selbst bauen. Beim fluent/fluentd-kubernetes-daemonset ist der Kubernetes-Kontext der Prüfpunkt. Vergleiche DaemonSet, ConfigMap, Container-Logs und die angegebenen Fluentd-Parameter. Ein kleiner Namespace mit absichtlich fehlerhaften und gültigen Logzeilen zeigt, ob Sammlung, Pufferung und Weiterleitung wie erwartet zusammenspielen.
Konfigurationsdateien und Umgebungsvariablen
Jedes Image enthält Standard-Konfigurationsdateien: fluent.conf für Zieleinstellungen, kubernetes.conf für k8s-spezifischen tail-Eingang und den kubernetes_metadata-Filter, tail_container_parse.conf für das Parsen von /var/log/containers/*.log, prometheus.conf für Monitoring und systemd.conf für systemd-journal. Nutzer können diese Dateien über ConfigMap überschreiben. Das README dokumentiert Umgebungsvariablen wie FLUENT_UID für v0.12-Images, FLUENT_CONTAINER_TAIL_PATH zum Ändern des Container-Log-Ordners, FLUENT_CONTAINER_TAIL_EXCLUDE_PATH seit v1.9.3 zum Ausschließen bestimmter Logs und FLUENT_POS_EXTRA_DIR für mehrere fluentd-Instanzen, die keine pos-Datei teilen sollen. Beim fluent/fluentd-kubernetes-daemonset ist der Kubernetes-Kontext der Prüfpunkt. Vergleiche DaemonSet, ConfigMap, Container-Logs und die angegebenen Fluentd-Parameter. Ein kleiner Namespace mit absichtlich fehlerhaften und gültigen Logzeilen zeigt, ob Sammlung, Pufferung und Weiterleitung wie erwartet zusammenspielen.
CRI-Parser und Log-Parsing
Standardmäßig verwenden diese Images den json-Parser für /var/log/containers/-Dateien, weil Docker JSON-formatierte Logs erzeugt. containerd und cri-o verwenden ein anderes Format, daher können Nutzer seit v1.12.0-xxx-1.1 tail_container_parse.conf über ConfigMap mit einem cri-Parser überschreiben. Das README zeigt ein Konfigurationsbeispiel mit @type cri und verlinkt für Details auf das fluent-plugin-parser-cri-Repository. Beim fluent/fluentd-kubernetes-daemonset ist der Kubernetes-Kontext der Prüfpunkt. Vergleiche DaemonSet, ConfigMap, Container-Logs und die angegebenen Fluentd-Parameter. Ein kleiner Namespace mit absichtlich fehlerhaften und gültigen Logzeilen zeigt, ob Sammlung, Pufferung und Weiterleitung wie erwartet zusammenspielen.
Speicherzuweiser, systemd und prometheus-Schalter
Seit v1.17.0-1.3 und v1.16.5-1.3 ist der jemalloc-Speicherzuweiser standardmäßig deaktiviert, weil die Kombination aus systemd-Plugin und jemalloc einen Absturzfehler verursachte, der als free(): invalid pointer gemeldet wurde. Nutzer, die das systemd-Plugin nicht verwenden, können jemalloc mit LD_PRELOAD=/usr/lib/libjemalloc.so.2 explizit aktivieren. Das README dokumentiert außerdem, FLUENTD_SYSTEMD_CONF auf disable zu setzen, um systemd-Warnungen zu unterdrücken, FLUENTD_PROMETHEUS_CONF auf disable zu setzen, um prometheus-Eingabe-Plugins abzuschalten, und für ältere elasticsearch-Images FLUENT_ELASTICSEARCH_SED_DISABLE auf true zu setzen, um sed-Ausführung beim Start mit schreibgeschützten Mounts zu vermeiden.
OpenShift, mehrere fluentd und Plattform-Hinweise
Für OpenShift mountet das daemonset /var/log mit dem Servicekonto fluentd und erfordert privilegierte Container; das README liefert eine oc-Befehlssequenz. Für mehrere fluentd-Instanzen, die an verschiedene Ziele senden, fügt FLUENT_POS_EXTRA_DIR ein zusätzliches Verzeichnis für pos-Dateien hinzu. Das README weist darauf hin, dass das kafka-Image keine Zookeeper-Parameter unterstützt, weil die Zookeeper-Gem auf Debian 10 nicht funktioniert, und empfiehlt debian-kafka2 statt debian-kafka, weil letzteres das veraltete out_kafka_buffered-Plugin verwendet. Windows-k8s-daemonset wird in diesem Repository nicht unterstützt; das README verlinkt stattdessen auf Community-Forks.
Redaktionelles Fazit
Nutzer sollten Probleme über GitHub Issues melden, nicht über DockerHub-Kommentare, und Pull Requests sollten Vorlagendateien aktualisieren, da docker-image-Dateien generiert werden. Das README liefert keine Leistungszahlen, Sicherheitszusicherungen oder Produktionsergebnisse; diese müssen gegen eine echte Bereitstellung verifiziert werden.
Community-Notizen