> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Configuring ConfigMaps in Applications
> Managing application configuration in Kubernetes using ConfigMaps to separate non-sensitive settings from Pod specs and inject them as environment variables or mounted files.
In this lesson you'll learn how to manage application configuration in Kubernetes using ConfigMaps. ConfigMaps let you separate non-sensitive configuration from Pod specs so you can manage settings centrally, avoid duplication across manifests, and make your deployments more maintainable.
Why use ConfigMaps?
* Reduce duplication of environment variables across many Pod manifests.
* Separate configuration from container images and deployment logic.
* Make configuration updates without rebuilding container images (depending on consumption method).
Basic workflow
1. Create a ConfigMap that contains key/value configuration data.
2. Inject the ConfigMap into one or more Pods as environment variables or mounted files.
Example key-value pairs we want to manage:
```text theme={null}
APP_COLOR: blue
APP_MODE: prod
```
Example: embedding env vars directly (NOT recommended at scale)
```yaml theme={null}
apiVersion: v1
kind: Pod
metadata:
name: simple-webapp-color
spec:
containers:
- name: simple-webapp-color
image: simple-webapp-color
ports:
- containerPort: 8080
env:
- name: APP_COLOR
value: blue
```
When managing many manifests, duplicating values like the example above becomes hard to maintain. ConfigMaps solve this.
Ways to create ConfigMaps
There are two main approaches: imperatively with `kubectl` and declaratively with YAML manifests.
| Method | When to use | Example |
| - | - | - |
| Imperative — from literals | Quick, ad-hoc values or one-off testing | `kubectl create configmap app-config --from-literal=APP_COLOR=blue --from-literal=APP_MODE=prod` |
| Imperative — from files | Load configuration from files (each filename becomes a key) | `kubectl create configmap app-config --from-file=app.properties` |
| Declarative — YAML manifest | Recommended for production: version-controlled, repeatable | See manifest example below and run `kubectl apply -f app-config.yaml` |
Imperative creation (from literals)
* Use `--from-literal` to add key/value pairs directly.
```bash theme={null}
kubectl create configmap app-config \
--from-literal=APP_COLOR=blue \
--from-literal=APP_MODE=prod
```
Repeat `--from-literal` for additional keys. Good for a small number of items; less practical for many entries.
Imperative creation (from files)
* Use `--from-file` to create keys from file names. The file content becomes the value.
```bash theme={null}
kubectl create configmap app-config --from-file=app.properties
```
If `app.properties` contains arbitrary content, the ConfigMap stores it under the key `app.properties`.
Declarative creation (YAML manifest)
* Preferred for repeatability and GitOps workflows. Create `app-config.yaml`:
```yaml theme={null}
apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
data:
APP_COLOR: "blue"
APP_MODE: "prod"
```
Apply the manifest:
```bash theme={null}
kubectl apply -f app-config.yaml
```
You can create multiple ConfigMaps (for example `mysql-config`, `redis-config`) and name them to reflect their purpose.
View and inspect ConfigMaps
* List ConfigMaps:
```bash theme={null}
kubectl get configmaps
```
Sample output:
```bash theme={null}
$ kubectl get configmaps
NAME DATA AGE
app-config 2 3s
```
* Describe a specific ConfigMap to inspect keys and values:
```bash theme={null}
kubectl describe configmap app-config
```
Sample output:
```bash theme={null}
$ kubectl describe configmap app-config
Name: app-config
Namespace: default
Labels:
Annotations:
Data
====
APP_COLOR:
----
blue
APP_MODE:
----
prod
Events:
```
How to inject ConfigMap data into Pods
There are three common consumption patterns. Choose the one that best fits your application:
| Consumption method | Description | Example |
| - | - | - |
| Import all keys as env vars (`envFrom`) | Expose every key in the ConfigMap as an environment variable | see `envFrom` example below |
| Single env var from a specific key (`valueFrom.configMapKeyRef`) | Map a specific ConfigMap key to a single env var | see `configMapKeyRef` example below |
| Mount keys as files (volume) | Each ConfigMap key becomes a file with the value as file content | see volume mount example below |
1. Import all keys into environment variables (envFrom)
* Use `envFrom` to import all key-value pairs from the named ConfigMap into the container environment:
```yaml theme={null}
apiVersion: v1
kind: Pod
metadata:
name: simple-webapp-color
spec:
containers:
- name: simple-webapp-color
image: simple-webapp-color
ports:
- containerPort: 8080
envFrom:
- configMapRef:
name: app-config
```
This populates `APP_COLOR=blue` and `APP_MODE=prod` in the container environment.
2. Map a single key to a single environment variable
* Use `valueFrom.configMapKeyRef` when you only need one specific key:
```yaml theme={null}
env:
- name: APP_COLOR
valueFrom:
configMapKeyRef:
name: app-config
key: APP_COLOR
```
3. Mount ConfigMap keys as files in a volume
* Mount the ConfigMap as a volume so that each key appears as a file under the mount path:
```yaml theme={null}
volumes:
- name: app-config-volume
configMap:
name: app-config
containers:
- name: simple-webapp-color
image: simple-webapp-color
volumeMounts:
- name: app-config-volume
mountPath: /etc/config
```
Files appear at `/etc/config/APP_COLOR` and `/etc/config/APP_MODE`, with file contents equal to the values.
Best practices and important notes
ConfigMaps are not intended for sensitive data (such as passwords). Use Secrets for sensitive configuration. Also prefer declarative manifests (`kubectl apply -f`) for repeatability and version control.
Quick tips
* Use clear, descriptive ConfigMap names because Pods reference them by name.
* Prefer declarative YAML for production and CI/CD pipelines.
* When mounting ConfigMaps as files, applications that read filesystem-based configs can pick up changes if they re-read files (watching/reload behavior varies by app).
* To update a ConfigMap and ensure Pods pick up changes, you may need to restart or roll the Pods (depending on how the app consumes the data).
What we covered
* Why separate configuration from Pod manifests.
* How to create ConfigMaps imperatively (`--from-literal`, `--from-file`) and declaratively (YAML).
* How to view and describe ConfigMaps (`kubectl get` / `kubectl describe`).
* How to inject ConfigMap data into Pods using `envFrom`, `valueFrom.configMapKeyRef`, and volume mounts.
Links and references
* Kubernetes ConfigMap documentation: [https://kubernetes.io/docs/concepts/configuration/configmap/](https://kubernetes.io/docs/concepts/configuration/configmap/)
* Kubernetes API reference: [https://kubernetes.io/docs/reference/generated/kubernetes-api/](https://kubernetes.io/docs/reference/generated/kubernetes-api/)
Try it
1. Create a ConfigMap using the YAML manifest above.
2. Create the example Pod that consumes the ConfigMap.
3. Inspect the Pod environment or mounted files to confirm the ConfigMap values are available.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.