Using ConfigMaps as mounted volumes in Kubernetes - Step-by-Step Execution

Process Flow - Using ConfigMaps as mounted volumes

Create ConfigMap with data

↓

Define Pod spec with volume referencing ConfigMap

↓

Mount volume inside container at path

↓

Pod starts, volume files appear inside container

↓

Container reads config files from mounted volume

This flow shows how a ConfigMap is created, referenced as a volume in a Pod, mounted inside the container, and then accessed as files.

Execution Sample

Kubernetes

kubectl create configmap app-config --from-literal=key1=value1
---
apiVersion: v1
kind: Pod
metadata:
  name: configmap-pod
spec:
  containers:
  - name: app
    image: busybox
    volumeMounts:
    - name: config-volume
      mountPath: /etc/config
  volumes:
  - name: config-volume
    configMap:
      name: app-config

Creates a ConfigMap and mounts it as a volume inside a Pod at /etc/config.

Process Table

Step	Action	Resource Created/Modified	Result/State Change
1	Create ConfigMap with key1=value1	ConfigMap 'app-config'	ConfigMap stores key1=value1
2	Define Pod spec referencing ConfigMap volume	Pod 'configmap-pod' spec	Pod spec includes volume 'config-volume' from ConfigMap 'app-config'
3	Mount volume inside container at /etc/config	Container volumeMounts updated	Volume 'config-volume' mounted at /etc/config inside container
4	Start Pod	Pod 'configmap-pod' running	Pod starts, container filesystem has /etc/config/key1 file with content 'value1'
5	Container reads /etc/config/key1	File read operation	Container reads 'value1' from mounted ConfigMap file
6	Pod terminates or deleted	Pod removed	Mounted volume and ConfigMap files no longer accessible
Exit	No more steps	-	Execution ends after Pod lifecycle

💡 Pod lifecycle ends, mounted ConfigMap volume is removed with Pod termination

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	After Step 5	Final
ConfigMap 'app-config'	None	Created with key1=value1	Unchanged	Unchanged	Unchanged	Unchanged	Exists until Pod deleted
Pod 'configmap-pod'	None	None	Defined with volume referencing ConfigMap	Volume mounted at /etc/config	Running with mounted volume	Container reads file content	Deleted after termination
Mounted volume files	None	None	None	Files appear at /etc/config/key1	File content 'value1' accessible	Read successfully	Removed with Pod

Key Moments - 3 Insights

Why does the ConfigMap data appear as files inside the container?

Because the ConfigMap is mounted as a volume, Kubernetes creates files inside the container at the mount path, each file named after a key with its content as the value, as shown in execution_table step 4.

What happens if the ConfigMap is updated after the Pod is running?

The mounted volume does not automatically update inside the running Pod. The Pod must be restarted to see changes, as the volume files are created at Pod start (see execution_table step 4).

Can the container write to the ConfigMap files inside the mounted volume?

No, the ConfigMap volume is read-only inside the container. Attempts to write will fail, ensuring config data integrity (implied by volume mount behavior in step 3).

Visual Quiz - 3 Questions

Look at the execution table, at which step does the ConfigMap volume get mounted inside the container?

A Step 3

B Step 2

C Step 4

D Step 5

💡 Hint

Check the 'Action' and 'Result/State Change' columns for volume mounting details.

According to the variable tracker, what is the state of the Pod after Step 4?

A Pod is deleted

B Pod is defined but not running

C Pod is running with mounted volume

D Pod is starting but volume not mounted

💡 Hint

Look at the 'Pod configmap-pod' row under 'After Step 4' in variable_tracker.

If the ConfigMap is updated after the Pod starts, what will happen to the files inside the container?

A Files update immediately

B Files do not update until Pod restart

C Files update after a delay

D Files are deleted

💡 Hint

Refer to key_moments about ConfigMap updates and execution_table step 4.

Concept Snapshot

Create a ConfigMap with kubectl or YAML
Reference it in Pod spec as a volume under 'volumes'
Mount the volume inside container with 'volumeMounts' and 'mountPath'
At Pod start, ConfigMap keys appear as files in mountPath
Files are read-only and reflect ConfigMap data at Pod start
Pod restart needed to see ConfigMap updates

Full Transcript

This visual execution shows how to use ConfigMaps as mounted volumes in Kubernetes. First, a ConfigMap named 'app-config' is created with key-value data. Then, a Pod is defined that references this ConfigMap as a volume named 'config-volume'. The volume is mounted inside the container at /etc/config. When the Pod starts, Kubernetes creates files inside the container at /etc/config, each file named after a ConfigMap key with its content as the value. The container can read these files to access configuration data. The ConfigMap volume is read-only, so the container cannot modify these files. If the ConfigMap is updated after the Pod is running, the files inside the container do not change until the Pod is restarted. Finally, when the Pod is deleted, the mounted volume and files disappear. This step-by-step trace helps beginners understand how ConfigMaps provide configuration data to containers via mounted volumes.

Practice

1. What is the main purpose of using a ConfigMap as a mounted volume in Kubernetes?

easy

A. To provide configuration data as files inside a container without rebuilding the image

B. To store container logs persistently

C. To increase container CPU limits dynamically

D. To manage container networking settings

Solution

1. Step 1: Understand ConfigMap role

   ConfigMaps hold configuration data separately from container images.

2. Step 2: Understand mounting as volume

   Mounting a ConfigMap as a volume makes its data available as files inside the container.

3. Final Answer:

   To provide configuration data as files inside a container without rebuilding the image -> Option A

4. Quick Check:

   ConfigMap volume = config files inside container [OK]

Hint: ConfigMaps as volumes = config files inside container [OK]

Common Mistakes:

• Confusing ConfigMaps with persistent storage for logs
• Thinking ConfigMaps control CPU or networking
• Assuming ConfigMaps require container rebuild

2. Which of the following is the correct YAML snippet to mount a ConfigMap named app-config as a volume in a pod?

easy

A. volumes:\n - name: config-volume\n emptyDir: {}

B. volumes:\n - name: config-volume\n secret:\n name: app-config

C. volumes:\n - name: config-volume\n persistentVolumeClaim:\n claimName: app-config

D. volumes:\n - name: config-volume\n configMap:\n name: app-config

Solution

1. Step 1: Identify volume type for ConfigMap

   ConfigMaps are mounted using the configMap field inside volumes.

2. Step 2: Match correct YAML structure

   volumes:\n - name: config-volume\n configMap:\n name: app-config correctly uses configMap: with the ConfigMap name.

3. Final Answer:

   volumes:\n - name: config-volume\n configMap:\n name: app-config -> Option D

4. Quick Check:

   ConfigMap volume uses configMap: name [OK]

Hint: ConfigMap volume uses 'configMap:' with name [OK]

Common Mistakes:

• Using secret instead of configMap for ConfigMap volumes
• Confusing persistentVolumeClaim with ConfigMap
• Using emptyDir which is an empty temp volume

3. Given this pod volume mount snippet, what file content will appear inside the container at /etc/config/app.properties if the ConfigMap app-config has a key app.properties with value mode=production?

volumes:
  - name: config-volume
    configMap:
      name: app-config
containers:
  - name: app
    image: myapp
    volumeMounts:
      - name: config-volume
        mountPath: /etc/config
        readOnly: true

medium

A. A directory named app.properties with no content

B. No file created because mountPath is a directory

C. A file named app.properties with content 'mode=production'

D. A file named app.properties with content 'mode=development'

Solution

1. Step 1: Understand ConfigMap key to file mapping

   Each key in ConfigMap becomes a file with that name and its value as content.

2. Step 2: Check mountPath and file presence

   Mounting at /etc/config creates files inside that directory, including app.properties with content mode=production.

3. Final Answer:

   A file named app.properties with content 'mode=production' -> Option C

4. Quick Check:

   ConfigMap key = filename, value = file content [OK]

Hint: ConfigMap keys become files with their values inside mountPath [OK]

Common Mistakes:

• Thinking mountPath must be a file, not directory
• Assuming file content changes without ConfigMap update
• Confusing file name with directory

4. You mounted a ConfigMap as a volume, but inside the container the files are missing. Which is the most likely cause?

medium

A. The ConfigMap name in the volume spec does not match any existing ConfigMap

B. The container image does not support volumes

C. The pod has no CPU resources assigned

D. The ConfigMap keys are empty strings

Solution

1. Step 1: Check ConfigMap reference correctness

   If the ConfigMap name in the volume spec is wrong, Kubernetes cannot mount it, so files won't appear.

2. Step 2: Eliminate unrelated causes

   Container images support volumes by default; CPU resources don't affect file mounting; keys cannot be empty strings in ConfigMaps.

3. Final Answer:

   The ConfigMap name in the volume spec does not match any existing ConfigMap -> Option A

4. Quick Check:

   Wrong ConfigMap name = no files mounted [OK]

Hint: Check ConfigMap name spelling in volume spec [OK]

Common Mistakes:

• Blaming container image for missing files
• Ignoring ConfigMap existence or name mismatch
• Assuming resource limits affect volume mounts

5. You want to mount only specific keys from a ConfigMap named app-config as files inside a container at /etc/config. Which volume configuration snippet achieves this?

hard

A. volumes:
- name: config-volume
configMap:
name: app-config
exclude:
- unused_key

B. volumes:
- name: config-volume
configMap:
name: app-config
items:
- key: database_url
path: db_url
- key: log_level
path: log_level

C. volumes:
- name: config-volume
secret:
name: app-config
items:
- key: database_url
path: db_url

D. volumes:
- name: config-volume
configMap:
name: app-config
keys:
- database_url
- log_level

Solution

1. Step 1: Understand selective key mounting

   Kubernetes allows selecting specific keys from a ConfigMap using the items field with key and path.

2. Step 2: Identify correct syntax

   volumes: - name: config-volume configMap: name: app-config items: - key: database_url path: db_url - key: log_level path: log_level correctly uses items with key-path pairs to mount only chosen keys as files.

3. Final Answer:

   volumes: - name: config-volume configMap: name: app-config items: - key: database_url path: db_url - key: log_level path: log_level -> Option B

4. Quick Check:

   Use items with key and path to select keys [OK]

Hint: Use 'items' with key and path to mount specific keys [OK]

Common Mistakes:

• Using 'keys' instead of 'items' for selection
• Confusing ConfigMap with Secret for this purpose
• Trying to exclude keys instead of selecting them