ConfigMaps

Same image, different config

A ConfigMap stores non-sensitive configuration as key-value pairs or whole files: log levels, feature flags, URLs of other services, configuration files. Keeping configuration out of images lets the same image run in development, staging and production. Note that values are strings (the flag "true" is quoted). Pods do not automatically restart when a ConfigMap changes; tools like Kustomize's config generators (which add a content hash to the name) trigger rollouts on changes.

Separate config from images

ConfigMaps hold settings, Secrets hold sensitive values, and both reach pods as env vars or files.

Generating a ConfigMap from literals, run

I ran this with kubectl 1.37.0 using --dry-run=client (or kubectl kustomize), which generates manifests locally without a cluster; nothing was applied to a live cluster. Both values become strings in the data section; "true" is quoted to stay a string.

kubectl create configmap web-config --from-literal=LOG_LEVEL=info --from-literal=FEATURE_SEARCH=true --dry-run=client -o yaml

Output:

apiVersion: v1
data:
  FEATURE_SEARCH: "true"
  LOG_LEVEL: info
kind: ConfigMap
metadata:
  name: web-config

Version config with the app

Generate ConfigMaps with a hash suffix so a config change rolls the Deployment and can be rolled back with it.

त्वरित जाँच: Why keep configuration in ConfigMaps rather than in the image?

• It makes pods start faster
• Images cannot contain files
• ConfigMaps are encrypted
• The same image can run in every environment with different settings