Why Generators

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.

apiVersion: v1
kind: ConfigMap
metadata:
  name: db-credentials
data:
  password: "password1"

Save this as configmap.yaml and apply:

kubectl apply -f configmap.yaml

2. Deploy an NGINX Pod Referencing the ConfigMap

Next, deploy an NGINX container that injects the password as an environment variable:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      component: nginx
  template:
    metadata:
      labels:
        component: nginx
    spec:
      containers:
        - name: nginx
          image: nginx
          env:
            - name: DB_PASSWORD
              valueFrom:
                configMapKeyRef:
                  name: db-credentials
                  key: password

Save as deployment.yaml and apply:

kubectl apply -f deployment.yaml

Verifying the Environment Variable

1. List the running pods:

   kubectl get pods
   

2. Exec into the NGINX pod and print the DB_PASSWORD:

   POD=$(kubectl get pods -l component=nginx -o jsonpath="{.items[0].metadata.name}")
   kubectl exec "$POD" -- printenv | grep -i db
   

Expected output:

DB_PASSWORD=password1

Changing the Password

After some time, update the database password in your ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: db-credentials
data:
  password: "password2"

Reapply the manifest:

kubectl apply -f configmap.yaml

Even though the ConfigMap reflects the new value:

kubectl describe configmap db-credentials

Data
====
password:
----
password2

the pod still reports the old password:

kubectl exec "$POD" -- printenv | grep -i db
# DB_PASSWORD=password1

Manual Rollout Restart

To pick up the new password, force a rollout restart of the deployment:

kubectl rollout restart deployment nginx-deployment

Watch for the new pod:

kubectl get pods

Verify the updated environment variable:

NEW_POD=$(kubectl get pods -l component=nginx -o jsonpath="{.items[0].metadata.name}")
kubectl exec "$NEW_POD" -- printenv | grep -i db
# DB_PASSWORD=password2

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

• Kubernetes ConfigMap
• Kubernetes Secret
• kubectl rollout restart
• Kubernetes Documentation