🎓 LEVEL 36 DEBRIEF: ConfigMap Key Management¶
Congratulations! You've mastered ConfigMap key references - essential for application configuration in Kubernetes!
📊 What You Fixed¶
The Problem:
data:
app_name: "MyApp"
app_version: "1.0.0"
# ❌ Missing: database_host
env:
- name: DATABASE_HOST
valueFrom:
configMapKeyRef:
key: database_host # ❌ Key doesn't exist!
The Solution:
data:
app_name: "MyApp"
app_version: "1.0.0"
database_host: "postgres.k8squest.svc.cluster.local" # ✅ Added!
🔍 ConfigMap Fundamentals¶
ConfigMaps store non-sensitive configuration data as key-value pairs.
Three Ways to Use ConfigMaps¶
1. Environment Variables:
2. All Keys as Environment Variables:
3. As Files (Volume Mount):
volumes:
- name: config
configMap:
name: app-config
volumeMounts:
- name: config
mountPath: /etc/config
# Each key becomes a file
💥 Common Mistakes¶
Mistake 1: Key Typo¶
data:
database_host: "..." # Defined as database_host
env:
- valueFrom:
configMapKeyRef:
key: databaseHost # ❌ Wrong case!
Mistake 2: Missing Required Key¶
# ConfigMap has: app_name, app_version
# Pod needs: app_name, app_version, database_host
# Result: Pod fails to start
Mistake 3: Using configMapKeyRef Without Optional Flag¶
env:
- name: OPTIONAL_CONFIG
valueFrom:
configMapKeyRef:
name: config
key: optional_key # ❌ If missing, pod fails
# Should add: optional: true
🛡️ Best Practices¶
-
Validate all required keys exist:
-
Use optional for non-critical configs:
-
Document expected keys:
-
Use envFrom for all keys:
🎯 Key Takeaways¶
- All referenced keys must exist - Or pod fails to start
- Keys are case-sensitive - database_host ≠ databaseHost
- Three usage patterns - Env vars, envFrom, volume mounts
- Use optional: true for non-critical - Allows pod to start
- Validate before deployment - Check ConfigMap has all required keys
Well done! You understand ConfigMap key management! 🎉