kube-logging-operator-fluentd-drain-watch-fips

packaged by Chainguard

Chainguard Container for kube-logging-operator-fluentd-drain-watch-fips

Minimal Logging operator for Kubernetes

Chainguard Containers are regularly-updated, secure-by-default container images.

Download this Container Image

For those with access, this container image is available on cgr.dev:

docker pull cgr.dev/ORGANIZATION/kube-logging-operator-fluentd-drain-watch-fips:latest

Be sure to replace the ORGANIZATION placeholder with the name used for your organization's private repository within the Chainguard Registry.

Compatibility Notes

The logging-operator project publishes several container images from a single repository. Chainguard builds a FIPS variant of each of them, and every one is a drop-in replacement for its upstream counterpart, with the same entrypoint, arguments, and environment variables:

kube-logging-operator-fips is also a drop-in replacement for the older banzaicloud/logging-operator image.

The same project also publishes the Fluentd image and the buffer volume metrics sidecar, which Chainguard ships as kube-logging-operator-fluentd-fips and kube-logging-operator-node-exporter-fips. The Getting Started example below references the Fluentd one.

All three run as the nonroot user 65532, where the upstream images run as root. This does not affect the drainer, because the operator applies its own pod security context to that job.

The operator and the config reloader are Go binaries built against the FIPS-validated OpenSSL provider. kube-logging-operator-fluentd-drain-watch-fips is a POSIX shell script rather than a compiled binary, and it reaches Fluentd over the loopback interface in plain HTTP, so it performs no cryptography of its own. It still ships the FIPS-hardened OpenSSL configuration so that curl, and anything else you layer on top of the image, resolves to the validated provider.

FIPS Support

The kube-logging-operator-fips container image ships with a validated redistribution of OpenSSL's FIPS provider module. For more on FIPS support in Chainguard Containers, consult the guide on FIPS-enabled Chainguard Containers on Chainguard Academy.

Getting Started

The operator watches Logging, Flow, and Output custom resources and reconciles them into a Fluent Bit and Fluentd log collection pipeline. The supported way to install it is the official Helm chart.

Write a values file that points each component of the pipeline at a FIPS container image:

cat > values.yaml <<EOF
image:
  repository: cgr.dev/ORGANIZATION/kube-logging-operator-fips
  tag: latest

logging:
  enabled: true
  fluentd:
    image:
      repository: cgr.dev/ORGANIZATION/kube-logging-operator-fluentd-fips
      tag: latest
    configReloaderImage:
      repository: cgr.dev/ORGANIZATION/kube-logging-operator-config-reloader-fips
      tag: latest
    scaling:
      replicas: 2
      drain:
        enabled: true
        image:
          repository: cgr.dev/ORGANIZATION/kube-logging-operator-fluentd-drain-watch-fips
          tag: latest
EOF

Be sure to replace the ORGANIZATION placeholder with the name used for your organization's private repository within the Chainguard Registry.

Install the chart with that values file:

helm install logging-operator oci://ghcr.io/kube-logging/helm-charts/logging-operator \
  --namespace logging-operator --create-namespace \
  --values values.yaml

Confirm that the operator has reconciled the pipeline:

kubectl get pods -n logging-operator

Configuration

The scaling.drain block above is what puts kube-logging-operator-fluentd-drain-watch-fips to work. When you reduce the Fluentd replica count, the operator leaves the removed replica's buffer volume behind and starts a drainer job that pairs a Fluentd container with a drain-watch container sharing that volume. drain-watch waits for Fluentd's RPC endpoint, watches the buffer directory, and calls killWorkers only once the last *.buffer file has been flushed, so scaling down does not drop buffered log records.

The container reads its configuration entirely from the environment:

When the operator builds the drainer job it sets BUFFER_PATH and CHECK_INTERVAL itself and leaves the rest at their defaults, so under Helm these are behavioral documentation rather than knobs. They matter when you run the container yourself, which is also the quickest way to see how it behaves. With nothing listening on the RPC address, it parks in its first loop and reports why:

docker run -d --name drain-watch -e BUFFER_PATH=/tmp cgr.dev/ORGANIZATION/kube-logging-operator-fluentd-drain-watch-fips:latest
docker logs drain-watch

[Mon Aug 24 09:42:43 UTC 2026] waiting for fluentd RPC endpoint to become available
[Mon Aug 24 09:42:43 UTC 2026] fluentd RPC endpoint not available, waiting
[Mon Aug 24 09:42:44 UTC 2026] fluentd RPC endpoint not available, waiting

It waits indefinitely, because in the drainer job Fluentd is expected to appear alongside it. Stop it when you are done:

docker stop drain-watch

KILL_TIMEOUT is the one worth understanding before a large scale-down. After drain-watch calls killWorkers, Fluentd finishes flushing in-flight chunks before it closes the RPC endpoint. If that takes longer than the timeout, drain-watch exits non-zero, the drainer job fails, and the buffer volume is left undrained rather than silently discarded.

Draining requires persistent buffer volumes. If disablePvc is set on the Fluentd spec, the operator logs that draining cannot be enabled and skips it.

Documentation and Resources

• Logging operator documentation
• Scaling the logging operator
• Fluentd custom resource reference
• FIPS-enabled Chainguard Containers
• Chainguard Academy

What are Chainguard Containers?

Chainguard's free tier of Starter container images are built with Wolfi, our minimal Linux undistro.

All other Chainguard Containers are built with Chainguard OS, Chainguard's minimal Linux operating system designed to produce container images that meet the requirements of a more secure software supply chain.

The main features of Chainguard Containers include:

• Minimal design, without unnecessary software bloat
• Daily builds to ensure container images are up-to-date with available security patches
• High quality build-time SBOMs attesting to the provenance of all artifacts within the image
• Verifiable signatures provided by Sigstore
• Reproducible builds with Cosign and apko (read more about reproducibility)

For cases where you need container images with shells and package managers to build or debug, most Chainguard Containers come paired with a development, or -dev, variant.

In all other cases, including Chainguard Containers tagged as :latest or with a specific version number, the container images include only an open-source application and its runtime dependencies. These minimal container images typically do not contain a shell or package manager.

Although the -dev container image variants have similar security features as their more minimal versions, they include additional software that is typically not necessary in production environments. We recommend using multi-stage builds to copy artifacts from the -dev variant into a more minimal production image.

Need additional packages?

To improve security, Chainguard Containers include only essential dependencies. Need more packages? Chainguard customers can use Custom Assembly to add packages, either through the Console, chainctl, or API.

To use Custom Assembly in the Chainguard Console: navigate to the image you'd like to customize in your Organization's list of images, and click on the Customize image button at the top of the page.

Learn More

Refer to our Chainguard Containers documentation on Chainguard Academy. Chainguard also offers VMs and Libraries — contact us for access.

Trademarks

This software listing is packaged by Chainguard. The trademarks set forth in this offering are owned by their respective companies, and use of them does not imply any affiliation, sponsorship, or endorsement by such companies.