Copying a Fluentd-config file to a kubernetes pod

Question

I've got a fluentd.conf file and I'm trying to use (copy) it in my minikube cluster (works fine in a docker container). The steps are the following:

1. Ill build (in my minikube docker-env) the docker image with the following commands Dockerfile:

FROM fluent/fluentd:v1.11-1

# Use root account to use apk
USER root

# below RUN includes plugin as examples elasticsearch is not required
# you may customize including plugins as you wish
RUN apk add --no-cache --update --virtual .build-deps \
    sudo build-base ruby-dev \
    && sudo gem install fluent-plugin-elasticsearch \
    && sudo gem sources --clear-all \
    && apk del .build-deps \
    && rm -rf /tmp/* /var/tmp/* /usr/lib/ruby/gems/*/cache/*.gem

COPY conf/fluent.conf /fluentd/etc/
USER fluent

2. This executes succesfully (so the copy works) and results in a runnable image, the following step is to launch the pods. Part of the deployment files

      spec:
        containers:
        - image: fluentd
          imagePullPolicy: ""
          name: fluentd
          ports:
          - containerPort: 24224
          - containerPort: 24224
            protocol: UDP
          resources: {}
          volumeMounts:
          - mountPath: /fluentd/etc
            name: fluentd-claim0
        restartPolicy: Always
        serviceAccountName: ""
        volumes:
        - name: fluentd-claim0
          persistentVolumeClaim:
            claimName: fluentd-claim0

Everything launches fine but the fluentd-pod returns the following error: No such file or directory @ rb_sysopen - /fluentd/etc/fluent.conf

Anybody got an idea what i'm missing or what i'm doing wrong?

Thanks in advance,

Answer 1

This happens because you are mounting a volume in the same folder.

Inside your image, the config file is placed in /fluentd/etc/fluent.conf .

In your pod, you mount the fluentd-claim0 volume into /fluentd/etc/ :

volumeMounts:
- mountPath: /fluentd/etc
  name: fluentd-claim0

Like it would happen if you mount a volume in a nonempty directory in linux, all files present in the mount point directory will be hidden by the mount itself.

In order to "fix" this, you could use the subPath option of the volumeMounts entry like described in the documentation . For example:

volumeMounts:
- mountPath: /fluentd/etc/myfileordirectory
  name: fluentd-claim0
  subPath: myfileordirectory

This way only myfileordirectory will be mounted in /fluentd/etc/ and the rest of files will still be visible.

The limitation of this approach is that you need to know the list of files within your volume in advance. If this is not possible, the only alternative is to use a different directory for either your config file or your mountPath.

Answer 2

I see two problems in this setup.

First, your image: fluentd is running the Docker Hub fluentd image and not your customized image. You need to give a name including a registry address or your Docker Hub user name to use something else. (You say you're using minikube, so you could have docker build -t fluentd in the minikube context to get this image; try to avoid using names that could conflict with the Docker Hub image names even for local builds.)

Second, your volume setup is creating a new empty persistent volume, and then overwriting the configuration file in the image with that volume. Nothing copies anything into the persistent volume, so you're getting an empty directory inside the container. (This is different from Docker named volumes; even in plain Docker, I don't recommend relying on the copy-on-first-use volume behavior.) You can delete everything that mentions the volumes.

That leaves you with a simpler pod spec, especially if you also delete fields that are being left at default values:

spec:
  containers:
    - image: my/fluentd # not plain "fluentd"
      name: fluentd
      ports:
      - containerPort: 24224
      - containerPort: 24224
        protocol: UDP
    restartPolicy: Always

Another option is to provide the configuration file in a ConfigMap . It wouldn't necessarily be in your image in this case, and if you use a tool like Helm to deploy, there's an opportunity to set up the configuration at deployment time. Here you would have most of the volume machinery, but the volumes: block would reference the configMap: and not a PVC.