Stage 5 · Platform
Configuration & Secrets Management
Configuration Rollouts
Checksum annotations, Stakater Reloader, canary config changes, and rollback validation.
Configuration Rollout Strategies
Configuration changes are deployment risks. A bad ConfigMap can crash all pods. Use safe rollout strategies: rolling updates with PDBs, canary config changes, checksum-based restarts, and atomic versioned ConfigMaps.
- Version ConfigMaps for atomic updates
- Use checksum annotations to trigger restarts
- Deploy Stakater Reloader for automatic restarts
- Test config changes in staging before production
- Monitor pod health during configuration rollouts
Checksum Annotations
Helm supports checksum annotations that change when values change. This triggers a rolling restart of pods, ensuring they use the new configuration. Without this, pods continue using the old ConfigMap until restarted.
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
template:
metadata:
annotations:
checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }}
spec:
containers:
- name: app
volumeMounts:
- name: config
mountPath: /etc/config
volumes:
- name: config
configMap:
name: {{ include "my-app.configName" . }}The checksum annotation changes when the ConfigMap template changes. This forces a rolling restart of all pods. The sha256sum is computed from the rendered ConfigMap template, ensuring any change triggers a restart.
Stakater Reloader
Stakater Reloader automatically restarts pods when referenced ConfigMaps or Secrets change. It watches for changes and triggers rolling updates. This eliminates the need for checksum annotations or manual restarts.
# Install Reloader
# helm install reloader stakater/reloader -n kube-system
# Auto-detect ConfigMap/Secret changes
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
annotations:
reloader.stakater.com/auto: "true"
---
# Specific ConfigMap/Secret triggers
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
annotations:
configmap.reloader.stakater.com/reload: "app-config"
secret.reloader.stakater.com/reload: "db-credentials"auto: true watches all ConfigMaps and Secrets referenced in the Deployment. Specific annotations watch only named resources. Reloader updates the pod template annotation, triggering a rolling restart.
Canary Configuration Changes
Test configuration changes on a subset of pods before applying to all. Use a Deployment with separate ConfigMaps for canary and stable. Shift traffic to test the new configuration before full rollout.
# Stable config
apiVersion: v1
kind: ConfigMap
metadata:
name: app-config-stable
data:
config.yaml: |
logLevel: info
maxRetries: 3
---
# Canary config
apiVersion: v1
kind: ConfigMap
metadata:
name: app-config-canary
data:
config.yaml: |
logLevel: debug
maxRetries: 5
newFeature: true
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-canary
spec:
replicas: 1
selector:
matchLabels:
app: my-app
config: canary
template:
metadata:
labels:
app: my-app
config: canary
spec:
containers:
- name: app
volumeMounts:
- name: config
mountPath: /etc/config
volumes:
- name: config
configMap:
name: app-config-canaryDeploy canary config alongside stable. Monitor canary pods for errors. If healthy, apply the config change to all pods. This reduces the blast radius of configuration changes.
Rollback Validation
After configuration changes, validate that pods are healthy and serving traffic correctly. Use readiness probes, health checks, and monitoring to detect issues. Automate rollback if validation fails.
# Check Helm release history
helm history my-release -n production
# Rollback to previous revision
helm rollback my-release --wait --timeout 5m
# Rollback to specific revision
helm rollback my-release 3 --wait --timeout 5m
# Verify rollback
helm status my-release -n production
kubectl get pods -n production -l app=my-appHelm tracks release history. Rollback reverts to a previous revision. --wait ensures all pods are ready before completing. --timeout prevents hanging if pods fail to start.
Atomic Configuration Updates
Atomic updates replace the entire ConfigMap at once. Create a new ConfigMap with a version suffix, update the Deployment to reference it, and delete the old one. This prevents partial updates where some pods use old config and some use new.
# Create new ConfigMap with version suffix
kubectl create configmap app-config-v2 \
--from-literal=config.yaml="$(cat config.yaml)" \
-n production
# Update Deployment to use new ConfigMap
kubectl patch deployment my-app -n production -p \
'{"spec":{"template":{"spec":{"volumes":[{"name":"config","configMap":{"name":"app-config-v2"}}]}}}}'
# Delete old ConfigMap
kubectl delete configmap app-config-v1 -n productionThis creates a new ConfigMap, updates the Deployment atomically, and removes the old one. The Deployment update triggers a rolling restart with the new configuration. No partial updates occur.
Use GitOps (ArgoCD/Flux) to detect configuration drift. If someone manually modifies a ConfigMap, GitOps tools revert it to the Git state. This ensures configuration consistency across environments.
Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.