Kubernetes ConfigMaps Explained with Examples – Managing Application Configuration in Pods
Hello DevOps and DevSecOps enthusiasts!
Welcome back to another Kubernetes learning posts,
In Today's article we will explore the most commonly used Kubernetes object: ConfigMaps (cm), This is like any other object we can create, get, delete and describe ConfigMaps.
As applications move to containers and Kubernetes, separating configuration from application code becomes extremely important. Hardcoding configuration values such as database URLs, API endpoints, application properties, and environment-specific settings makes deployments difficult to manage across Development, Testing, Staging, and Production environments.
Kubernetes solves this problem using ConfigMaps.
A ConfigMap allows you to store configuration data separately from your container images and inject it into running Pods whenever needed.
If you come from a programming background, you can think of a ConfigMap as being similar to a:
The key difference is that ConfigMaps are Kubernetes-native objects that can be shared across Pods and deployments.
What is ConfigMap in Kubernetes?
ConfigMaps can hold Properties files of an application – For Example Java applications hibernate.properties log4j.properties, logging.conf
Why use ConfigMaps?
| Environment | Database Host |
|---|---|
| Development | dev-db.company.com |
| Testing | test-db.company.com |
| Production | prod-db.company.com |
Without ConfigMaps we need to create each environment with different Image.
With ConfigMaps we can deploy single image for each environment while Kubernetes provide environment specific configurations dynamically.
We can also add JSON files as ConfigMap
Once ConfirMap is created, Kubernetes objects are ready for injecting in running containers to get the new configuration changes.
Creating ConfigMaps
Kubernetes supports several methods to create ConfigMaps.kubectl create configmap [CM NAME] [DATA-SOURCE] kubectl create configmap [configmapName] \
[--from-file file_path]|[--from-literal key=value]
- Directories
- Files
- Literal Values
- YAML manifests
kubectl api-resources (or) kubectl api-resources |grep -i configmap
Verify ConfigMap Resource
kubectl get cm or kubectl get configmapsExample output: Example:
NAME DATA AGE devapp-cm 3 10m prod-cm 3 8m
Method 1: Creating ConfigMaps using Literals
We can use key-value pairs in the command line and Create a simple configmap object using the literal by using --from-literal option:
kubectl create configmap devdb-cm --from-literal=dev.database_ip="192.168.30.2"To check details about the newly created cm devdb-cm
kubectl describe cm devdb-cmNote that you can add multiple key-value pairs as data.
kubectl create configmap devapp-cm \ --from-literal=app.envname="dev" \ --from-literal=app.url="vtdev.com" \ --from-literal=app.mem="1024m" kubectl create configmap prod-cm \ --from-literal=app.envname="prod" \ --from-literal=app.url="vtprod.com" \ --from-literal=app.mem="8096m" kubectl get cm kubectl describe cm devapp-cm kubectl describe cm prod-cm
Method 2: Creating Using Directory
create a directory and have configMap files in it.mkdir cm-dir/; cd cm-dir
echo "admin"> a.properties
echo "dev-env">b.properties
kubectl create configmap app-config --from-file=cm-dir
kubectl get configmaps -o wide
Describe the cm
kubectl describe cm app-config kubectl get configmaps app-config -o yamlobserve the difference using -o yaml and the describe there you can find DATA section.
3: Creating Using a File
Create another ConfigMap using Files redis-fileecho "app.name=web-state app.env=dev" > redis-filecreating...
kubectl create configmap redis-config --from-file=redis-config
Method 4: Declarative way using YAML
In the declarative approch, your YML you must create ConfigMap before refering it in Pod spec or template spec.
apiVersion: v1
kind: Pod
metadata:
name: redis
spec:
containers:
- name: redis
image: kubernetes/redis:v1
volumeMounts:
- mountPath: /redis-master
name: config
volumes:
- name: config
configMap:
name: myredis-config
items:
- key: redis-config
path: redis.conf
You can inject the configMap to a pod, here redis pod included as 'VolumeMounts', volume connects
kubectl apply -f redis-config.yml kubectl exec redis cat /redis-master/redis.conf kubectl exec -it redis redis-cli
Pod associating with ConfigMaps
Using VolumeMounts pointing to Volume
Using env variable map to ConfigMap key reference
Real-World DevOps Use Cases
Java Applications Store:application.properties hibernate.properties log4j.propertiesNGINX web server store:
nginx.confSpring Boot Inject:
database.url database.username database.poolsizeKubernetes Deployments
Provide environment-specific settings without changing container images.
Common interview question: ConfigMap vs Secrets
| ConfigMap | Secret |
|---|---|
| Stores non-sensitive data | Stores sensitive data |
| Plain text | Base64 encoded |
| App configuration | Passwords, API Keys |
| Environment settings | Credentials |
ConfigMap APP_ENV=dev LOG_LEVEL=INFOSecret
DB_PASSWORD API_TOKEN SSH_PRIVATE_KEYImportant Note: Never store passwords in ConfigMaps.
Best Practices for ConfigMaps
Keep Configuration Separate Avoid hardcoding values inside application code.
Use YAML in ProductionVersion control ConfigMaps using Git.
Use NamespacesOrganize configurations per environment.
Use Secrets for Sensitive DataNever place credentials inside ConfigMaps.
Follow GitOps PrinciplesManage ConfigMaps through ArgoCD, FluxCD, or CI/CD pipelines.
Conclusion
ConfigMaps are one of the most important Kubernetes objects for managing application configuration. They help separate configuration from application code, improve portability, and simplify deployments across multiple environments.
Whether you are deploying Java applications, NGINX web servers, Redis instances, or microservices, ConfigMaps provide a flexible and Kubernetes-native way to manage configuration.
As your Kubernetes journey progresses, mastering ConfigMaps will help you build cleaner, more scalable, and production-ready deployments.
Dear Reader Question
How do you currently manage application configuration in Kubernetes—ConfigMaps, Helm values, GitOps repositories, or external configuration management tools?
Let us know in the comments and share your real-world experience with the Kubernetes community.
Comments