fluent-operator

What is fluent-operator?

The fluent-operator image provides a Kubernetes controller that manages the full lifecycle of Fluent Bit and Fluentd within a cluster. Previously known as FluentBit Operator, it was donated to the Fluent community and extended to support both tools under a single operator.

Fluent Bit runs as a DaemonSet on every node to collect and lightly process container and system logs. Fluentd runs as a StatefulSet to receive those logs over the network and apply heavier transformations, routing, and aggregation before forwarding to destinations like Elasticsearch, Kafka, S3, or Loki. The operator manages both through CRDs — meaning log pipeline configuration is version-controlled and applied declaratively, without restarting agents.

It's commonly used in platform engineering and DevOps teams that need centralized, policy-driven log management across multi-tenant Kubernetes clusters, air-gapped environments, or regulated industries.

How to use this image

The fluent-operator is deployed as a Kubernetes controller via Helm. It watches CRDs to manage Fluent Bit DaemonSets and Fluentd StatefulSets as first-class Kubernetes resources.

Install via Helm:

helm repo add fluent https://fluent.github.io/helm-charts
helm install fluent-operator fluent/fluent-operator \
  --namespace fluent --create-namespace \
  --set containerRuntime=containerd
Define a Fluent Bit instance and cluster-wide log pipeline:
apiVersion: fluentbit.fluent.io/v1alpha2
kind: FluentBit
metadata:
  name: fluent-bit
  namespace: fluent
spec:
  image: ghcr.io/fluent/fluent-operator/fluent-bit:latest
  fluentBitConfigName: fluent-bit-config
---
apiVersion: fluentbit.fluent.io/v1alpha2
kind: ClusterOutput
metadata:
  name: es-output
  labels:
    fluentbit.fluent.io/enabled: "true"
spec:
  matchRegex: (?:kube|service)\.(.*)
  es:
    host: elasticsearch.logging.svc
    port: 9200
    logstashFormat: true

After applying these manifests, the operator provisions the Fluent Bit DaemonSet across all nodes, generates the pipeline configuration into a Secret, and dynamically reloads it without restarting pods. Logs from the operator itself are written to stdout and can be collected via any standard Kubernetes logging system.

Image variants

Published under ghcr.io/fluent/fluent-operator, the operator ships several images that work together:

• fluent-operator:latest / fluent-operator:<version> — The operator controller image itself. Watches CRDs and manages Fluent Bit and Fluentd deployments. This is the primary image deployed by the Helm chart.
• fluent-bit:<version> — A custom Fluent Bit image maintained by the fluent-operator project, required for dynamic configuration reloading. Not a drop-in replacement for the upstream fluent/fluent-bit image.
• fluent-operator:latest-amd64 / fluent-operator:latest-arm64 — Architecture-specific variants for multi-arch clusters.

All component images are versioned together and should be kept in sync. Production deployments should pin to explicit version tags and validate upgrades in a staging environment, as new operator releases may introduce CRD schema changes.