Using ConfigMaps as environment variables in Kubernetes - Step-by-Step Execution

Process Flow - Using ConfigMaps as environment variables

Create ConfigMap with key-value pairs

↓

Define Pod spec referencing ConfigMap

↓

Pod starts, Kubernetes injects env vars

↓

Container reads env vars from ConfigMap

↓

Application uses env vars at runtime

This flow shows how a ConfigMap is created and then used to inject environment variables into a Kubernetes Pod, which the containerized app can access.

Execution Sample

Kubernetes

kubectl create configmap app-config --from-literal=APP_MODE=production

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: app
    image: busybox
    envFrom:
    - configMapRef:
        name: app-config

Creates a ConfigMap with APP_MODE=production and a Pod that uses this ConfigMap to set environment variables in its container.

Process Table

Step	Action	Resource Affected	Result	Notes
1	Create ConfigMap 'app-config' with APP_MODE=production	ConfigMap	ConfigMap 'app-config' created	ConfigMap stores key-value pairs
2	Define Pod spec referencing ConfigMap 'app-config'	Pod spec	Pod spec includes envFrom with configMapRef	Pod will use ConfigMap for env vars
3	Apply Pod spec to cluster	Pod	Pod 'example-pod' created and scheduled	Pod starts running
4	Kubernetes injects env vars from ConfigMap into container	Container environment	Container env var APP_MODE=production set	Env vars available inside container
5	Container application reads APP_MODE env var	Application runtime	APP_MODE=production accessible	App can use config values dynamically
6	Pod runs normally with env vars	Pod status	Pod Running	Execution complete

💡 Pod is running with environment variables injected from ConfigMap

Status Tracker

Variable	Start	After Step 1	After Step 4	Final
ConfigMap 'app-config'	Not created	Created with APP_MODE=production	Unchanged	Exists with APP_MODE=production
Pod environment variable APP_MODE	Not set	Not set	Set to 'production'	Set to 'production'

Key Moments - 3 Insights

Why doesn't the environment variable appear in the container before the Pod starts?

Environment variables from ConfigMaps are injected only when the Pod starts and the container is created, as shown in step 4 of the execution_table.

What happens if the ConfigMap is changed after the Pod is running?

The running Pod's environment variables do not update automatically; the Pod must be restarted to pick up ConfigMap changes, as environment variables are set at container start.

Can multiple ConfigMaps be used to set environment variables in one Pod?

Yes, multiple ConfigMaps can be referenced using multiple envFrom entries or individual env entries, but each must be defined explicitly in the Pod spec.

Visual Quiz - 3 Questions

Look at the execution_table, at which step is the environment variable APP_MODE set inside the container?

A Step 2

B Step 4

C Step 1

D Step 6

💡 Hint

Check the 'Result' column in step 4 where container env var APP_MODE=production is set.

According to variable_tracker, what is the value of APP_MODE after step 1?

A production

B undefined

C Not set

D null

💡 Hint

Step 1 creates the ConfigMap but environment variables are injected later, see variable_tracker row for APP_MODE.

If the Pod is restarted after changing the ConfigMap, what will happen to the environment variable APP_MODE?

A It updates to the new ConfigMap value

B It remains the old value

C It becomes empty

D Pod fails to start

💡 Hint

Refer to key_moments about ConfigMap changes requiring Pod restart to update env vars.

Concept Snapshot

Create a ConfigMap with key-value pairs
Reference it in Pod spec using envFrom with configMapRef
When Pod starts, env vars from ConfigMap are injected into container
App reads env vars at runtime
Changes to ConfigMap require Pod restart to take effect

Full Transcript

This visual execution shows how to use Kubernetes ConfigMaps as environment variables in Pods. First, a ConfigMap named 'app-config' is created with a key APP_MODE set to 'production'. Then, a Pod specification is defined that references this ConfigMap under the envFrom field. When the Pod is applied and starts running, Kubernetes injects the environment variables from the ConfigMap into the container. The containerized application can then read these environment variables at runtime. The environment variables are only set when the Pod starts, so changes to the ConfigMap after the Pod is running require restarting the Pod to update the environment variables. This method allows configuration to be managed separately from container images and easily updated.

Practice

1. What is the main purpose of using a ConfigMap in Kubernetes when setting environment variables for a pod?

easy

A. To separate configuration data from application code for easier updates

B. To store container images for pods

C. To manage network policies between pods

D. To define resource limits for containers

Solution

1. Step 1: Understand ConfigMap role

   ConfigMaps hold configuration data separately from app code, allowing updates without rebuilding images.

2. Step 2: Identify correct purpose

   Among options, only separating config data matches ConfigMap's main use for environment variables.

3. Final Answer:

   To separate configuration data from application code for easier updates -> Option A

4. Quick Check:

   ConfigMap purpose = separate config data [OK]

Hint: ConfigMaps separate config from code for flexible env vars [OK]

Common Mistakes:

• Confusing ConfigMaps with container images
• Thinking ConfigMaps manage network or resources
• Using ConfigMaps to store secrets (use Secrets instead)

2. Which of the following is the correct syntax to load all keys from a ConfigMap named app-config as environment variables in a pod spec?

easy

A. envFrom:
- configMapRef:
name: app-config

B. env:
- name: app-config
valueFrom:
configMapKeyRef:
name: app-config

C. configMap:
name: app-config

D. envFrom:
- secretRef:
name: app-config

Solution

1. Step 1: Identify correct envFrom usage

   To load all keys as env vars, use envFrom with configMapRef and the ConfigMap name.

2. Step 2: Check options for syntax correctness

   envFrom: - configMapRef: name: app-config correctly uses envFrom with configMapRef. Others misuse keys or use secretRef incorrectly.

3. Final Answer:

   envFrom: - configMapRef: name: app-config -> Option A

4. Quick Check:

   Use envFrom + configMapRef for all keys [OK]

Hint: Use envFrom with configMapRef to load all keys [OK]

Common Mistakes:

• Using env instead of envFrom for all keys
• Confusing configMapRef with secretRef
• Missing indentation or wrong key names

3. Given this pod spec snippet, what environment variables will be available inside the container?

envFrom:
  - configMapRef:
      name: my-config

And the ConfigMap my-config contains keys: API_URL=https://api.example.com and TIMEOUT=30.

medium

A. Only API_URL=https://api.example.com

B. API_URL=https://api.example.com and TIMEOUT=30

C. Only TIMEOUT=30

D. No environment variables will be set

Solution

1. Step 1: Understand envFrom with configMapRef

   Using envFrom with configMapRef loads all keys from the ConfigMap as environment variables.

2. Step 2: Check ConfigMap keys

   The ConfigMap has two keys: API_URL and TIMEOUT, so both become env vars.

3. Final Answer:

   API_URL=https://api.example.com and TIMEOUT=30 -> Option B

4. Quick Check:

   envFrom loads all keys as env vars [OK]

Hint: envFrom loads all ConfigMap keys as env vars [OK]

Common Mistakes:

• Assuming only one key loads at a time
• Confusing envFrom with env and missing keys
• Thinking ConfigMap keys are not environment variables

4. You applied this pod spec to use a ConfigMap as environment variables, but the container does not see the variables. What is wrong?

envFrom:
  - configMapRef:
      name: wrong-config-name

The ConfigMap you created is named app-config.

medium

A. The pod spec must use secretRef instead of configMapRef

B. envFrom cannot be used to load ConfigMaps

C. ConfigMaps cannot be used as environment variables

D. The ConfigMap name in the pod spec does not match the actual ConfigMap name

Solution

1. Step 1: Compare ConfigMap names

   The pod spec references wrong-config-name, but the actual ConfigMap is app-config.

2. Step 2: Understand impact of name mismatch

   If names don't match, Kubernetes cannot find the ConfigMap, so env vars won't be set.

3. Final Answer:

   The ConfigMap name in the pod spec does not match the actual ConfigMap name -> Option D

4. Quick Check:

   ConfigMap name must match exactly [OK]

Hint: Check ConfigMap name spelling matches pod spec [OK]

Common Mistakes:

• Using secretRef instead of configMapRef incorrectly
• Assuming envFrom can't load ConfigMaps
• Ignoring case sensitivity in names

5. You want to update environment variables in a running pod without rebuilding the container image. Which approach using ConfigMaps is correct?

hard

A. Use a Secret instead of ConfigMap for environment variables

B. Modify the container image to include new environment variables

C. Create or update a ConfigMap and reference it with envFrom in the pod spec, then restart the pod

D. Edit the pod spec to add environment variables directly and redeploy the image

Solution

1. Step 1: Understand ConfigMap update workflow

   ConfigMaps allow updating config data separately; updating the ConfigMap and restarting the pod applies new env vars without rebuilding images.

2. Step 2: Evaluate options for best practice

   Create or update a ConfigMap and reference it with envFrom in the pod spec, then restart the pod correctly uses ConfigMap with envFrom and pod restart. Others require image rebuild or confuse Secrets with ConfigMaps.

3. Final Answer:

   Create or update a ConfigMap and reference it with envFrom in the pod spec, then restart the pod -> Option C

4. Quick Check:

   Update ConfigMap + restart pod for new env vars [OK]

Hint: Update ConfigMap and restart pod, no image rebuild needed [OK]

Common Mistakes:

• Rebuilding container image unnecessarily
• Confusing Secrets with ConfigMaps for non-sensitive data
• Editing pod spec without restarting pod