kube-logging/logging-operator for Kubernetes logging pipelines

What Logging operator manages in a Kubernetes cluster

Logging operator addresses the operational gap between collecting Kubernetes container logs and sending them to a destination that can store or index them. It automates deployment and configuration of a logging pipeline rather than requiring administrators to maintain a collector DaemonSet, a forwarder deployment, and routing rules as separate pieces of infrastructure. The intended users are Kubernetes platform engineers and application teams that need logging configuration to be represented alongside application manifests.

The README says that the collector is a Fluent Bit DaemonSet deployed on every node. Fluent Bit reads container and application logs from the node filesystem, then queries the Kubernetes API to attach pod metadata. A separate log forwarder receives the records. Logging operator supports Fluentd and syslog-ng as forwarders, and the documentation explicitly says that the best choice depends on the logging requirements.

This is not a general-purpose log search interface. The project configures the collection and forwarding path, while destinations such as Elasticsearch, Amazon S3, GCS, and Loki are represented as outputs in the supported logging configuration. Storage retention, indexing, querying, and dashboard behavior therefore belong to the selected destination, not to the operator itself.

From node files to filtered outputs

The documented data path has three distinct stages. First, Fluent Bit runs as a node-level collector and obtains logs from the node file system. Second, it queries Kubernetes and enriches records with metadata about pods. Third, the forwarder applies filters and transformations before sending records to one or more outputs.

The operator also handles the Kubernetes configuration around that path. The `Logging` resource defines the logging infrastructure, including collectors and forwarders, and contains configuration for Fluent Bit, Fluentd, and syslog-ng. Fluent Bit is therefore not interchangeable with the forwarder in the README's architecture. It is the endpoint collector, while Fluentd or syslog-ng performs the forwarder role.

The flow model is the main routing boundary. A Fluentd `Flow` selects log messages, applies filters, and sends the selected messages to outputs. A `ClusterFlow` is the cluster-wide counterpart and collects logs from all namespaces by default. syslog-ng has corresponding `SyslogNGFlow` and `SyslogNGClusterFlow` resources tailored to syslog-ng features. Outputs are also separated into namespaced and cluster-wide resources. This model supports multiple flows and multiple outputs, including sending the same stored log data to more than one destination.

The README states that communication uses authenticated and encrypted channels and lists TLS as a feature. Configuration validation is also listed as a supported feature. Those statements address transport and configuration checks, but the README does not provide a detailed explanation of certificate issuance, rotation, or failure recovery, so those operational details need verification in the project documentation.

Namespace boundaries and cluster-wide resource evaluation

Namespace isolation is one of the main reasons to use Kubernetes custom resources for logging configuration. Namespaced `Output` and `Flow` resources can represent application or team ownership, while cluster-wide resources provide shared destinations and routing. The distinction also matters when multiple logging systems run in the same cluster, which the README lists as supported.

The control-plane boundary is explicit for `ClusterOutput` and `ClusterFlow`. The operator evaluates them in the `controlNamespace` only unless `allowClusterResourcesFromAllNamespaces` is set to true. This setting changes where cluster-wide resources are evaluated, so it should be treated as a permission and configuration decision rather than a convenience switch. The README does not claim that namespace isolation alone prevents a namespaced flow from referencing every output, so an adopter should inspect the detailed CRD documentation and admission policy for the intended trust model.

The resources are tied to forwarder type. Fluentd uses `Output`, `Flow`, `ClusterOutput`, and `ClusterFlow`; syslog-ng uses the `SyslogNG...` variants. A configuration written for one forwarder should not be assumed to work unchanged with the other. That is a concrete maintenance cost for teams supporting both systems or changing forwarders later.

Installation sources and the first real use

The README directs users to the project's documentation website for detailed CRD configuration, but it does not provide an installation command, Helm installation command, kubectl apply command, or a complete first-use manifest. Consequently, there is no safe shell or YAML example to reproduce without inventing flags or resource fields. The repository includes a `Dockerfile`, a `Makefile`, `charts/`, `config/`, and controller source directories, which indicates that container image builds, generated configuration, and Helm charts are part of the project layout.

A first real use should begin by selecting the forwarder, then mapping the intended destinations to the matching output resources, and then defining a namespaced flow for the workload whose records should be routed. The relevant CRD pages are `Logging`, `Output`, `Flow`, `ClusterOutput`, and `ClusterFlow` for Fluentd, with separate syslog-ng pages for its resource variants. After installation, the first verification point is whether the `Logging` resource results in a Fluent Bit DaemonSet on every node and whether the configured forwarder is reachable over the operator's authenticated, encrypted transport.

The repository's Dockerfile builds the manager from Go 1.27.1 Alpine tooling and produces a distroless container whose entrypoint is `/manager`. The Makefile also exposes image names such as `OPERATOR_IMG ?= controller:local`, but the repository files do not document a complete operator installation workflow from those targets. Follow the project's documented installation path rather than treating the image build details as a deployment procedure.

Operational limits and failure boundaries

The first limitation is architectural. Logging operator depends on a node filesystem collector, Kubernetes API metadata, a forwarder, and one or more external outputs. A failure in any component can interrupt the path. The README does not document retry behavior, backpressure, delivery guarantees, duplicate handling, or what happens when an output becomes unavailable. Teams that need those guarantees must verify them before treating the pipeline as an audit or incident-response record.

The second limitation is transformation compatibility. Fluent Bit collects and enriches records, but the forwarder determines much of the filtering and transformation behavior. Fluentd and syslog-ng have separate CRDs because their feature sets differ. Choosing a forwarder based only on operational familiarity can make later routing requirements harder to express.

The third limitation concerns cluster-wide authority. Enabling `allowClusterResourcesFromAllNamespaces` broadens where `ClusterOutput` and `ClusterFlow` resources are evaluated. The README does not document a rollback workflow, a failed-configuration recovery procedure, or an in-place migration path between Fluentd and syslog-ng. Those gaps matter for production adoption, where an operator upgrade can affect logging for many workloads at once.

Logging operator compared with a direct collector setup

A direct Kubernetes logging setup usually leaves the team to assemble and coordinate the collector DaemonSet, forwarder configuration, routing rules, and output definitions independently. Logging operator takes a different approach: it uses Kubernetes custom resources and a controller to manage the collectors, forwarders, and routes as infrastructure objects. The value is declarative coordination across many workloads, not merely the presence of Fluent Bit.

The trade-off is dependency on operator-managed resources and their configuration model. A direct setup can be simpler when there is one cluster, one output, and a stable routing rule. Logging operator becomes more relevant when namespace isolation, multiple outputs, multiple flows, multiple logging systems, or application-owned logging configuration are requirements. It is also the wrong choice for a non-Kubernetes environment because its stated problem and resources are specifically tied to Kubernetes nodes and the Kubernetes API.

The project uses Go 1.27.0 in `go.mod`, with controller-runtime and Kubernetes libraries declared as dependencies. Its Dockerfile builds a CGO-disabled manager binary and packages it in a distroless image. This confirms the controller's implementation and packaging model, but it does not establish deployment performance or upgrade compatibility. Review the relevant release notes and configuration changes for version 6.9.0, 6.8.0, or 6.7.0 before selecting an upgrade path.

License, releases, and maintenance cost

The repository identifies Apache-2.0 as its license. That permits use and modification under the license's terms, subject to its conditions, but this review does not provide legal advice. Organizations should review `LICENSE`, `NOTICE`, and their own compliance requirements before redistribution or deployment.

The repository is not archived, and the last push was on 2026-10-16. Recent releases include 6.9.0 on 2026-09-17, 6.8.0 on 2026-08-11, and 6.7.0 on 2026-06-16. These facts indicate recent repository activity, but they do not by themselves describe the compatibility policy or the effort required for an upgrade. The release history still leaves a platform team responsible for checking changes to CRDs, controller behavior, collector configuration, and forwarder integrations.

The upgrade cost is likely to be configuration-sensitive rather than limited to replacing one container image. Fluentd and syslog-ng resources are distinct, and changing a forwarder can require rewriting flows and outputs. Teams should preserve the existing `Logging` resource and matching output and flow definitions when reviewing a release, then validate them against the target cluster's Kubernetes version and logging requirements.

Editorial conclusion

Adopt kube-logging/logging-operator when a Kubernetes platform team wants declarative control over node log collection, enrichment, filtering, and multiple destinations. Do not choose it for a cluster that only needs the node filesystem log file, or when the team cannot maintain a controller, CRDs, TLS-enabled connections, and separate Fluentd or syslog-ng configuration. Verify first which forwarder fits the required transformations, whether cluster-wide resources are restricted to `controlNamespace`, and how outputs will be isolated between namespaces. The project is licensed under Apache-2.0, its repository is not archived, and its last push was on 2026-10-16.

Frequently asked questions

Official sources

1. kube-logging/logging-operator on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases