Download Latest Version 6.8.0 source code.zip (1.8 MB)
Email in envelope

Get an email when there's a new version of Logging operator

Home / 6.8.0
Name Modified Size InfoDownloads / Week
Parent folder
6.8.0 source code.tar.gz 2026-08-11 1.3 MB
1 1 weekly downloads
6.8.0 source code.zip 2026-08-11 1.8 MB
1 1 weekly downloads
README.md 2026-08-11 13.6 kB
0
Totals: 3 Items   3.1 MB 2

What's Changed

New or updated images

component image
operator ghcr.io/kube-logging/logging-operator:6.8.0
axosyslog ghcr.io/axoflow/axosyslog:4.26.0
fluentd ghcr.io/kube-logging/logging-operator/fluentd:6.8.0-full
syslog-ng-reloader ghcr.io/kube-logging/logging-operator/syslog-ng-reloader:6.8.0
config-reloader ghcr.io/kube-logging/logging-operator/config-reloader:6.8.0
fluentd-drain-watch ghcr.io/kube-logging/logging-operator/fluentd-drain-watch:6.8.0
buffer-volume-metrics ghcr.io/kube-logging/logging-operator/node-exporter:6.8.0
axosyslog exporter ghcr.io/axoflow/axosyslog-metrics-exporter:0.0.16
custom-runner ghcr.io/kube-logging/custom-runner:v1.0.0
fluentd-version rubygems.org/gems/fluentd/versions/1.19.3
fluentbit-version ghcr.io/fluent/fluent-bit:5.1.0

Install with helm

:::bash
helm install logging-operator oci://ghcr.io/kube-logging/helm-charts/logging-operator --version=6.8.0

Breaking changes

A duplicate parser name stops Fluent Bit from starting

Fluent Bit 5.1.0 makes a duplicate parser name fatal where 5.0 logged a warning and carried on. A customParsers entry reusing a built-in name, such as json, docker, cri or kube-custom, now crash-loops the DaemonSet. The parser the operator generates itself does not collide. This is not in the Fluent Bit release notes; we found it while testing the bump.

Rename any colliding parser before upgrading, or pin the Fluent Bit image to 5.0.5.

Sidecar images older than custom-runner 1.0.0 no longer start

The config-reloader and buffer-metrics sidecars are now given an explicit -metrics-port, a flag custom-runner gained in 1.0.0. Go rejects flags it does not know, so an older runner exits with flag provided but not defined and the container crash-loops.

Move any configReloadImage or bufferVolumeMetricsImage pin to 6.8.0, or drop it and take the default.

A syslog-ng image with only repository set now resolves to the pinned tag

syslogNGImage and metricsExporterImage were defaulted as whole structs, so setting just repository, which is what you do to point at a registry mirror, left the tag empty and the image resolved to :latest. Each field is defaulted on its own now, so the same spec pulls the tag this release pins. If your mirror does not carry that tag, the pull fails.

Set tag explicitly if you were relying on :latest.

The syslog-ng metrics service overrides are applied

metricsService and bufferVolumeMetricsService have been on the CRD since syslog-ng support landed, but nothing read them. They are merged into the generated Services now, so a value set once and forgotten because it did nothing takes effect on upgrade.

Check both fields before upgrading.

Worth knowing

DB_Sync now reaches Fluent Bit. The operator wrote this setting as DB_Sync, which Fluent Bit does not recognise, so it was dropped from the generated config. It renders as DB.sync now and takes effect. The CRD field keeps its name and nothing needs editing, but the agent syncs its position database as configured rather than not at all.

The syslog-ng config-reloader reports readiness. It has a readiness probe on the runner's /readyz, which answers 503 naming the path when a configured file watch could not be registered, the state where the reloader keeps running while silently never reloading again. A pod that turns NotReady on upgrade was already failing to reload; the probe only makes it visible.

IPv6

enabledIPv6 produced Services the cluster could not accept, and listeners that did not match those Services. This release fixes three separate faults and changes what the flag does.

The operator now asks the API server which IP families it can allocate and names only those. A cluster without an IPv6 range no longer has its Services rejected. syslog-ng also binds its source for IPv6 under the same flag; previously only the Service changed, so an IPv6 primary address pointed at a listener that was still IPv4 only and log ingestion stopped.

Kubernetes does not allow the primary IP family of an existing Service to change. Upgrading therefore leaves an existing Service on its current primary family:

  • Upgrading with enabledIPv6: true: the fluentd or syslog-ng Service keeps its IPv4 primary and gains an IPv6 secondary. It is reachable over IPv6, but IPv4 stays first in ipFamilies, so Prometheus keeps scraping the IPv4 address.
  • To get an IPv6 primary: delete the Service and let the operator recreate it. bash kubectl delete svc -n <control-namespace> <logging-name>-fluentd Expect a brief interruption. The Service comes back with a new cluster IP.
  • New installs get an IPv6 primary where the cluster has an IPv6 range.

metrics.bind is a new field on the metrics type. It sets the listen address directly, which is the supported way to get IPv6 metrics without forcing an IPv6 primary on the Service. The syslog-ng metrics exporter has no listen address option, so it ignores the field.

Metrics

The syslog-ng config-reloader served its metrics on the runner's own default port while the Service, the container port and the ServiceMonitor all named 9533, so nothing was ever scraped. It listens on 9533 now.

sidecar_reloader_* series therefore appear for syslog-ng where there were none. A panel or alert that has only ever seen an empty target starts receiving data, in particular sidecar_reloader_config_reloader_last_reload_error.

Enhancements

Dependency and image updates

Bug fixes

New Contributors

Full Changelog: https://github.com/kube-logging/logging-operator/compare/6.7.0...6.8.0

Source: README.md, updated 2026-08-11