Getting Started with ConfigMaps in Kubernetes

We often see .env Files are used to store environment variables and configuration data for applications during development. Ever wonder how Kubernetes handles this when it comes to deploying applications in a Kubernetes cluster?

The answer is ConfigMaps. ConfigMaps are a Kubernetes resource that allows you to store non-sensitive data in key-value pairs. It can be used to inject configuration data into your applications at runtime, making it easier to manage and update configurations without modifying the application code.

ConfigMaps serve a similar purpose in the k8’s (Kubernetes) as .env files do in local development. However, it is important to understand the difference between ConfigMaps and Secrets . While configMaps are intended for non-sensitive data, and the secrets are designed for storing the sensitive data like passwords and tokens. Secrets are encrypted to ensure secure storage unlike configMaps.

We’ll explore the k8s secrets in more detail in the next blog.

For example, below is a sample set of variables that store configuration data for an application:

Is it mandatory to use ConfigMaps in the Kubernetes cluster? No, it’s not mandatory, but it is a good practice. Using ConfigMaps makes it easier to manage and update configurations without modifying the application code. It also helps keep your application code clean and maintainable.

For example, consider a pod definition without using ConfigMaps:

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
    image: nginx
    env:
    - name: ENVIRONMENT
      value: "production"
    - name: LOG_LEVEL
      value: "info"

In this example, the environment variables ENVIRONMENT and LOG_LEVEL are hardcoded in the pod definition. This approach has several drawbacks.

Imagine you have hundreds of pod definitions, and you want to change the ENVIRONMENT variable from production staging. You would have to modify all the pod definitions manually, which can lead to errors and inconsistencies, especially in larger deployments.

Drawbacks:

• Hardcoding configuration values makes it difficult to change them without modifying the pod or deployment definitions.

• It can lead to code duplication if multiple pods require the same configuration.

• It makes the application less flexible and harder to manage in different environments (e.g., development, staging, production).

In short, hardcoding configuration makes application deployment more complex and error-prone.

That’s where ConfigMaps come into play. By using ConfigMaps, you can externalize configuration data and inject it into your pods at runtime, making it easier to manage and update configurations without modifying the application code.

ConfigMaps are just another object in Kubernetes, like pods, deployments, or services. They are used to store non-sensitive data in key-value pairs, allowing you to decouple configuration from application code. This makes it easier to manage configurations across different environments and deployments.

Let’s see an example of how to create a ConfigMap in Kubernetes.
First, you can check for existing ConfigMaps in your Cluster using this command:

kubectl get configmaps

or

kubectl get cm

You will see a list of ConfigMaps in the cluster, including the default one. kube-root-ca.crt (in a local setup), which stores the CA certificate for the Kubernetes API server.

Before creating a ConfigMap, there are a few ways to do it in Kubernetes:

1. From Literal Values (Imperative):
   You can create a ConfigMap directly from key-value pairs using the kubectl create configmap Command. For example:

    kubectl create configmap my-config --from-literal=ENVIRONMENT=production --from-literal=LOG_LEVEL=info
   

   This command creates a ConfigMap named my-config With two key-value pairs.

   You can verify the created ConfigMap by running:

    kubectl get cm
   

   (Note: I use cm as an alias for configmapsYou can use configmaps as well.)

   To see the details of the created ConfigMap:

    kubectl describe cm my-config
   

   

   You can also edit the ConfigMap using:

    kubectl edit cm my-config
   

   This will open the ConfigMap in your default editor, allowing you to modify it.

   This is one imperative way of creating a ConfigMap. It’s not commonly used, but it’s a quick way to create a ConfigMap for testing or development purposes.

2. From a File (Declarative):
   You can create a ConfigMap from a file containing key-value pairs. For example, if you have a file named example-cm.yml With the following content:

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: my-config
    data:
      ENVIRONMENT: production
      LOG_LEVEL: info
   

   You can create the ConfigMap using:

    kubectl apply -f example-cm.yml
   

   This command creates a ConfigMap named my-config With the key-value pairs defined in the file.

As usual, you can use the above commands to verify, describe, and edit the ConfigMap.

Where is this ConfigMap used?
You can use the ConfigMap in your pod or deployment definitions to inject configuration data into your application. For example, here’s a pod definition using a ConfigMap:

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
    image: nginx
    envFrom:
    - configMapRef:
        name: my-config

In this example, the envFrom field references the my-config ConfigMap. This means the environment variables defined in the ConfigMap will be injected into the container as environment variables. You can also use the env field to pick specific environment variables from the ConfigMap instead of all variables:

env:
- name: ENVIRONMENT
  valueFrom:
    configMapKeyRef:
      name: my-config
      key: ENVIRONMENT

This allows you to use specific keys from the ConfigMap as environment variables in your container.

You can see more examples of using ConfigMaps in the Kubernetes documentation.

First, make sure you have created the ConfigMap before applying the pod definition. After that, you can apply the pod definition.

How do you know the pod is using the ConfigMap?
You can check the pod description to see if the ConfigMap is referenced correctly under the variable "Environment Variables from:".

The best way to check if the ConfigMap is working correctly is to exec into the pod and check the environment variables. Use the following command to exec into the pod:

kubectl exec -it example-pod -- sh

Now you are inside the pod. Check the environment variables using:

env

You should see the environment variables defined in the ConfigMap, such as ENVIRONMENT and LOG_LEVEL. This confirms that the ConfigMap is being used by the pod.
(You will also see some default environment variables set by Kubernetes.)

You can check individual environment variables as well:

echo $ENVIRONMENT

echo $LOG_LEVEL

You should see the values defined in the ConfigMap.

What if you face the error CreateContainerConfigError When working with ConfigMaps?
This error occurs when the pod is unable to start due to a misconfiguration in the ConfigMap or if the ConfigMap does not exist. To troubleshoot this error, check the following:

• Make sure the ConfigMap exists in the Kubernetes cluster:

    kubectl get cm
  

• Ensure you are correctly referencing the ConfigMap in your pod or deployment definition. Check the name field in the configMapRef to ensure it matches the name of the ConfigMap you created.

• Check the pod description for any errors related to the ConfigMap:

    kubectl describe pod example-pod
  

  Look for error messages related to the ConfigMap in the output. Common issues include:

  • The ConfigMap does not exist.

  • The ConfigMap is not in the same namespace as the pod.

  • The ConfigMap is not correctly referenced in the pod definition.

  • The keys in the ConfigMap do not match the expected environment variable names in the pod definition.

  • The ConfigMap is empty or does not contain the expected keys.

  • RBAC or other misconfigurations etc….

That’s it! You have successfully created and used a ConfigMap in Kubernetes. ConfigMaps are a powerful way to manage configuration data in your applications, making it easier to update and maintain configurations without modifying the application code.

You can also delete the ConfigMap using:

kubectl delete cm my-config

Finally, that’s it for this blog on ConfigMaps in Kubernetes. I hope you found it helpful and informative. If you have any questions or feedback, feel free to leave a comment below. Happy Kuberneting! 🚀

If you found this helpful, please support me by following my blog and sharing it with your friends. You can also check out my other blogs on Kubernetes and DevOps.