Fluentd is an open source data collector, which lets you unify the data collection and consumption for a better use and understanding of data.

$ helm repo add bitnami https://charts.bitnami.com/bitnami
$ helm install my-release bitnami/fluentd

This chart bootstraps a Fluentd deployment on a Kubernetes cluster using the Helm package manager.

Bitnami charts can be used with Kubeapps for deployment and management of Helm Charts in clusters.

• Kubernetes 1.12
• Helm 3.1.0
• PV provisioner support in the underlying infrastructure

Note: Please, note that the forwarder runs the container as root by default setting the forwarder.securityContext.runAsUser to 0 (root user)

To install the chart with the release name my-release:

$ helm repo add bitnami https://charts.bitnami.com/bitnami
$ helm install my-release bitnami/fluentd

These commands deploy Fluentd on the Kubernetes cluster in the default configuration. The Parameters section lists the parameters that can be configured during installation.

Tip: List all releases using helm list

To uninstall/delete the my-release resources:

$ helm delete my-release

The command removes all the Kubernetes components associated with the chart and deletes the release. Use the option --purge to delete all history too.

The following tables lists the configurable parameters of the fluentd chart and their default values.

Specify each parameter using the --set key=value[,key=value] argument to helm install. For example,

$ helm install my-release \
  --set aggregator.port=24444 bitnami/fluentd

The above command sets the aggregators to listen on port 24444.

Alternatively, a YAML file that specifies the values for the parameters can be provided while installing the chart. For example,

$ helm install my-release -f values.yaml bitnami/fluentd

Tip: You can use the default values.yaml

It is strongly recommended to use immutable tags in a production environment. This ensures your deployment does not change automatically if the same tag is updated with a different image.

Bitnami will release a new chart updating its containers if a new version of the main container, significant changes, or critical vulnerabilities exist.

By default, the aggregators in this chart will send the processed logs to the standard output. However, a common practice is to send them to another service, like Elasticsearch, instead. This can be achieved with this Helm Chart by mounting your own configuration files. For example:

configmap.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: elasticsearch-output
data:
  fluentd.conf: |
    # Prometheus Exporter Plugin
    # input plugin that exports metrics
    <source>
      @type prometheus
      port 24231
    </source>

    # input plugin that collects metrics from MonitorAgent
    <source>
      @type prometheus_monitor
      <labels>
        host ${hostname}
      </labels>
    </source>

    # input plugin that collects metrics for output plugin
    <source>
      @type prometheus_output_monitor
      <labels>
        host ${hostname}
      </labels>
    </source>

    # Ignore fluentd own events
    <match fluent.**>
      @type null
    </match>

    # TCP input to receive logs from the forwarders
    <source>
      @type forward
      bind 0.0.0.0
      port 24224
    </source>

    # HTTP input for the liveness and readiness probes
    <source>
      @type http
      bind 0.0.0.0
      port 9880
    </source>

    # Throw the healthcheck to the standard output instead of forwarding it
    <match fluentd.healthcheck>
      @type stdout
    </match>

    # Send the logs to the standard output
    <match **>
      @type elasticsearch
      include_tag_key true
      host "#{ENV['ELASTICSEARCH_HOST']}"
      port "#{ENV['ELASTICSEARCH_PORT']}"
      logstash_format true

      <buffer>
        @type file
        path /opt/bitnami/fluentd/logs/buffers/logs.buffer
        flush_thread_count 2
        flush_interval 5s
      </buffer>
    </match>

As an example, using the above configmap, you should specify the required parameters when upgrading or installing the chart:

aggregator.configMap=elasticsearch-output
aggregator.extraEnv[0].name=ELASTICSEARCH_HOST
aggregator.extraEnv[0].value=your-ip-here
aggregator.extraEnv[1].name=ELASTICSEARCH_PORT
aggregator.extraEnv[1].value=your-port-here

By default, the forwarder DaemonSet from this chart runs as the root user, within the root group, assigning root file system permissions. This is different to the default behaviour of most Bitnami Helm charts where we prefer to work with non-root containers.

The default behaviour is to run as root because:

• the forwarder needs to mount hostPath volumes from the underlying node to read Docker container (& potentially other) logs
• in many Kubernetes node distributions, these log files are not readable by anyone other than root
• fsGroup doesn't work with hostPath volumes to allow the process to run non-root with alternate file system permissions

Since we would like the chart to work out-of-the-box for as many users as possible, the forwarder thus runs as root by default. You can read more about the motivation for this at #1905 and #2323, however you should be aware of this, and the risks of running root containers in general.

If you enable the forwarder's bundled PodSecurityPolicy with forwarder.rbac.pspEnabled=true it will allow the pod to run as root by default, while ensuring as many other privileges as possible are dropped.

You can run as the fluentd user/group (non-root) with the below overrides if:

• you have control of the hostPath filesystem permissions on your nodes sufficient to allow the fluentd user to read from them
• don't need to write to the hostPaths

Note that if you have enabled the bundled PodSecurityPolicy, it will adapt to the Chart values overrides.

forwarder:
  daemonUser: fluentd
  daemonGroup: fluentd

  securityContext:
    runAsUser: 1001
    runAsGroup: 1001
    fsGroup: 1001

Mounting additional hostPaths is sometimes required to deal with /var/lib being symlinked on some Kubernetes environments. If you need to do so, the bundled PodSecurityPolicy will likely not meet your needs, as it whitelists only the standard hostPaths.

This chart allows you to set your custom affinity using the XXX.affinity parameter(s). Find more information about Pod's affinity in the kubernetes documentation.

As an alternative, you can use of the preset configurations for pod affinity, pod anti-affinity, and node affinity available at the bitnami/common chart. To do so, set the XXX.podAffinityPreset, XXX.podAntiAffinityPreset, or XXX.nodeAffinityPreset parameters.

Find more information about how to deal with common errors related to Bitnami’s Helm charts in this troubleshooting guide.

This version also introduces bitnami/common, a library chart as a dependency. More documentation about this new utility could be found here. Please, make sure that you have updated the chart dependencies before executing any upgrade.

On November 13, 2020, Helm v2 support was formally finished, this major version is the result of the required changes applied to the Helm Chart to be able to incorporate the different features added in Helm v3 and to be consistent with the Helm project itself regarding the Helm v2 EOL.

What changes were introduced in this major version?

• Previous versions of this Helm Chart use apiVersion: v1 (installable by both Helm 2 and 3), this Helm Chart was updated to apiVersion: v2 (installable by Helm 3 only). Here you can find more information about the apiVersion field.
• The different fields present in the Chart.yaml file has been ordered alphabetically in a homogeneous way for all the Bitnami Helm Charts

Considerations when upgrading to this version

• If you want to upgrade to this version from a previous one installed with Helm v3, you shouldn't face any issues
• If you want to upgrade to this version using Helm v2, this scenario is not supported as this version doesn't support Helm v2 anymore
• If you installed the previous version with Helm v2 and wants to upgrade to this version with Helm v3, please refer to the official Helm documentation about migrating from Helm v2 to v3

Useful links

• https://docs.bitnami.com/tutorials/resolve-helm2-helm3-post-migration-issues/
• https://helm.sh/docs/topics/v2_v3_migration/
• https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/

This version introduces the ability to create/customise a ServiceAccount to be used by the aggregator, making it possible to target the aggregator with PodSecurityPolicy independent of the forwarder's ServiceAccount.

The forwarder previously used the below top-level values to configure its own ServiceAccount, which have been moved under the forwarder. prefix to avoid confusion, and only created if forwarder.enabled=true. There is no functional change as a result of this, and if you did not override the defaults for serviceAccount or rbac, this change does not require any action from you.

If you are overriding the default values from the 1.x chart, the chart will fail installation with your old overrides and warn you of the necessary changes.

# before - 1.x
serviceAccount:
  create: true
  name: my-custom-service-account
  annotations:
    my-custom-annotation: my-custom-annotation-value
rbac:
  create: true

# after - 2.x
forwarder:
  # ...
  serviceAccount:
    create: true
    name: my-custom-service-account
    annotations:
      my-custom-annotation: my-custom-annotation-value
  rbac:
    create: true

In this version of the chart the Fluentd forwarder daemon system user will be root by default. This is done to ensure that mounted host paths are readable by the forwarder. For more context, check this support case.

No issues are expected in the upgrade process. However, please ensure that you add extra security measures in your cluster as you will be running root containers. If you want the daemon to be run as a user different from root, you can change the forwarder.daemonUser and forwarder.daemonGroup values. In this case make sure that the user you choose has sufficient permissions to read log files under /var/lib/docker/containers directory.