⚙️ ConfigMaps = Configuration
Hardcoding config is bad. ConfigMaps externalize configuration. Change settings without rebuilding.
📝 Creating ConfigMaps
# From literal values
kubectl create configmap app-config \
--from-literal=env=production \
--from-literal=log-level=debug \
--from-literal=api-url=https://api.example.com
# From file
kubectl create configmap app-config \
--from-file=./configs/app.properties \
--from-file=./configs/log4j.properties
# From YAML
apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
data:
env: production
log-level: debug
api-url: https://api.example.com
app.properties: |
database.url=postgres://localhost/db
database.user=postgres
cache.ttl=3600
🎯 Using ConfigMaps
# As environment variables
apiVersion: v1
kind: Pod
metadata:
name: myapp
spec:
containers:
- name: app
image: myapp:latest
env:
- name: ENV
valueFrom:
configMapKeyRef:
name: app-config
key: env
- name: LOG_LEVEL
valueFrom:
configMapKeyRef:
name: app-config
key: log-level
# All env from ConfigMap
spec:
containers:
- name: app
envFrom:
- configMapRef:
name: app-config
# As volume mount
spec:
containers:
- name: app
volumeMounts:
- name: config-volume
mountPath: /etc/config
readOnly: true
volumes:
- name: config-volume
configMap:
name: app-config
# ConfigMap Tips
- Separate config from code
- Use different ConfigMaps per environment
- Use subPath for specific files
- ConfigMaps update automatically (volume mounts)
- Not for sensitive data (use Secrets)
💡 ConfigMap Tips
- Separate config from code
- Use different ConfigMaps per environment
- Use subPath for specific files
- ConfigMaps update automatically (volume mounts)
- Not for sensitive data (use Secrets)
“ConfigMaps externalize configuration. No more rebuilding for config changes. Essential for flexibility.”
