There are good solutions mentioned around here but I tried to find a solution that could be done without modifying existing deployment pipelines, etc. Here is an example of a filebeat Daemonset from a Helm chart that reloads when the filebeat config changes. The approach is not new: use the liveness probe to trigger a reload of the pod from within the pod itself. The postStart calculates an md5 sum of the configmap directory; the liveness probe checks it. That's all.

The '...' are just to cut out the cruft. You can see that the filebeat.yml file is mounted directly into /etc and used by filebeat itself. The configmap is mounted again, specifically for the purposes of watching the configmap contents for changes.

Once configmap is edited (or otherwise modified), it takes some time before the pod is actually restarted. You can tweak all of that separately.

#apiVersion: apps/v1
apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  name: ...-filebeat
...
      containers:
      - name: ...-filebeat
        image: "{{ .Values.filebeat.image.url }}:{{ .Values.filebeat.image.version }}"
        imagePullPolicy: "{{ .Values.filebeat.image.pullPolicy }}"
        command: [ "filebeat" ]
        args: [
          "-c", "/etc/filebeat-config/filebeat.yml",
          "-e"
        ]
        env:
...
        resources:
...
    lifecycle:
      postStart:
        exec:
          command: ["sh", "-c", "ls -LRih /etc/filebeat-config | md5sum >> /tmp/filebeat-config-md5.txt"]
    livenessProbe:
      exec:
        # Further commands can be strung to the statement e.g. calls with curl
        command:
          - sh
          - -c
          - >
            x=$(cat /tmp/filebeat-config-md5.txt);
            y=$(ls -LRih /etc/filebeat-config | md5sum);
            if [ "$x" != "$y" ]; then exit 1; fi
      initialDelaySeconds: 60
      periodSeconds: 60
    volumeMounts:
    - name: filebeat-config
      mountPath: /etc/filebeat-config
      readOnly: true
....

Depending on how you are consuming the configmap values, there could be two ways in which you can reload the configmap updates into a running pod.

• If you are consuming the configs as environment variables, you can write a controller, which watches for the updates in configs and restarts your pods with new config whenever the config changes.

• If you are consuming the configmap via volumes, you can watch for file changes and notify that to your process in the container and handle the update in application. Please see https://github.com/jimmidyson/configmap-reload for example.