Skip to main content

ConfigMap Volume Mounts

ConfigMaps Part 2

In the past lesson you have learned how to map ConfigMaps to environment variables. While this is a valid approach to separate configuration information from application source code, it comes with a slight drawback.

Environment variables are injected into a Pod during its creation and therefore changes to a ConfigMap won't be reflected during the Pod's lifetime. In other words, to update the ConfigMaps of a Pod, the Pod has to be restarted.

Alternatively, Kubernetes allows file based access to ConfigMaps. With this approach a ConfigMap is mounted as a volume into a Pod. In case the ConfigMap is updated, changes are reflected immediately in the files of the ConfigMap volume. To date there is no notification from Kubernetes telling the application actively about a ConfigMap update. It therefore is the responsibility of the application to observe ConfigMap files for changes and handle them accordingly.

Have a look at the Pod definition in the file 70-pod-with-config-map-volume.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: busybox-config
spec:
  containers:
    - image: busybox
      name: busybox-config-container
      command:
        - 'sh'
        - '-c'
      args:
        - 'ls /config; cat /config/number-of-requests; echo " "; cat /config/very-important-switch'
      volumeMounts:
        - name: config-volume
          mountPath: /config
  volumes:
    - name: config-volume
      configMap:
        name: config-example-2
  restartPolicy: Never

The Pod definition in 70-pod-with-config-map-volume.yaml uses sh -c as the container command to then execute several shell commands passed as arguments. Generally speaking, containers should have a single responsibility and thus invoking a single command should suffice. In this case of a one-off Pod building a container image would be wasteful so that the trick comes in handy.

Also worth recognizing is that the volume is defined at the Pod level but mounted at the container level. You can see this by looking at the indentation level where volumes is on the same level as spec but volumeMounts is located under the busybox-config container in the containers section. This means that a volume can be shared among containers of the same Pod.

Execute the Pod definition:

kubectl apply -f 70-pod-with-config-map-volume.yaml

The ls /config command will print to STDOUT and the output can be gathered as logs:

kubectl logs busybox-config

The log output should be:

number-of-requests
very-important-switch
20
true

As the log-output shows the ConfigMap keys are represented as files in the ConfigMap volume. Their contents are the ConfigMap values associated with the corresponding keys. Pretty straightforward.

Exercise​

If ConfigMap keys become files and ConfigMap values are the contents of these files, the earlier ConfigMap example config-example-1 comes to mind. In this ConfigMap the key 20-config-file.conf was created after importing a config file converting into a ConfigMap.

Modify the Pod definition from the previous example to mount the config file contained in the ConfigMap and write its contents to the log (like before).

Can you see how importing the config file goes together with mounting the ConfigMap as a volume? From the container's perspective the config file "feels" like any other config file.