Kubernetes – ConfigMaps

An open-source container orchestration system called Kubernetes is primarily used for automated software deployment, scaling, and management. Another name for Kubernetes is K8s. Originally developed by Google, Kubernetes is now managed by the Cloud Native Computing Foundation. Although it now supports both containers and CRI-O alongside the Docker runtime, it was originally intended to interact. Automating container-managed operational tasks is the primary goal of Kubernetes. There are built-in commands for deploying the application and rolling out the desired changes to the application. It is currently used by companies such as Google, Spotify, and Capital One.

What are Kubernetes ConfigMaps?

In Kubernetes, Configmap is an API object that is mainly used to store non-confidential data. The data that is stored in ConfigMap is stored as key-value pairs. ConfigMaps are configuration files that may be used by pods as command-line arguments, environment variables, or even as configuration files on a disc. This feature allows us to decouple environment-specific configuration from our container images, after this is done, our applications are easily portable. The thing to be noted here is that ConfigMap does not provide any sort of secrecy or encryption, so it is advised to store non-confidential data only We can use secrets to store confidential data. 

A ConfigMap may be used to set configuration data independently of the application code. Imagine that we are developing an application that you can run on your computer and in the cloud. We create the code to check the DATABASE HOST environment variable. We can set the variable to localhost locally, but in the cloud, we set it to a Kubernetes service. A configMap is not designed to store large amounts of data in it. The data that is stored in ConfigMap cannot be more than 1 MB. If we need to store more data than that, then we can use volume instead of ConfigMaps.

What is a Kubernetes ConfigMap used for?

We know that ConfigMap is an API object that is mainly used to store non-confidential data or configurations for other objects to use. Most of the Kubernetes objects have a specification, but ConfigMap has data and binary data fields. Key value pairs are accepted by these fields as values. The data field is used to store UTF-8 strings, while the binary data field is used to store binary data as base64-encoded strings. A valid DNS subdomain name should be given to ConfigMap. The key value that is recorded in the data field and the key value in the binaryData field cannot both be the same.

Without being available to Pods this way directly, it may be used by other components of the system. Data that is utilized for configuration by other system components may be stored in COnfigMap. ConfigMaps are most commonly used to config settings for containers running in a Pod present in the same namespace. We can even use ConfigMap separately. 

Where are ConfigMaps stored in Kubernetes?

ConfigMaps in Kubernetes are stored as API objects within the Kubernetes cluster’s etcd datastore. They are managed by the Kubernetes API server and can be accessed and manipulated using the kubectl command-line tool or Kubernetes API.

How to use Kubernetes ConfigMaps – Examples

To create ConfigMaps in Kubernetes using YAML manifests, ensure the YAML file includes the apiVersion, kind, metadata, and data fields. The data field should contain key-value pairs representing the configuration data. Here’s an example YAML manifest for creating a ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
 name: demo-config
data:
 database_host: "172.138.0.1"
 debug_mode: "1"
 log_level: "verbose"

Save this manifest to a file named config.yaml. Then, apply it to your Kubernetes cluster using.

kubectl apply -f config.yaml

This will create the ConfigMap object named demo-config with the specified data in your cluster.

1. Using data and binaryData fields

When defining ConfigMaps in Kubernetes YAML manifests, note that the values within the data field must be strings. However, if you need to store binary data, you can utilize the binaryData field instead. Here’s an example illustrating this concept:

apiVersion: v1
kind: ConfigMap
metadata:
 name: binary-config
data:
 text-data: "This is a string value"
binaryData:
 binary-file: |
 U29tZSBiaW5hcnkgZGF0YQ==

In this YAML manifest, the data field contains a string value, while the binaryData field stores binary data represented by a base64-encoded string. This allows you to store both text and binary data within the same ConfigMap object.

2: Listing and inspecting ConfigMaps

To view the ConfigMaps you’ve created in Kubernetes, you can use the kubectl get command. Here’s how you can do it:

kubectl get configmaps

This command will list every ConfigMap in your Kubernetes cluster, along with their names and other pertinent details, when it is executed in your terminal or command prompt.

You can use the kubectl describe command in Kubernetes to view the key-value pairs that are kept in a ConfigMap. This is how you do it:

kubectl describe configmap <configmap-name>

The name of the ConfigMap you wish to investigate should be substituted for <configmap-name>. This command will enable you to confirm the configuration data that has been stored by giving you comprehensive details about the given ConfigMap, including its key-value pairs.

Getting a ConfigMap’s Content as JSON

This command retrieves the ConfigMap named “test-config”, extracts its data field, and formats the output using JSONPath. Then, the output is piped to the jq tool for better formatting and readability.

kubectl get configmap <configmap-name> -o=jsonpath='{.data}' | jq

3. Mounting ConfigMaps into Pods as volumes

We must first construct a ConfigMap in order to use it as a file in a pod. The command kubectl create configmap can be used to accomplish this. The ConfigMap must be mounted as a volume in the Pod once it has been generated. The volumes part of the Pod specification can be used to accomplish this.

For instance, the following Pod specification mounts a volume named my-configmap at the path /etc/configmap for a ConfigMap with the name my-configmap:

apiVersion: v1
kind: Pod
metadata:
 name: my-pod
spec:
 containers:
 - name: my-container
 image: my-image
 volumeMounts:
 - name: configmap-volume
 mountPath: /etc/configmap
 volumes:
 - name: configmap-volume
 configMap:
 name: my-configmap

The containers in the Pod can access the files in the ConfigMap once the ConfigMap has been mounted into the Pod. These files can then be used by the containers to launch and operate.

Here is an illustration of how to use a container to access the files in a ConfigMap:

# Get a list of all the files in the ConfigMap
ls /etc/configmap
# Get the contents of a file in the ConfigMap
cat /etc/configmap/my-file.txt

4. Mounting ConfigMaps into Pods as command line arguments

In Kubernetes, you can mount ConfigMaps into Pods as files and then access those files as command-line arguments. This allows you to pass configuration data to your application without hardcoding it into your container image. Here’s how you can achieve this:

1. Mount the ConfigMap into your Pod as a volume.
2. Access the configuration files from the mounted volume as command-line arguments.

Here’s an example YAML configuration to illustrate this:

apiVersion: v1
kind: Pod
metadata:
 name: test-pod
spec:
 containers:
 - name: test-container
 image: <your-app-image>
 command: ["/bin/sh", "-c", "your-app-binary --config /mnt/test-config/config.properties"]
 volumeMounts:
 - name: config-volume
 mountPath: /mnt/test-config
 volumes:
 - name: config-volume
 configMap:
 name: test-config

• A ConfigMap named “test-config” is defined with a single key “config.properties”, containing the application configuration.
• The Pod “test-pod” mounts the ConfigMap as a volume at “/mnt/test-config”.
• The application container in the Pod executes a command that includes the configuration file “/mnt/test-config/config.properties” as a command-line argument.

5. Using Immutable ConfigMaps

Read-only ConfigMaps that are unmodifiable once created are known as immutable ConfigMaps in Kubernetes. They come in handy when you want to make sure that the configuration data does not alter or become inconsistent during the course of your application. Here is an example of using immutable ConfigMaps:

• Create a ConfigMap with the immutable flag set to true.
• Once created, you cannot modify the data or metadata of the ConfigMap.
• If you need to update the configuration data, create a new ConfigMap with the updated values.
• Update your Pods to use the new ConfigMap.

Here’s an example YAML configuration to illustrate using immutable ConfigMaps:

apiVersion: v1
kind: ConfigMap
metadata:
 name: test-config
 annotations:
 immutable: "true" # Set the immutable flag to true
data:
 config.properties: |
 database_url=http://example.com/db
 debug_mode=true
 log_level=debug

kubectl apply -f test-config.yaml

• A ConfigMap named “test-config” is defined with the immutable flag set to true.
• The configuration data is specified under the “data” section as key-value pairs.
• Once created, any attempt to modify the “test-config” ConfigMap will result in an error.
• To update the configuration data, create a new ConfigMap with the desired changes and update your Pods to use the new ConfigMap.

By using immutable ConfigMaps, you can help prevent inadvertent modifications that can compromise the stability of your application and guarantee that its configuration stays consistent and dependable.

Understanding ConfigMap Updates

The configmaps can befig edited by using two ways one is by changing the config maps in the config file and by using the command kubectl edit configmap command. It will open the kubernetes configmaps file and there you can make the changes required in that file.

You can also use kubectl update configmap command. to update the config maps for example as shown below.

kubectl update configmap my-configmap –from-literal=key1=value1 –from-literal=key2=value2

• Data Mutation: Kubernetes applies modifications made to an updated ConfigMap to the current ConfigMap object. This implies that rather than producing a new item, the existing one is altered in-place. The modified configuration data is automatically sent to any pods referencing the updated ConfigMap.
• Pod Updates: When the ConfigMap is updated, pods that use ConfigMaps as environment variables or mount them as volumes are not automatically restarted. Consequently, until they are restarted or terminated, running pods continue to operate under the previous configuration.

How to Set Sensitive Config Values

Because ConfigMaps feature encryption, it isn’t recommended to store private or sensitive data on them. ConfigMap data may be accessed by anyone with access to the cluster’s etcd datastore. Use Secrets, which are made expressly for the safe transfer and maintaining of private information, for sensitive data.

ConfigMap vs Secrets