Updating ConfigMaps and propagation in Kubernetes - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is a ConfigMap in Kubernetes?

A ConfigMap is a Kubernetes object used to store non-confidential configuration data in key-value pairs. It allows you to separate configuration from container images to keep containers portable.

beginner

How do you update a ConfigMap in Kubernetes?

You can update a ConfigMap by editing it with 'kubectl edit configmap <name>' or by applying a new YAML file with 'kubectl apply -f '.

intermediate

Does updating a ConfigMap automatically update the pods using it?

No, updating a ConfigMap does not automatically update pods. Pods must be restarted or recreated to pick up the new ConfigMap values.

intermediate

What is a common method to propagate ConfigMap changes to running pods?

A common method is to delete pods so that the Deployment or ReplicaSet recreates them with the updated ConfigMap, or to trigger a rolling update by changing pod template annotations.

advanced

Can ConfigMap changes be automatically reflected inside a running container without restart?

ConfigMap changes mounted as files in volumes can be updated inside running containers, but applications must watch and reload the config. Environment variable changes require pod restart.

Which command updates a ConfigMap from a YAML file?

A kubectl apply -f configmap.yaml

B kubectl run configmap.yaml

C kubectl create pod configmap.yaml

D kubectl delete configmap.yaml

Use 'kubectl apply -f' to update or create resources from a YAML file.

After updating a ConfigMap, what must you do to apply changes to pods using it?

A Nothing, pods update automatically

B Restart or recreate the pods

C Run 'kubectl update pods'

D Delete the ConfigMap

Pods do not automatically reload ConfigMap changes; they must be restarted or recreated.

How can you trigger a rolling update to propagate ConfigMap changes?

A Edit the ConfigMap directly inside the pod

B Delete the ConfigMap

C Run 'kubectl scale deployment'

D Change pod template annotations

Changing pod template annotations forces a rolling update, recreating pods with new config.

Which ConfigMap mounting method allows live updates inside running containers?

A Passed as environment variables

B Embedded in container image

C Mounted as files in volumes

D Stored in pod annotations

ConfigMaps mounted as files can be updated live; environment variables require pod restart.

What happens if you update a ConfigMap but do not restart pods using it?

A Pods continue using old config

B Pods automatically reload new config

C Pods crash immediately

D Pods delete themselves

Pods keep using the old ConfigMap data until restarted or recreated.

Explain how ConfigMap updates propagate to running pods in Kubernetes.

Think about pod lifecycle and how config is loaded.

Describe the difference between ConfigMap data mounted as environment variables versus as files regarding updates.

Consider how containers read environment variables vs files.

Practice

1. What happens when you update a ConfigMap in Kubernetes without restarting the pods using it?

easy

A. Pods continue using the old ConfigMap values until restarted

B. Pods automatically reload the new ConfigMap values immediately

C. Kubernetes deletes the pods using the old ConfigMap

D. ConfigMap update fails if pods are running

Solution

1. Step 1: Understand ConfigMap behavior on update

   Updating a ConfigMap does not notify or refresh pods automatically.

2. Step 2: Effect on running pods

   Pods keep using the old ConfigMap data until they are restarted or redeployed.

3. Final Answer:

   Pods continue using the old ConfigMap values until restarted -> Option A

4. Quick Check:

   Pods do not auto-refresh ConfigMaps = B [OK]

Hint: Pods need restart to use updated ConfigMaps [OK]

Common Mistakes:

• Assuming pods auto-refresh ConfigMap changes
• Thinking ConfigMaps update triggers pod restart automatically
• Believing ConfigMap updates delete pods

2. Which command correctly updates a ConfigMap named app-config from a file config.yaml?

easy

A. kubectl update configmap app-config --from-file=config.yaml

B. kubectl edit configmap app-config --from-file=config.yaml

C. kubectl replace configmap app-config --from-file=config.yaml

D. kubectl create configmap app-config --from-file=config.yaml --dry-run=client -o yaml | kubectl apply -f -

Solution

1. Step 1: Understand updating ConfigMap from file

   Direct update requires creating new YAML and applying it.

2. Step 2: Use dry-run and apply for update

   Command C creates new ConfigMap YAML from file and applies it, updating existing ConfigMap.

3. Final Answer:

   kubectl create configmap app-config --from-file=config.yaml --dry-run=client -o yaml | kubectl apply -f - -> Option D

4. Quick Check:

   Use create with dry-run + apply to update ConfigMap = C [OK]

Hint: Use create with dry-run and apply to update ConfigMap [OK]

Common Mistakes:

• Using 'kubectl update' which is not a valid command
• Trying to edit ConfigMap with --from-file option
• Using replace without proper YAML input

3. Given a pod using a ConfigMap mounted as a volume, what is the output of cat /etc/config/app.properties inside the pod immediately after updating the ConfigMap but before restarting the pod?

medium

A. Shows the updated content from the ConfigMap

B. Shows the old content from the ConfigMap before update

C. File is empty because ConfigMap is not mounted

D. Command returns an error because ConfigMap changed

Solution

1. Step 1: Understand ConfigMap volume mount behavior

   ConfigMap mounted as volume is projected as files inside pod at start time.

2. Step 2: Effect of ConfigMap update on mounted files

   Files inside pod do not update automatically; they keep old content until pod restart.

3. Final Answer:

   Shows the old content from the ConfigMap before update -> Option B

4. Quick Check:

   Mounted ConfigMap files do not auto-update = A [OK]

Hint: Mounted ConfigMap files update only after pod restart [OK]

Common Mistakes:

• Assuming mounted files auto-refresh on ConfigMap update
• Expecting empty files if ConfigMap changed
• Thinking command errors due to ConfigMap update

4. You updated a ConfigMap but your pods still use old values. Which command fixes this without deleting pods manually?

medium

A. kubectl rollout restart deployment/myapp

B. kubectl delete pod -l app=myapp

C. kubectl apply -f configmap.yaml

D. kubectl configmap refresh myapp

Solution

1. Step 1: Identify how to refresh pods after ConfigMap update

   Pods must restart to load new ConfigMap values.

2. Step 2: Use rollout restart to restart pods gracefully

   Command 'kubectl rollout restart' triggers pod restart without manual deletion.

3. Final Answer:

   kubectl rollout restart deployment/myapp -> Option A

4. Quick Check:

   Use rollout restart to refresh pods = D [OK]

Hint: Use rollout restart to refresh pods after ConfigMap update [OK]

Common Mistakes:

• Deleting pods manually instead of rollout restart
• Expecting apply to restart pods automatically
• Using non-existent commands like configmap refresh

5. You have a deployment using a ConfigMap for environment variables. After updating the ConfigMap, you want all pods to use the new values without downtime. What is the best approach?

hard

A. Update the ConfigMap and wait; pods auto-refresh environment variables

B. Delete all pods manually to force recreation with new ConfigMap

C. Update the ConfigMap and run kubectl rollout restart deployment/myapp

D. Edit each pod to mount the new ConfigMap version

Solution

1. Step 1: Understand environment variable update behavior

   Pods do not auto-refresh environment variables from ConfigMap updates.

2. Step 2: Use rollout restart for zero downtime update

   Rolling restart updates pods one by one, applying new ConfigMap values without downtime.

3. Final Answer:

   Update the ConfigMap and run kubectl rollout restart deployment/myapp -> Option C

4. Quick Check:

   Rollout restart updates pods gracefully = A [OK]

Hint: Use rollout restart for zero downtime ConfigMap update [OK]

Common Mistakes:

• Expecting pods to auto-refresh env vars
• Deleting pods causing downtime
• Editing pods directly which is not recommended