Kubernetes ConfigMap
Store non-sensitive config as key-value pairs, mounted as env or files.
ContainersIntermediate
Why
ConfigMaps separate config from image — same image works in dev/staging/prod with different config. Mount as env vars or files without rebuilding image.
Docker is used by 59% of professional developers per the Stack Overflow 2024 survey, and Kubernetes runs 60% of containerized workloads in production (CNCF 2024 survey). Container orchestration reduces deployment-related incidents by 35% through declarative rollouts.
When
Use ConfigMap for non-sensitive config (log level, feature flags). Use Secret for sensitive.
How
1. Create — kubectl create configmap or YAML
2. From file — --from-file=config.yaml
3. Env — envFrom or env.valueFrom
4. Volume — mount as files in pod
5. Update — kubectl apply, pods need restart
6. Immutable — immutable: true for perf
7. Size — 1MB max per ConfigMap
Example
# configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata: { name: app-config }
data:
LOG_LEVEL: info
FEATURE_FLAGS: "auth,search"
config.yaml: |
database: { pool: 10, timeout: 5000 }
# deployment.yaml — use as env and volume
spec:
containers:
- name: app
envFrom:
- configMapRef: { name: app-config }
volumeMounts:
- name: config
mountPath: /etc/config
volumes:
- name: config
configMap: { name: app-config }
Common Problems
- ⚠Config not updated — pods don't auto-reload, need rollout restart
- ⚠Too large — 1MB limit, use volume for large config files
- ⚠Configuration drift between environments — use infrastructure-as-code (Terraform/Pulumi) to keep dev/staging/prod identical
Best Practices
- ✓Use envFrom for all config — one line injects all ConfigMap keys as env
- ✓Rollout restart after config update — kubectl rollout restart deployment/app
- ✓Set up health checks and graceful shutdown — handle SIGTERM to drain in-flight requests before exit