What Is a ConfigMap? Externalizing Kubernetes Configuration
A ConfigMap holds non-secret configuration as key-value data, which Kubernetes injects into pods as environment variables or mounted files.
Configuration should not be baked into your container image - the same image should run in dev, staging, and prod with different settings. A ConfigMap is how Kubernetes externalizes that non-sensitive configuration so one image can be configured per environment at deploy time.
What it stores
A ConfigMap is a set of key-value pairs (and whole config files). It is for non-sensitive data - feature flags, URLs, tuning values. Sensitive data belongs in a Secret instead.
How pods consume it
- As environment variables injected into containers.
- As files mounted into a volume the container reads.
- As command-line args sourced from its values.
Why externalize config
Keeping config out of the image means one immutable image promotes cleanly across environments - you change the ConfigMap, not rebuild. It also keeps environment-specific values out of version-pinned artifacts.
A gotcha: updates and restarts
Env-var values from a ConfigMap are read at pod start, so changing the ConfigMap does not update running pods until they restart. Mounted-file values can update live, but apps must re-read them.
ConfigMaps in CI/CD
A delivery pipeline applies the ConfigMap for the target environment alongside the Deployment, or templates it via a Helm chart. The image stays the same; only the ConfigMap differs between environments.
Key takeaways
- A ConfigMap externalizes non-secret config as env vars or files.
- It lets one immutable image be configured per environment.
- Env-var values are read at pod start, so changes need a restart to take effect.