Skip to main content
In Kubernetes, workloads often rely on ConfigMaps or Secrets for configuration data. However, when these resources change, pods do not automatically pick up the updates. Config generators (and secret generators) solve this by automating rollouts whenever underlying ConfigMaps or Secrets are modified. In this lesson, we’ll demonstrate this problem and prepare for the next section on generators.

Initial Setup

1. Create a ConfigMap for Database Credentials

First, define a ConfigMap to hold your database password. In production, you should use a Secret, but for demonstration the behavior is identical.
Use a Secret in real deployments to protect sensitive data.
Save this as configmap.yaml and apply:

2. Deploy an NGINX Pod Referencing the ConfigMap

Next, deploy an NGINX container that injects the password as an environment variable:
Save as deployment.yaml and apply:

Verifying the Environment Variable

  1. List the running pods:
  2. Exec into the NGINX pod and print the DB_PASSWORD:
Expected output:

Changing the Password

After some time, update the database password in your ConfigMap:
Reapply the manifest:
Even though the ConfigMap reflects the new value:
the pod still reports the old password:
Kubernetes does not automatically redeploy pods when a referenced ConfigMap or Secret is updated. You must manually trigger a restart.

Manual Rollout Restart

To pick up the new password, force a rollout restart of the deployment:
Watch for the new pod:
Verify the updated environment variable:

Common Kubectl Commands

The Challenge

Every time a ConfigMap or Secret changes, Kubernetes leaves existing pods untouched. Manually restarting each deployment can become error-prone at scale. In the next section, we’ll introduce config generators to automate this process, ensuring your applications always run with the latest configuration.

References

Watch Video