fluent/fluentd-kubernetes-daemonset: prebuilt Fluentd images and DaemonSet manifests for cluster log collection
Fluentd daemonset for Kubernetes and it Docker image. This is because there were limitation about the number of automated builds on hub.docker.com.
At a glance
- What is it?
- The repository ships one Fluentd Docker image per output plugin plus matching DaemonSet YAML, so log shipping on Kubernetes is mostly a choice of tag and a mounted config file. The trade-off is that you inherit the image's plugin set and its release cadence.
- Who is it for?
- Adopt it when you want Fluentd running on every node with a maintained plugin set and can live with the tag naming: pick the output image (for example v1.19.3-debian-elasticsearch8-1.1), mount your own fluent.conf, and apply the matching YAML from the repository root. Do not adopt it if you need a destination that has no image in the current v1.19 line, or if you want the collector configured through a chart's values file rather than a ConfigMap you maintain.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 27 days ago.
- What is it written in?
- Mainly Ruby, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 26, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What the repository actually ships
This is not a Fluentd plugin and not a Helm chart. It is a packaging repository: a set of Dockerfiles under docker-image/ that each build Fluentd with one output plugin family preinstalled, plus a flat list of example DaemonSet manifests at the repository root, one per destination (fluentd-daemonset-elasticsearch.yaml, fluentd-daemonset-cloudwatch-rbac.yaml, fluentd-daemonset-kafka2.yaml, and so on). The audience is the platform team that has decided Fluentd is the node-level log collector and does not want to write a Dockerfile to get there. The README states the build process moved from automated builds on hub.docker.com to GitHub Actions at v1.17.0, because of limits on the number of automated builds. The practical consequence is that the tag list is now generated by CI, and the README itself is generated from templates/README.md.erb, which the file warns about at the top.
One image per output, and why that matters for upgrades
The image matrix is the design. There is a Debian image for azureblob, cloudwatch, datadog, elasticsearch7, elasticsearch8, elasticsearch9, forward, gcs, graylog, kafka, kafka2, kinesis, logentries, loggly, logzio, opensearch, papertrail, s3 and syslog, each published as a multi-arch tag and, for most of them, a separate amd64 tag. Tags carry both the Fluentd version and an image revision, so v1.19.3-debian-elasticsearch8-1.1 and v1.19-debian-elasticsearch8-1 are distinct pulls, the second being the moving minor line. That scheme is convenient until you need a plugin that is not in the image you picked: the README's answer is to build it yourself, and it notes the Dockerfile is still maintained even for images that are no longer published. The version suffix also means a Fluentd patch release forces a new tag rather than mutating an existing one, which is good for reproducibility and bad for anyone pinning a floating tag in production.
Installing and a first DaemonSet run
There is no package to install. You pull an image and apply a manifest. The README gives the pull command for the Elasticsearch 8 build:
docker pull fluent/fluentd-kubernetes-daemonset:v1.19.3-debian-elasticsearch8-1.1The README lists the manifests under the repository root, including fluentd-daemonset-elasticsearch.yaml and fluentd-daemonset-elasticsearch-rbac.yaml. Apply them with kubectl and then check the pods on the nodes. The pod should reach Running on each node, and the container log should show Fluentd starting its input and output plugins. If it restarts, read the container log before touching the manifest: the usual cause is a destination the node cannot reach, not a bad image.
The config file is yours to own
The images ship a default configuration, but the manifests mount a ConfigMap over it so the operator controls the routing. The README does not document the default fluent.conf contents in the excerpt available, and it does not document a rollback path for a config change. That is a real gap: a DaemonSet rollout with a broken configuration restarts the collector on every node at once, and the repository's manifests give you no canary mechanism of their own. Treat the ConfigMap as the risky artifact, version it outside the cluster, and test the parse locally with the same image before applying, since a syntax error in fluent.conf takes the pod down on every node simultaneously rather than degrading one replica.
Images that are no longer published
The README is explicit that some tags stopped shipping. From v1.16.5 and older, the papertrail and syslog images are no longer published for x86_64 or arm64, and the logentries, loggly, logzio and s3 arm64 images are no longer published at all, leaving x86_64 only. That is the clearest case where this repository is the wrong tool: if you run an arm64 node pool and your destination is S3, there is no published image to pull, and the README's instruction is to build it from the Dockerfile in docker-image/. The same applies to any destination not in the current matrix. Before committing to the repository, check the Docker Hub tags page it links to rather than trusting a tag you saw in a blog post.
Compared with the Fluentd Helm chart route
The alternative most teams weigh is deploying Fluentd through a Helm chart, where the collector configuration is expressed as chart values and the chart owns the DaemonSet, RBAC and ConfigMap together. The difference is where configuration lives. Here, the repository gives you a YAML file and an image tag, and you edit both: the manifest is a starting point you copy into your own tree, and the fluent.conf is a file you maintain. With a chart, upgrades arrive as a values diff and the templating handles the surrounding objects. Neither approach changes what Fluentd does; they change who owns the upgrade. Copying a manifest from this repository means you also copy the responsibility for tracking new Fluentd releases, whereas a chart moves that to the chart's release cycle.
Maintenance, licensing and upgrade cost
The repository is not archived, and the last push was on 2026-08-05, the same date as the v1.19.3-1.1 release, so releases and repository activity are moving together. The upgrade cost is dominated by the tag scheme: the v1.19 minor line and the v1.19.3 patch line are separate tags, so moving from v1.19.3-1.0 to v1.19.3-1.1 is an image bump you can schedule, while staying on v1.19-debian-elasticsearch8-1 means accepting whatever CI publishes next. The repository is Apache-2.0 licensed, and the images bundle Fluentd itself plus third-party output plugins, each under its own licence; if you redistribute a built image inside a product, check the plugin licences rather than relying on the repository's own LICENSE file.
Editorial conclusion
Adopt it when you want Fluentd running on every node with a maintained plugin set and can live with the tag naming: pick the output image (for example v1.19.3-debian-elasticsearch8-1.1), mount your own fluent.conf, and apply the matching YAML from the repository root. Do not adopt it if you need a destination that has no image in the current v1.19 line, or if you want the collector configured through a chart's values file rather than a ConfigMap you maintain. Before rollout, verify that the tag you chose still exists on Docker Hub, that the plugin version inside it matches your destination's API, and whether the DaemonSet manifest you copied sets the RBAC objects your cluster needs.
Frequently asked questions
What is Fluentd doing in Kubernetes when it runs as this DaemonSet?
It runs one Fluentd process per node as a DaemonSet, collecting container log files from that node and forwarding them to the destination baked into the image you chose. The repository supplies both the image and an example manifest for each destination.
What is a DaemonSet in Kubernetes, and why is it used here?
A DaemonSet schedules one pod per node, which matches log collection because each node's container logs live on that node's filesystem. That is why fluent/fluentd-kubernetes-daemonset ships DaemonSet manifests rather than a Deployment.
Can you give an example of a DaemonSet from this project?
The repository root contains files such as fluentd-daemonset-elasticsearch.yaml and fluentd-daemonset-cloudwatch-rbac.yaml, each pairing a DaemonSet with the environment variables and, in the rbac variants, the permissions its output plugin needs.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/fluent-fluentd-kubernetes-daemonset)
Community notes