Fluentd daemonset pour Kubernetes : images, configuration et limites connues
Ensemble de démons Fluentd pour Kubernetes et son image Docker. En effet, le nombre de builds automatisés sur hub.docker.com était limité.
En bref
- De quoi s’agit-il ?
- Ce que contient réellement le dépôt fluent/fluentd-kubernetes-daemonset : les images Fluentd basées sur Debian publiées, l'organisation des tags et ce que le README ne dit pas.
- À qui s’adresse-t-il ?
- Les utilisateurs doivent signaler les problèmes via GitHub issues, pas via les commentaires DockerHub, et les pull requests doivent modifier les fichiers de modèles car les fichiers docker-image sont générés. Le README n'établit pas de chiffres de performance, de garanties de sécurité ni de résultats de production ; ces éléments doivent être vérifiés sur un déploiement réel.
- Puis-je l’utiliser commercialement ?
- Oui. Apache-2.0 est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 14 jours.
- En quel langage est-il écrit ?
- Principalement Ruby, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 14 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Images Fluentd daemonset pour Kubernetes
Ce dépôt fournit un daemonset Fluentd pour Kubernetes et l'image Docker exécutée par ce daemonset. Le README commence par un avertissement : README.md est généré à partir de templates/README.md.erb, les modifications doivent donc cibler le fichier de modèle. Le projet est écrit en Ruby, est sous licence Apache-2.0 et sa branche par défaut est master. Au moment des métadonnées du dépôt, il comptait 1 296 étoiles, 969 forks et 17 problèmes ouverts.
Variantes d'images et conventions de tags
Le README liste les tags pris en charge pour les images basées sur Debian en trois groupes : multi-arch, x86_64 et arm64. Chaque variante associe une version de Fluentd à un plugin de destination : azureblob, cloudwatch, datadog, elasticsearch7, elasticsearch8, elasticsearch9, forward, gcs, graylog, kafka, kafka2, kinesis, logentries, loggly, logzio, opensearch, papertrail, s3 et syslog. Les tags ressemblent à v1.19.3-debian-azureblob-1.1, et un tag v1-debian-PLUGIN désigne la dernière image v1. Le README conseille d'utiliser des tags stricts en production pour éviter les mises à jour inattendues.
Processus de build migré vers GitHub Actions
Depuis v1.17.0, le processus de build des images conteneur a été migré des builds automatisés sur hub.docker.com vers GitHub Actions, car hub.docker.com limitait le nombre de builds automatisés. Le README indique qu'il n'y a désormais plus de limite sur le nombre de pipelines de build. Il documente aussi des restrictions pour les images v1.16.5 et plus anciennes : les images papertrail et syslog ne seront plus publiées, et les images arm64 de logentries, loggly, logzio et s3 ne seront plus publiées. Les utilisateurs qui ont besoin de ces images peuvent les construire à partir des Dockerfiles maintenus.
Fichiers de configuration et variables d'environnement
Chaque image est livrée avec des fichiers de configuration par défaut : fluent.conf pour les paramètres de destination, kubernetes.conf pour l'entrée tail spécifique à k8s et le filtre kubernetes_metadata, tail_container_parse.conf pour l'analyse de /var/log/containers/*.log, prometheus.conf pour la surveillance et systemd.conf pour systemd-journal. Les utilisateurs peuvent remplacer ces fichiers via ConfigMap. Le README documente des variables d'environnement comme FLUENT_UID pour les images v0.12, FLUENT_CONTAINER_TAIL_PATH pour changer le dossier des journaux conteneur, FLUENT_CONTAINER_TAIL_EXCLUDE_PATH depuis v1.9.3 pour exclure certains journaux, et FLUENT_POS_EXTRA_DIR pour exécuter plusieurs instances fluentd sans partager le même fichier pos.
Analyseur CRI et analyse des journaux
Par défaut, ces images utilisent l'analyseur json pour les fichiers /var/log/containers/, car Docker génère des journaux au format JSON. containerd et cri-o utilisent un format différent, donc depuis v1.12.0-xxx-1.1 les utilisateurs peuvent remplacer tail_container_parse.conf par un analyseur cri via ConfigMap. Le README fournit un exemple de configuration avec @type cri et renvoie au dépôt fluent-plugin-parser-cri pour plus de détails.
Allocateur mémoire, systemd et interrupteurs prometheus
Depuis v1.17.0-1.3 et v1.16.5-1.3, l'allocateur mémoire jemalloc est désactivé par défaut, car la combinaison du plugin systemd et de jemalloc provoquait un bug de crash signalé comme free(): invalid pointer. Les utilisateurs qui n'utilisent pas le plugin systemd peuvent activer jemalloc avec LD_PRELOAD=/usr/lib/libjemalloc.so.2. Le README documente aussi le fait de définir FLUENTD_SYSTEMD_CONF sur disable pour supprimer les avertissements systemd, FLUENTD_PROMETHEUS_CONF sur disable pour désactiver les plugins d'entrée prometheus, et, pour les anciennes images elasticsearch, FLUENT_ELASTICSEARCH_SED_DISABLE sur true pour éviter l'exécution de sed au démarrage avec des montages en lecture seule.
Le modèle README.erb fait partie du dépôt
Le fichier README.md étant généré depuis templates/README.md.erb, la documentation locale et les images publiées doivent être lues ensemble. Ce détail évite de corriger une sortie générée sans modifier sa source. Les variantes de tags associent une version de Fluentd, une base Debian, une architecture et un plugin de destination ; chacune de ces dimensions peut changer le comportement du daemonset. Le tag strict conseillé pour la production est donc un élément de reproductibilité, pas une simple préférence de nommage.
Observer le daemonset dans son cluster
Un essai de fluent/fluentd-kubernetes-daemonset doit vérifier le montage des journaux de nœuds, les permissions, la consommation et la destination retenue, par exemple elasticsearch8 ou s3. Comparez le tag d'image dans le manifeste avec la variante publiée, puis inspectez les logs du pod lorsque le backend est indisponible. Le README décrit des images et des conventions, mais ne fournit pas une politique universelle de ressources, de tolérance ou de rotation des logs. Ces paramètres doivent rester explicites dans les manifests de votre cluster.
Conclusion éditoriale
Les utilisateurs doivent signaler les problèmes via GitHub issues, pas via les commentaires DockerHub, et les pull requests doivent modifier les fichiers de modèles car les fichiers docker-image sont générés. Le README n'établit pas de chiffres de performance, de garanties de sécurité ni de résultats de production ; ces éléments doivent être vérifiés sur un déploiement réel.
Notes de la communauté