⌂ Home

ConfigMaps in Kubernetes

Interactive guide to storing non-sensitive configuration outside images and consuming it through environment variables or mounted files.

ConfigMaps separate runtime configuration from application images. The key design question is not whether to use ConfigMaps, but how the container should consume the data.

Core Model

Understand the Concept First

Repository YAML Files:
  • k8s/labs/workloads/configmap.yaml — ConfigMap resource holding key/value configuration data.
  • k8s/labs/workloads/configpod.yaml — Pod consuming a ConfigMap as env vars or volumes.
  • k8s/labs/workloads/config-svc.yaml — Pod that injects a ConfigMap key into an environment variable via configMapKeyRef.
Decouple configuration

The same image can run in dev, test, and prod with different configuration values.

Not for secrets

ConfigMaps are for non-confidential data. Sensitive values should use Secrets.

Three consumption paths

Use all keys as env vars, selected keys as env vars, or project data as files in a volume.

Lifecycle Flow

Configuration Delivery Flow

ConfigMap Consumption Patterns ConfigMap app-config database: mongodb log.level: INFO envFrom Pattern 1: All Keys as Env Vars envFrom: - configMapRef: name: app-config Container sees: $database = "mongodb" $log.level = "INFO" valueFrom Pattern 2: Selective Keys env: - name: DB_TYPE valueFrom: configMapKeyRef: name: app-config key: database $DB_TYPE = "mongodb" volumeMount Pattern 3: Files in Volume volumes: - name: config configMap: name: app-config Files created: /config/database /config/log.level Update Propagation Flow ConfigMap Updated log.level: DEBUG (was INFO) kubectl edit cm Sync (kubelet) ~1 minute Volume Mount ✓ Auto-updates /config/log.level reflects new value App must reload config Environment Variables ✗ NO auto-update Env vars set at Pod creation Immutable during Pod lifetime Must recreate Pod for updates
The biggest practical choice is whether the application expects configuration as environment variables or as files. Volume mounts support dynamic updates; environment variables do not.
YAML and Commands

Examples You Can Recognize Quickly

Multi-Container ConfigMap Sharing Pod: multi-container-app ConfigMap: shared-config api.url: https://api.example.com timeout: 30 Volume: config-vol Mounted from ConfigMap Container: web-app Mount: /app/config Container: sidecar Mount: /etc/config Container: init-db Mount: /config
ConfigMap YAML
apiVersion: v1
kind: ConfigMap
metadata:
  name: example-configmap
data:
  database: mongodb
  database_uri: mongodb://localhost:27017
Consume All Keys as Environment Variables
envFrom:
- configMapRef:
    name: example-configmap
Mount ConfigMap as Files
volumes:
- name: config-volume
  configMap:
    name: example-configmap
volumeMounts:
- name: config-volume
  mountPath: /config
Decision Guide

ConfigMap Consumption Patterns

Pattern How it works Best fit
envFrom Loads every key as an environment variable Simple apps that want all config at once
valueFrom Maps one specific key to one variable Explicit control over naming and scope
Volume mount Creates files from ConfigMap keys Apps that expect config files
Most teams standardize on one or two consumption patterns per application type to keep operations predictable.
Use It Well

Practice and Real-World Thinking

Application settings

Move database URLs, feature flags, and environment names out of the image.

Config file projection

Mount web server configs, properties files, or startup scripts from ConfigMaps.

Reusable config

Share a common non-secret configuration source across multiple Pods.