Kubernetes ConfigMaps Explained: Simplify Application Configuration Management

Kubernetes ConfigMaps play a vital role in configuration management for deploying scalable and maintainable containerized applications. In modern Kubernetes environments, managing configuration data effectively ensures flexibility and faster deployments. Many developers still hardcode configuration values directly into container images, which makes applications rigid and forces unnecessary redeployments whenever they change a setting.

Developers often embed configuration data such as database URLs, API keys, service endpoints, or environment-specific parameters directly in the application code instead of using Kubernetes ConfigMaps. Each small change then requires rebuilding the container image. This practice slows down Kubernetes deployment cycles, increases maintenance work, and limits flexibility across environments like development, staging, and production.

By using ConfigMaps in Kubernetes

What is a ConfigMap?

A ConfigMap solves this problem by separating configuration data from the application code. It is a Kubernetes object that stores non-sensitive configuration information in key-value pairs. Developers can use ConfigMaps to inject configuration data into Pods through environment variables, command-line arguments, or mounted files.

By using ConfigMaps, teams can manage configurations independently, promote reusability across environments, and simplify updates without touching the application code. This separation improves agility, consistency, and maintainability in modern Kubernetes deployments.

There are two ways of creating a config map:

i) The imperative way – without using a ConfigMap definition file
ii) Declarative way by using a Configmap definition file

Creating a ConfigMap

In Kubernetes, you can create a ConfigMap either using kubectl commands or a YAML manifest.

1. Using kubectl (imperative commands):

From literal values:

kubectl create configmap demo-config --from-literal=database_host=172.138.0.1 --from-literal=debug_mode=1 --from-literal=log_level=verbose 

From a file:

kubectl create configmap demo-config --from-file=config.properties

2. Using a YAML manifest (declarative approach):
Create a file config.yaml with the following content:

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

Then apply it to your cluster:

kubectl apply -f config.yaml

This creates a ConfigMap named demo-config that stores your configuration data as key-value pairs, ready to be used by Pods in your cluster.

ConfigMaps and Pods

You can write a Pod spec that attributes to a ConfigMap and configures the container based on the data in the ConfigMap. Note that the Pod and the ConfigMap must exist in the same namespace.

Let’s look at an instance now, ConfigMap, with some keys with single values and other keys where the value looks like a fragment of a configuration format.

apiVersion: v1
kind: ConfigMap
metadata:
  ...
data:
  ...
immutable: true

There are four various ways you can use a ConfigMap to configure a container in a Pod:

1. Entrypoint of the containers via command line.
2. Environment variables for a container.
3. Also, we can add a file in read-only volume for the application to read.
4. Manually written Code to run inside the Pod that uses the K8s API to read a ConfigMap.

Using ConfigMaps

ConfigMaps can be mounted as data volumes. Other parts of the system can also use ConfigMaps without being directly exposed to the Pod. For example, ConfigMaps can hold data that different system parts should use for configuration. The usual way of using ConfigMaps is to configure environments for containers running in a Pod in the same namespace. You can also use ConfigMap separately.

Immutable ConfigMaps

The K8s beta feature Immutable Secrets and ConfigMaps gives an option to set specific Secrets and ConfigMaps as immutable. And for clusters that extensively use ConfigMaps, restricting modifications to their data has the following advantages:

• Protects you from accidental updates that could cause applications outages
• Improves the performance of your cluster by significantly reducing the load on the Kube-API server by closing watches for ConfigMaps marked as immutable.

The Immutable Ephemeral Volumes control this feature gate. You can build an immutable ConfigMap by fixing the immutable field to true. For example:

apiVersion: v1

kind: ConfigMap

metadata:

...

data:

...

immutable: true

Best Practices for ConfigMaps

1. Use for non-sensitive data only – Do not store passwords, API keys, or other confidential information; use Secrets instead.
2. Keep ConfigMaps small – ConfigMaps have a 1 MB size limit. For large files or data, use Volumes instead.
3. Use immutable ConfigMaps when possible – Prevents accidental changes and ensures consistent configuration.
4. Name clearly and consistently – Use descriptive names that indicate purpose and environment (e.g., dev-db-config).
5. Version your ConfigMaps – When updating configuration, create a new ConfigMap instead of modifying the existing one to avoid conflicts in running Pods.
6. Mount carefully – When mounting ConfigMaps as volumes, ensure file paths inside Pods do not conflict with container files.
7. Monitor updates – Remember that Pods do not automatically reload updated ConfigMaps; plan for Pod restarts if needed.

Where are ConfigMaps stored in Kubernetes?

ConfigMaps are stored as API objects in the cluster’s etcd datastore.

They are managed by the Kubernetes API server and can be accessed or modified using kubectl or the Kubernetes API.

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.

ConfigMap Updates

The ConfigMaps can be 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.

ConfigMap V/s Secrets

Common interview Questions

1. What is a Kubernetes ConfigMap, and why is it used?

A ConfigMap is a Kubernetes object that stores non-sensitive configuration data in key-value pairs. It helps separate configuration from application code, allowing developers to modify configurations without rebuilding or redeploying containers.

2. How is a ConfigMap different from a Kubernetes Secret?

A ConfigMap stores non-sensitive data in plain text, while a Secret stores sensitive data (like passwords or tokens) in a base64-encoded and encrypted form. Secrets are designed for confidential information, whereas ConfigMaps are for general configuration data.

3. What are the different ways to create a ConfigMap in Kubernetes?

There are two main ways:

• Imperative method: Using kubectl create configmap commands.
• Declarative method: Creating a YAML manifest file and applying it using kubectl apply -f <filename>.

4. How can you use a ConfigMap inside a Pod?

ConfigMaps can be used in Pods in four ways:

• As environment variables
• As command-line arguments
• As mounted volumes (files inside the container)
• Through Kubernetes API calls within application code

5. What happens when a ConfigMap is updated — do Pods automatically reflect the changes?

No. Pods do not automatically reload updated ConfigMaps. If a ConfigMap changes, the Pods that use it must be restarted or redeployed to reflect the new configuration values.

6. What is an Immutable ConfigMap and when should you use it?

An Immutable ConfigMap is read-only and cannot be modified once created. It’s useful for production environments where you want to prevent accidental changes and improve cluster performance by reducing API server load.

7. How do you mount a ConfigMap as a volume in a Pod?

You can mount it by defining a volumes section in your Pod YAML:

volumes:
  - name: config-volume
    configMap:
      name: my-config

and refer to it in volumeMounts within the container specification.

8. Where are ConfigMaps stored in Kubernetes?

ConfigMaps are stored as Kubernetes API objects in the cluster’s etcd key-value datastore. They can be managed via the Kubernetes API server or kubectl commands.

9. Can you store binary data in a ConfigMap? How?

Yes. You can use the binaryData field in the YAML definition of a ConfigMap to store base64-encoded binary data, while the data field is reserved for plain text strings.

10. What are some best practices for managing ConfigMaps in production?

• Use ConfigMaps only for non-sensitive data.
• Keep them small and organized.
• Use immutable ConfigMaps when possible.
• Version your ConfigMaps instead of editing existing ones.
• Use descriptive naming conventions (e.g., dev-db-config, prod-app-config).
• Monitor and automate Pod restarts when configuration changes.

Conclusion

Kubernetes ConfigMaps are a fundamental component for managing configuration data in containerized applications. By separating configuration from application code, ConfigMaps enable teams to deploy, update, and scale applications more efficiently without rebuilding container images for every change. They provide flexibility in injecting configuration through environment variables, command-line arguments, or mounted volumes, making applications more adaptable across environments such as development, staging, and production.

Using ConfigMaps promotes better organization, reusability, and consistency, while features like immutable ConfigMaps help prevent accidental changes and improve cluster performance. When combined with Kubernetes Secrets for sensitive data, ConfigMaps support secure and maintainable application deployments. Following best practices—such as versioning, clear naming, and proper scoping within namespaces—ensures that your applications remain stable, secure, and easy to manage.