ConfigMaps

Config doesn't belong inside the image

Baking config into a container image means rebuilding the image every time a setting changes — the same mistake as hardcoding a database hostname into a compiled binary. A ConfigMap is a plain key-value object you create separately from your Pods, so the same image can run in dev, staging, and prod with different config, unchanged.

Three ways to consume one

1. A single env var, via valueFrom.configMapKeyRef — pick one key out of the ConfigMap and expose it as one environment variable. Good for a handful of simple values.
2. envFrom — dump every key in the ConfigMap into env vars at once, no per-key wiring. Convenient, but less explicit about what a Pod actually depends on.
3. A mounted volume — the whole ConfigMap appears as a directory, one file per key, its contents as the file's content. This is the only option that fits large config (an actual nginx.conf, a JSON blob) or files an app expects to literally read from disk.

The option that matters most in practice: env vars are frozen at pod start. Change the ConfigMap, and existing pods keep their old env vars until they're recreated. A mounted volume, by contrast, does get updated in the running pod (kubelet syncs it periodically) — but most apps don't watch their config files for changes, so you still usually need to restart the pod to actually pick it up. Either way: updating a ConfigMap is not the same as updating what your app is doing right now.

Linux aside: environment variables and files

If you've ever set export FOO=bar in a shell, that's exactly what valueFrom/envFrom are doing to the container's single process before it starts — same mechanism, just set by the kubelet instead of your terminal. A volume mount, meanwhile, is Kubernetes doing the same thing your OS does when you mount a USB drive at /mnt/usb: an existing directory path suddenly has new file contents behind it, fully transparent to whatever reads from that path.

The infrastructure analogy

Think of a ConfigMap as the externalized .env file or /etc/app/config you'd manage with Ansible/Puppet in a traditional deploy — except here it's a first-class, versioned API object the Pod spec references directly, instead of a file pushed out-of-band and hoped to be in sync.

In the lab, you'll diagnose a Pod whose environment doesn't match what its ConfigMap actually contains — the same "which part has the stale value" debugging you've likely done with config-management drift before.