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
- image: busybox
- 'ls /config; cat /config/number-of-requests; echo " "; cat /config/very-important-switch'
- name: config-volume
- name: config-volume
The Pod definition in
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
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
ls /config command will print to STDOUT and the output can be gathered as logs:
kubectl logs busybox-config
The log output should be:
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.
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.