Cheat notes · Module 02 · Run a workload

Configuration and secrets, and where the line is

A five-minute review for when you have done this module and want it back in your head. Open the full module for the steps and the lab, or the full text to print.

The idea

A ConfigMap gives a pod settings as environment variables (read once at start) or files (updated in place). A Secret is a ConfigMap with base64 and its own permissions, not encryption, so its value never goes in Git, and a rebuilt cluster needs a list of what Git does not hold.

Remember

Env is read once, files follow: changing a ConfigMap does not change a running container's environment.
Versioned, immutable ConfigMaps: checkout-settings-v2 with immutable: true. A config change is a new name, a rollout, and a clean revert.
base64 is an encoding. Anyone who may get the Secret reads the value.
Git history keeps everything. A pushed Secret means a new password, not a delete.
A missing Secret leaves new pods in CreateContainerConfigError; the old pods keep serving.
docs/secrets.md lists each Secret, its keys, its owner and where the value lives.

Pitfalls

Editing a ConfigMap in place and waiting for the change: pods only restart when the pod template changes.
"It is only encoded": a Secret in Git is readable by everyone who can read the repo, for ever.
Forgetting to delete the old ConfigMap after renaming: kubectl apply leaves it behind.

Commands

`kubectl -n NS exec deployment/NAME -- printenv VAR`	What the container's environment says
`kubectl -n NS create secret generic NAME --from-literal=KEY=VALUE`	A Secret typed in, not committed
`kubectl -n NS get secret NAME -o jsonpath='{.data.KEY}' \| base64 -d`	Read a Secret's value back
`git show HEAD~1:PATH`	A file as it was one commit ago

apps/checkout/deployment.yaml (container, excerpt)

env:
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: checkout-db
        key: password
envFrom:
  - configMapRef:
      name: checkout-settings-v2

Test yourself

Answer in your head first, then open the answer.

You change a ConfigMap used through envFrom. What happens to running pods?

Nothing: they keep the old values until they are replaced.

What protects a Secret's value?

Access control on secrets and optional encryption at rest. The value itself is only base64.

A Secret was pushed, then deleted in the next commit. What must happen?

Change the credential: the old value stays in the history.

How do you make a config change roll out from Git?

Give the ConfigMap a new versioned name, make it immutable, and point the Deployment at it.

Where module 02 leaves you: checkout reads its banner from an immutable ConfigMap checkout-settings-v2 and a password from the Secret checkout-db. The Secret exists only in the cluster; your repo has no Secret and has docs/secrets.md saying so.