Updating ConfigMaps and propagation in Kubernetes - Step-by-Step Execution

Process Flow - Updating ConfigMaps and propagation

Create or Update ConfigMap

↓

ConfigMap Stored in API Server

↓

Pods Reference ConfigMap

↓

Pod Restart or Reload Needed?

No→No Change in Pod

Yes↓

Pod Restart or Reload

↓

Pod Uses Updated ConfigMap

This flow shows how updating a ConfigMap affects pods: after updating, pods must restart or reload to use new data.

Execution Sample

Kubernetes

kubectl create configmap app-config --from-literal=key=oldvalue
kubectl get configmap app-config -o yaml
kubectl create configmap app-config --from-literal=key=newvalue -o yaml --dry-run=client | kubectl apply -f -
kubectl rollout restart deployment/myapp

Create a ConfigMap, check it, update it with new data, then restart pods to apply changes.

Process Table

Step	Command	Action	Result	Pod State
1	kubectl create configmap app-config --from-literal=key=oldvalue	Create ConfigMap	ConfigMap 'app-config' created with key=oldvalue	Pods use oldvalue
2	kubectl get configmap app-config -o yaml	View ConfigMap	Shows key=oldvalue	Pods still use oldvalue
3	kubectl create configmap app-config --from-literal=key=newvalue -o yaml --dry-run=client | kubectl apply -f -	Update ConfigMap	ConfigMap 'app-config' updated with key=newvalue	Pods still use oldvalue
4	kubectl rollout restart deployment/myapp	Restart Pods	Pods restarting to pick up new ConfigMap	Pods now use newvalue
5	Pods running with updated ConfigMap	Pods running	Pods use updated ConfigMap key=newvalue	Pods use newvalue

💡 Pods must restart or reload to use updated ConfigMap; update alone does not change running pods.

Status Tracker

Variable	Start	After Step 1	After Step 3	After Step 4	Final
ConfigMap key value	none	oldvalue	newvalue	newvalue	newvalue
Pod ConfigMap data	none	oldvalue	oldvalue	newvalue	newvalue
Pod state	not running	running	running	restarting	running

Key Moments - 2 Insights

Why do pods not immediately use the updated ConfigMap after step 3?

Because pods load ConfigMap data at start, they keep using the old data until restarted or reloaded, as shown in execution_table row 3.

What does 'kubectl rollout restart' do in this context?

It restarts pods so they reload the updated ConfigMap, changing pod state from running old config to running new config (see execution_table row 4).

Visual Quiz - 3 Questions

Look at the execution table, what is the ConfigMap key value after step 3?

A oldvalue

B none

C newvalue

D undefined

💡 Hint

Check the 'Result' column in row 3 showing ConfigMap updated with key=newvalue.

At which step do pods start using the updated ConfigMap value?

A Step 3

B Step 4

C Step 2

D Step 1

💡 Hint

Look at 'Pod State' column; pods use newvalue only after restart in step 4.

If you skip 'kubectl rollout restart', what happens to pods?

A Pods continue using old ConfigMap data

B Pods crash immediately

C Pods automatically reload ConfigMap

D Pods delete ConfigMap

💡 Hint

Refer to execution_table row 3 and 5 showing pods still use oldvalue without restart.

Concept Snapshot

Updating ConfigMaps:
- Use 'kubectl create configmap' or 'kubectl apply' to update
- Pods do NOT auto-refresh ConfigMap data
- Restart or reload pods to apply changes
- Use 'kubectl rollout restart' for deployments
- Without restart, pods keep old config

Full Transcript

This lesson shows how updating a Kubernetes ConfigMap affects running pods. First, a ConfigMap is created with a key-value pair. When updated, the ConfigMap data changes in the cluster, but pods keep using the old data until they restart or reload. Restarting pods forces them to read the new ConfigMap values. The key commands are creating/updating the ConfigMap and restarting pods with 'kubectl rollout restart'. Without restarting, pods do not see the new ConfigMap values. This is important to remember when managing configuration changes in Kubernetes.