ConfigMaps: settings outside the image

One image, many environments.

Your app needs settings — a log level, a feature flag, a database host — and those should live outside the container image so the same image can run anywhere, just configured differently. ConfigMaps are how Kubernetes stores that non-secret configuration and hands it to your pods. One image, many environments.

Settings outside the image

A ConfigMap is a simple object holding key-value configuration data. You inject it into a pod in one of two ways: as environment variables the app reads, or as files mounted into the container (each key becomes a file — handy for a whole config file like an nginx.conf). The point is separation: the image contains your code, and the ConfigMap contains the settings, so you build the image once and run it in dev, staging, and prod by pointing it at different ConfigMaps. Change the log level for production? Update the ConfigMap, not the image. This "config separate from code" principle is a cornerstone of running the same trusted artifact everywhere, and it is exactly what lets your one image behave correctly in every environment.

apiVersion: v1
kind: ConfigMap
metadata: { name: app-config }
data:
  LOG_LEVEL: "info"
  app.conf: |
    server_port = 8080
---
spec:
  containers:
    - name: web
      image: my-app:1.4
      envFrom: [{ configMapRef: { name: app-config } }]  # keys → env vars
      volumeMounts: [{ name: cfg, mountPath: /etc/app }]  # keys → files
  volumes:
    - name: cfg
      configMap: { name: app-config }   # /etc/app/app.conf appears in the pod

A couple of things to know

Two practical notes. First, how a change reaches a running pod depends on how you injected it: settings passed as environment variables are fixed when the pod starts, so updating the ConfigMap does not change them until you restart the pods; settings mounted as files do update in the pod after a short delay, though the app only notices if it re-reads the file. So for a config change to take effect, you often roll the Deployment (restart its pods) — a normal, safe operation. Second, and importantly, ConfigMaps are not for secrets: their contents are stored and displayed in plain text, so anyone who can read the ConfigMap sees everything in it. Passwords, tokens, and keys belong in Secrets (the next lesson), which are the sensitive-data counterpart. For everything non-sensitive — log levels, URLs, feature flags, config files — ConfigMaps are the clean, standard way to keep configuration out of your image and let one image serve every environment.