Please visit these pages for more details about ConfigMaps:
https://kubernetes.io/docs/concepts/configuration/configmap/
https://docs.openshift.com/dedicated/4/builds/builds-configmaps.html
https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names

ConfigMaps allows creating data objects that can be consumed by Pods at runtime.
The data in ConfigMaps is stored as key-value entries:

• Key: is a string value formed by alphanumeric, dot (.), dash (-), and underscore (_) characters.
  
  
• Value: is a string value that can contain any character, including carriage returns (if multiple lines then the data must be indented properly).
  
  

The key and the value, in the ConfigMap, are separated with a colon (key:value).

The name of the ConfigMap must be a valid DNS subdomain name.

Examples of values that can be saved in ConfigMaps include:

• Application settings.
  
  
• Configuration files (json/xml/properties files, shell scripts, ...).
  
  
• Base64 encoded data.
  
  

ConfigMaps are not meant to store sensitive data (credentials, certificates, ...). Kubernetes Secrets should be used instead.

The data stored in a ConfigMap can be consumed in a container in one the following ways:

• Environment variables.
  
  
• Command-line arguments of the container command.
  
  
• Files in volumes.
  
  
• Custom code (read the ConfigMap directly from the Kubernetes API).
  
  

Note:
If you update a ConfigMap that was already posted to the Kubernetes API server, then containers that were already created will be able to leverage the new data only if it was injected as files in a volume. ConfigMap data injected as environment variables won't be updated in a running container.

The data of the ConfigMaps can be specified using:

• --from-literal:
  Specify a key and literal value to insert in the ConfigMap.
  
  Create the ConfigMap:
  $ kubectl create configmap configmapfromliteral --from-literal="key1=value1" --from-literal="key2=value2" configmap/configmapfromliteral created
  Check the ConfigMap:
  $ kubectl get configmap configmapfromliteral NAME DATA AGE configmapfromliteral 2 2m10s
  Describe the ConfigMap:
  $ kubectl describe configmap configmapfromliteral Name: configmapfromliteral Namespace: default Labels: <none> Annotations: <none> Data ==== key1: ---- value1 key2: ---- value2 Events: <none>
  View the YAML file of the ConfigMap:
  $ kubectl get configmap configmapfromliteral -o yaml apiVersion: v1 data: key1: value1 key2: value2 kind: ConfigMap metadata: name: configmapfromliteral namespace: default
  The manifest file of the ConfigMap is pretty simple.
  It contains the fields apiVersion, kind, and metadata.
  It also contain the data field that contains the keys-values of the ConfigMap.
  
  
• --from-file:
  Specify a file path (--from-file="/home/nhabti/configmaps/file1.txt"), in which case the file base name will be used as the ConfigMap key.
  
  Or optionally with a key and file path (--from-file="mykey1=/home/nhabti/configmaps/file1.txt"), in which case the given key will be used as the ConfigMap key.
  
  Specifying a directory (--from-file="/home/nhabti/configmapsdir/") will iterate each named file in the directory and create a new entry for each file whose base name is a valid ConfigMap key.
  
  The path to the file (or directory) can be an absolute path or relative to the location from where the "kubectl create configmap" is executed.
  
  The content of the file can be anything.
  
  Let's have crate a directory where the sample files will stored (this can be any location you prefer):
  $ mkdir /home/nhabti/configmaps/
  Create a sample file "file1.txt" (single line text):
  $ echo -n 'value1' > "/home/nhabti/configmaps/file1.txt"
  Create a sample file "file2.txt" (multiple lines text):
  $ echo 'value2-1' > "/home/nhabti/configmaps/file2.txt" $ echo 'value2-2' >> "/home/nhabti/configmaps/file2.txt"
  
  • Create the ConfigMap (from file without a key):
    $ kubectl create configmap configmapfromfile1 --from-file="/home/nhabti/configmaps/file1.txt" --from-file="/home/nhabti/configmaps/file2.txt" configmap/configmapfromfile1 created
    View the ConfigMap (notice that the content of the file is indented properly):
    $ kubectl get configmap configmapfromfile1 -o yaml apiVersion: v1 data: file1.txt: value1 # note that the name of the key is file1.txt and the value is single line file2.txt: | # note that the name of the key is file2.txt and the value is multiple lines value2-1 value2-2 kind: ConfigMap metadata: name: configmapfromfile1 namespace: default
    
  • Create the ConfigMap (from file with a key):
    $ kubectl create configmap configmapfromfile2 --from-file="mykey1=/home/nhabti/configmaps/file1.txt" --from-file="mykey2=/home/nhabti/configmaps/file2.txt" configmap/configmapfromfile2 created
    View the ConfigMap (notice that the content of the file is indented properly):
    $ kubectl get configmap configmapfromfile2 -o yaml apiVersion: v1 data: mykey1: value1 # note that the name of the key is mykey1 and the value is single line mykey2: | # note that the name of the key is mykey2 and the value is multiple lines value2-1 value2-2 kind: ConfigMap metadata: name: configmapfromfile2 namespace: default
    
  • Create the ConfigMap (from a directory):
    $ kubectl create configmap configmapfromdirectory --from-file="/home/nhabti/configmaps/" configmap/configmapfromdirectory created
    View the ConfigMap (notice that the content of the file is indented properly):
    $ kubectl get configmap configmapfromdirectory -o yaml apiVersion: v1 data: file1.txt: value1 # note that the name of the key is file1.txt and the value is single line file2.txt: | # note that the name of the key is file2.txt and the value is multiple lines value2-1 value2-2 kind: ConfigMap metadata: name: configmapfromfile1 namespace: default
  
  
• --from-env-file:
  Specify the path to a file (--from-file="/home/nhabti/configmaps/file1.properties") to read lines of key=val pairs to insert in the ConfigMap.
  
  Create simple files:
  $ vi "/home/nhabti/configmaps/file1.properties" key1=value1 key2=value2
  Create the ConfigMap:
  $ kubectl create configmap configmapfromenvfile --from-env-file="/home/nhabti/configmaps/file1.properties" configmap/configmapfromenvfile created
  View the ConfigMap (notice that the content of the file is indented properly):
  $ kubectl get configmap configmapfromenvfile -o yaml apiVersion: v1 data: key1: value1 key2: value2 kind: ConfigMap metadata: name: configmapfromenvfile namespace: default

• Regular Manifest yaml file that defines a ConfigMag with simple key-value entries:
  $ vi configmapkeyvalue.yaml apiVersion: v1 kind: ConfigMap metadata: name: configmapkeyvalue data: key1: value1 key2: value2
  To apply the file:
  $ kubectl apply -f configmapkeyvalue.yaml configmap/configmapkeyvalue created
  
• Regular Manifest yaml file that defines a ConfigMag with keys and multi-line values entries:
  
  The key should be followed by the pipe character (|) and the value can span multiple lines.
  
  Note though that all the lines should be indented properly.
  
  $ vi configmapmultilinevalue.yaml apiVersion: v1 kind: ConfigMap metadata: name: configmapmultilinevalue data: key3: | first line second line third line

If you have created a ConfigMap using the manifest YAML file, then to change that ConfigMap you only need to adjust the YAML file and run the command kubectl apply -f CONFIGMAP-YAML-FILE-PATH

You can also use the command kubectl edit configmap CONFIGMAP-NAME to edit a ConfigMap. The command will open the ConfigMap in your default text editor. You do your changes and save that. Once you exit the editor, your changes will be submitted to API Server.

For example to view and edit the ConfigMap "configmapkeyvalue":
$ kubectl edit configmap configmapkeyvalue # Please edit the object below. # Lines beginning with a '#' will be ignored, and an empty file will abort the edit. # If an error occurs while saving this file will be reopened with the relevant failures. # apiVersion: v1 data: key1: value1 key2: value2 kind: ConfigMap metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"v1","data":{"key1":"value1","key2":"value2"},"kind":"ConfigMap","metadata":{"annotations":{},"name":"configmapkeyvalue","namespace":"default"}} creationTimestamp: "2021-06-06T04:35:51Z" name: configmapkeyvalue namespace: default resourceVersion: "2054685" selfLink: /api/v1/namespaces/default/configmaps/configmapkeyvalue uid: 3fa69d0b-36fd-4793-a3c7-fd3f0411e914 configmap/configmapkeyvalue edited

In a Pod YAML file, you can reference the entries of the ConfigMap directly in the "spec.containers.env" field. The environment variables will be set as any other regular Linux environment variables. You can check them using the env command directly from inside the container.

Note that if you start the Pod and later you change the ConfigMap, then these changes won't be reflected in the container unless you recreate the Pod.

• Let's use the ConfiMap "configmapkeyvalue" (see above) with the Pod "hello-busybox-configmaps":
  $ vi hello-busybox-configmaps-pod.yaml apiVersion: v1 kind: Pod metadata: name: hello-busybox-configmaps spec: containers: - name: hello-busybox-configmaps image: busybox:latest command: ['sh', '-c', 'sleep 300;'] env: - name: mykey1 valueFrom: configMapKeyRef: name: configmapkeyvalue key: key1 - name: mykey2 valueFrom: configMapKeyRef: name: configmapkeyvalue key: key2
  Note:
  You can give the environment variable a different name than the ConfigMap key name (i.e. name: mykey1).
  
  Apply the Pod:
  $ kubectl apply -f hello-busybox-configmaps-pod.yaml pod/hello-busybox-configmaps created
  Check the environment variables:
  $ kubectl exec hello-busybox-configmaps -- env | grep key mykey1=value1 mykey2=value2
  
• Instead of referencing individual entries of the ConfiMap, you can use the "spec.containers.envFrom" field to reference all entries of the ConfiMap:
  $ vi hello-busybox-configmaps-pod.yaml apiVersion: v1 kind: Pod metadata: name: hello-busybox-configmaps spec: containers: - name: hello-busybox-configmaps image: busybox:latest command: ['sh', '-c', 'sleep 300;'] envFrom: - configMapRef: name: configmapkeyvalue
  Apply the Pod:
  $ kubectl apply -f hello-busybox-configmaps-pod.yaml pod/hello-busybox-configmaps created
  Check the environment variables:
  $ kubectl exec hello-busybox-configmaps -- env | grep key key1=value1 key2=value2

ConfigMaps can also be referenced using volumes. Usually this is helpful when the ConfigMap contains configuration data (logging, ...).

Each entry of the ConfigMap will be referenced as a separate file in the volume.

The changes to the ConfigMap will be reflect directly in the volumes.

The ConfigMap is defined as a volume (spec.volumes) and mounted to the container (spec.containers.volumeMounts).

• In the following example, the .spec.volumes field creates a volume (named configmapkeyvalue) from the "configmapkeyvalue" ConfigMap.
  The .spec.containers.volumeMounts field mounts the volume (configmapkeyvalue) into the container (under /tmp/configmapkeyvalue).
  The volume will be populated with files where the file name is the key of the ConfigMap (key1, key2) and the content of the file is the value of the key (value1, value2).
  
  $ vi hello-busybox-configmaps-pod.yaml apiVersion: v1 kind: Pod metadata: name: hello-busybox-configmaps spec: containers: - name: hello-busybox-configmaps image: busybox:latest command: ['sh', '-c', 'sleep 300;'] volumeMounts: - name: configmapkeyvalue mountPath: /tmp/configmapkeyvalue volumes: - name: configmapkeyvalue configMap: name: configmapkeyvalue
  Apply the Pod:
  $ kubectl apply -f hello-busybox-configmaps-pod.yaml pod/hello-busybox-configmaps created
  Check the files in the volume (notice two files are created: key1, key2):
  $ kubectl exec hello-busybox-configmaps -- ls /tmp/configmapkeyvalue key1 key2
  Check the content of the files:
  $ kubectl exec hello-busybox-configmaps -- cat /tmp/configmapkeyvalue/key1 value1
  
• You can also decide what entries of the ConfigMag can be mounted (you can also decide the name of file in the volume "path"):
  $ vi hello-busybox-configmaps-pod.yaml apiVersion: v1 kind: Pod metadata: name: hello-busybox-configmaps spec: containers: - name: hello-busybox-configmaps image: busybox:latest command: ['sh', '-c', 'sleep 300;'] volumeMounts: - name: configmapkeyvalue mountPath: /tmp/configmapkeyvalue volumes: - name: configmapkeyvalue configMap: name: configmapkeyvalue items: - key: key1 path: key1path
  Apply the Pod:
  $ kubectl apply -f hello-busybox-configmaps-pod.yaml pod/hello-busybox-configmaps created
  Check the files in the volume (notice the "key1path" file was created):
  $ kubectl exec hello-busybox-configmaps -- ls /tmp/configmapkeyvalue key1path
  Check the content of the files:
  $ kubectl exec hello-busybox-configmaps -- cat /tmp/configmapkeyvalue/key1path value1

You can use the data of the ConfigMap to set the command or arguments in the container.
You use the following syntax to reference the environment variable: $(ENV_VAR_NAME).

As previously mentioned, changes to the ConfigMap won't be reflect for the environment variables already set.

$ vi hello-busybox-configmaps-pod.yaml apiVersion: v1 kind: Pod metadata: name: hello-busybox-configmaps spec: containers: - name: hello-busybox-configmaps image: busybox:latest command: ['sh', '-c', 'echo "mykey1:$(mykey1) | mykey2:$(mykey2)"; sleep 300;'] env: - name: mykey1 valueFrom: configMapKeyRef: name: configmapkeyvalue key: key1 - name: mykey2 valueFrom: configMapKeyRef: name: configmapkeyvalue key: key2
Apply the Pod:
$ kubectl apply -f hello-busybox-configmaps-pod.yaml pod/hello-busybox-configmaps created
Check the logs of the Pod:
$ kubectl logs hello-busybox-configmaps mykey1:value1 | mykey2:value2

To delete a ConfigMap: using manifest file (kubectl delete):
$ kubectl delete -f configmapkeyvalue.yaml configmap "configmapkeyvalue" deleted
To delete a ConfigMap using its name:
$ kubectl delete configmap configmapkeyvalue configmap "configmapkeyvalue" deleted