Skip to content

Commit d9f82c9

Browse files
author
Tim Bannister
committed
Explain ConfigMap volume source items array
The existing ConfigMap concept incorrectly states that you must use different ConfigMap objects if you want to configure both environment variables and file-like configuration items at the same time. Reword to give the correct advice.
1 parent b754da8 commit d9f82c9

File tree

1 file changed

+17
-16
lines changed

1 file changed

+17
-16
lines changed

content/en/docs/concepts/configuration/configmap.md

Lines changed: 17 additions & 16 deletions
Original file line numberDiff line numberDiff line change
@@ -126,25 +126,32 @@ spec:
126126
configMap:
127127
# Provide the name of the ConfigMap you want to mount.
128128
name: game-demo
129+
# An array of keys from the ConfigMap to create as files
130+
items:
131+
- key: "game.properties"
132+
path: "game.properties"
133+
- key: "user-interface.properties"
134+
path: "user-interface.properties"
129135
```
130136

131137

132138
A ConfigMap doesn't differentiate between single line property values and
133139
multi-line file-like values.
134140
What matters is how Pods and other objects consume those values.
141+
135142
For this example, defining a volume and mounting it inside the `demo`
136-
container as `/config` creates four files:
143+
container as `/config` creates two files,
144+
`/config/game.properties` and `/config/user-interface.properties`,
145+
even though there are four keys in the ConfigMap. This is because the Pod
146+
definition specifies an `items` array in the `volumes` section.
147+
If you omit the `items` array entirely, every key in the ConfigMap becomes
148+
a file with the same name as the key, and you get 4 files.
137149

138-
- `/config/player_initial_lives`
139-
- `/config/ui_properties_file_name`
140-
- `/config/game.properties`
141-
- `/config/user-interface.properties`
150+
## Using ConfigMaps
142151

143-
If you want to make sure that `/config` only contains files with a
144-
`.properties` extension, use two different ConfigMaps, and refer to both
145-
ConfigMaps in the `spec` for a Pod. The first ConfigMap defines
146-
`player_initial_lives` and `ui_properties_file_name`. The second
147-
ConfigMap defines the files that the kubelet places into `/config`.
152+
ConfigMaps can be mounted as data volumes. ConfigMaps can also be used by other
153+
parts of the system, without being directly exposed to the Pod. For example,
154+
ConfigMaps can hold data that other parts of the system should use for configuration.
148155

149156
{{< note >}}
150157
The most common way to use ConfigMaps is to configure settings for
@@ -157,12 +164,6 @@ or {{< glossary_tooltip text="operators" term_id="operator-pattern" >}} that
157164
adjust their behavior based on a ConfigMap.
158165
{{< /note >}}
159166

160-
## Using ConfigMaps
161-
162-
ConfigMaps can be mounted as data volumes. ConfigMaps can also be used by other
163-
parts of the system, without being directly exposed to the Pod. For example,
164-
ConfigMaps can hold data that other parts of the system should use for configuration.
165-
166167
### Using ConfigMaps as files from a Pod
167168

168169
To consume a ConfigMap in a volume in a Pod:

0 commit comments

Comments
 (0)