> ## 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.

# Demo Config Maps

> Explains creating and consuming a Kubernetes ConfigMap from a Deployment, showing manifests, configMapKeyRef usage, troubleshooting CreateContainerConfigError when ConfigMap is missing, and recovery steps.

This lesson demonstrates how to create and consume a Kubernetes ConfigMap from a Deployment (example: CartsDB). You'll see:

* The ConfigMap manifest and the key/value pairs it stores.
* The relevant Deployment snippet that consumes those keys via `configMapKeyRef`.
* The commands and expected behavior when the Deployment is applied before the ConfigMap exists, and what changes after the ConfigMap is created.

## ConfigMap manifest

File: `carts-configmap.yaml`

```yaml theme={null}
apiVersion: v1
kind: ConfigMap
metadata:
  name: cartsdb-config
data:
  MONGODB_USER: "sock-user"
  MONGODB_DATABASE: "data"
```

This ConfigMap stores simple key/value pairs:

| Key | Value |
| - | - |
| `MONGODB_USER` | `sock-user` |
| `MONGODB_DATABASE` | `data` |

ConfigMaps are intended for non-sensitive configuration data. For secrets, use Kubernetes Secrets instead.

## Deployment snippet that consumes the ConfigMap

File: `carts-db-deployment.yaml`

This is the essential part of the Deployment that consumes the ConfigMap values via `configMapKeyRef`. It focuses on the container, ports, and environment variables:

```yaml theme={null}
apiVersion: apps/v1
kind: Deployment
metadata:
  name: carts-db
  labels:
    name: carts-db
spec:
  replicas: 1
  selector:
    matchLabels:
      name: carts-db
  template:
    metadata:
      labels:
        name: carts-db
    spec:
      containers:
      - name: carts-db
        image: centos/mongodb-34-centos7
        ports:
          - containerPort: 27017
        env:
          - name: MONGODB_USER
            valueFrom:
              configMapKeyRef:
                name: cartsdb-config
                key: MONGODB_USER
          - name: MONGODB_PASSWORD
            value: password
          - name: MONGODB_DATABASE
            valueFrom:
              configMapKeyRef:
                name: cartsdb-config
                key: MONGODB_DATABASE
          - name: MONGODB_ADMIN_PASSWORD
            value: admin
        volumeMounts:
          - mountPath: /tmp
            name: tmp-volume
      volumes:
        - name: tmp-volume
          emptyDir: {}
```

Note how `env.valueFrom.configMapKeyRef` references both:

* the ConfigMap resource name: `cartsdb-config`
* the specific key within it: `MONGODB_USER` and `MONGODB_DATABASE`

The ConfigMap must exist in the same namespace so the kubelet can populate those environment variables when creating the container.

A ConfigMap is a separate Kubernetes resource. If the Deployment references a ConfigMap that does not exist when the Pod is created, the Pod will fail to start with an error like CreateContainerConfigError until the ConfigMap is created.

## Reproduce the failure (apply Deployment before ConfigMap)

Try deploying the Deployment before creating the ConfigMap to observe the failure:

```bash theme={null}
# Apply the Deployment (without having created the ConfigMap)
oc apply -f carts-db-deployment.yaml
```

When the referenced ConfigMap doesn't exist, the Pod will fail to start. In the OpenShift console the Pod status will show `CreateContainerConfigError` (example screenshot):

![Screenshot of the Red Hat OpenShift web console showing the "Pods" view in the default project. A pod named "carts-db-67d8869bbf-..." is listed with status "CreateContainerConfigError" and 0/1 ready.](https://mintcdn.com/kodekloud-c4ac6d9a/_-d-o-x8WFPLT_DD/images/OpenShift-4/OpenShift-Security/Demo-Config-Maps/openshift-pods-carts-db-createcontainerconfigerror-0-1.jpg?fit=max\&auto=format\&n=_-d-o-x8WFPLT_DD\&q=85\&s=1b873c5f758459fae88a6b40c9ad5f21)

Inspect the Pod events in the console or run:

```bash theme={null}
# Describe the failing Pod to see the event saying the ConfigMap was not found
oc describe pod `oc get pod -l name=carts-db -o name` 
# Or target a specific pod:
# oc describe pod `oc get pod -l name=carts-db -o jsonpath='{.items[0].metadata.name}'`
```

You will see an event explaining that the ConfigMap `cartsdb-config` was not found.

## Create the ConfigMap and recover the Pod

Create the ConfigMap, then reapply the Deployment or delete the failed Pod so the ReplicaSet recreates it:

```bash theme={null}
# Create the ConfigMap
oc apply -f carts-configmap.yaml

# Optionally reapply the Deployment (harmless) or delete the failed pod to trigger a recreate:
oc apply -f carts-db-deployment.yaml
# Or delete the Pod to let the Deployment create a new one:
# oc delete pod -l name=carts-db
```

Example output when creating the ConfigMap:

```text theme={null}
$ oc apply -f carts-configmap.yaml
configmap/cartsdb-config created
```

After the ConfigMap exists, the Pod can resolve the referenced keys and should transition to `Running`. Example OpenShift console view showing the Pod in `Running` state:

![A screenshot of the Red Hat OpenShift web console showing Pod details for "carts-db-67d8869bbf-nk974" in the "default" project with status "Running." The page displays metadata like namespace, labels, restart policy and Pod IP, with the left sidebar highlighting Workloads → Pods.](https://mintcdn.com/kodekloud-c4ac6d9a/_-d-o-x8WFPLT_DD/images/OpenShift-4/OpenShift-Security/Demo-Config-Maps/openshift-pod-carts-db-default.jpg?fit=max\&auto=format\&n=_-d-o-x8WFPLT_DD\&q=85\&s=d787e08e1b37b3846d0aba5e5a1e485a)

You can also inspect the Pod YAML to confirm metadata and IP information:

```yaml theme={null}
status:
  podIP: 10.217.0.183
  podIPs:
    - ip: 10.217.0.183
metadata:
  resourceVersion: "83802"
  name: carts-db-67d8869bbf-nk974
  uid: ec5385a7-a1a0-468a-88c6-ef277eba3561
```

## Quick reference

| Resource | Purpose | Example command |
| - | - | - |
| ConfigMap | Store non-sensitive configuration as key/value pairs | `oc apply -f carts-configmap.yaml` |
| Deployment | Consume ConfigMap via `env.valueFrom.configMapKeyRef` | `oc apply -f carts-db-deployment.yaml` |
| Pod troubleshooting | View events when Pod fails to start | `oc describe pod <pod-name>` |

## Links and further reading

* [Kubernetes ConfigMap documentation](https://kubernetes.io/docs/concepts/configuration/configmap/)
* [OpenShift CLI (oc) reference](https://docs.openshift.com/)

## Summary

* Store non-sensitive configuration data in a ConfigMap as key/value pairs.
* Reference ConfigMap values from a Pod using `env.valueFrom.configMapKeyRef`.
* Ensure the ConfigMap exists before the Pod is created; otherwise the Pod will fail with `CreateContainerConfigError`.
* For secrets or sensitive information, use Kubernetes Secrets instead of ConfigMaps.

Do not store sensitive credentials in a ConfigMap. Use Kubernetes Secrets for passwords, tokens, and private keys.

> **[Watch Video](https://learn.kodekloud.com/user/courses/openshift-4/module/413252bb-7455-41fa-86eb-e3e9370c8f08/lesson/4b17b12d-e0d3-44b8-ba95-b05c1f11133c)**


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.