Updating ConfigMaps and propagation in Kubernetes - Commands & Configuration

Introduction

ConfigMaps store configuration data for your apps in Kubernetes. When you update a ConfigMap, your app needs to get the new data to work correctly without restarting everything manually.

When you want to change app settings without rebuilding the container image.

When you need to update environment variables for running pods.

When you want to apply new configuration to multiple pods at once.

When you want to avoid downtime by updating config without restarting pods manually.

When you want to test new configuration quickly in a live environment.

Config File - configmap.yaml

configmap.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: example-config
  namespace: default
data:
  app.properties: |
    log_level=info
    max_connections=100

This file creates a ConfigMap named example-config in the default namespace.

The data section holds configuration key-value pairs your app can use.

Commands

This command creates or updates the ConfigMap in Kubernetes with the settings from the file.

Terminal

kubectl apply -f configmap.yaml

Expected Output

configmap/example-config created

This command shows the current content of the ConfigMap to verify your changes.

Terminal

kubectl get configmap example-config -o yaml

Expected Output

apiVersion: v1

data:

  app.properties: |

    log_level=info

    max_connections=100

kind: ConfigMap

metadata:

  name: example-config

  namespace: default

  resourceVersion: "12345"

  uid: 123e4567-e89b-12d3-a456-426614174000

→

-o yaml - Outputs the ConfigMap in YAML format for easy reading

This command restarts the pods in the deployment so they load the updated ConfigMap.

Terminal

kubectl rollout restart deployment example-deployment

Expected Output

deployment.apps/example-deployment restarted

This command lists pods with the label app=example-app to check their status after restart.

Terminal

kubectl get pods -l app=example-app

Expected Output

NAME                                READY   STATUS    RESTARTS   AGE

example-deployment-5d8f7c9d7f-abc12 1/1     Running   0          10s

example-deployment-5d8f7c9d7f-def34 1/1     Running   0          10s

→

-l app=example-app - Filters pods by label to show only relevant pods

Key Concept

Updating a ConfigMap alone does not update running pods; you must restart pods or trigger a rollout to apply changes.

Common Mistakes

Updating the ConfigMap but not restarting pods or deployment.

Pods keep using old config because they load ConfigMaps only at start.

After updating the ConfigMap, run 'kubectl rollout restart deployment <deployment-name>' to reload config.

Editing ConfigMap with 'kubectl edit' but forgetting to save changes.

No changes are applied if edits are not saved properly.

Make sure to save and exit the editor to apply changes.

Assuming ConfigMap updates automatically propagate to pods without restart.

Kubernetes does not auto-update running pods with new ConfigMap data.

Manually restart pods or deployment to pick up new ConfigMap values.

Summary

Create or update ConfigMaps using 'kubectl apply -f configmap.yaml'.

Verify ConfigMap content with 'kubectl get configmap <name> -o yaml'.

Restart pods or deployment with 'kubectl rollout restart deployment <name>' to apply changes.

Check pod status with 'kubectl get pods' filtered by labels.

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