This lesson ties together everything from Chapter 3 into a set of production-proven patterns. How should configuration flow from Git to running containers? How do you handle changes without downtime? How do you keep it maintainable across environments?

1. 12-Factor Config in Kubernetes

The 12-Factor App says: "Store config in the environment." Kubernetes gives you the tools to follow this rigorously:

The Configuration Hierarchy

# Priority (highest → lowest):
1. Environment-specific overrides   (ConfigMap per namespace)
2. Application defaults              (baked into image as fallbacks)
3. Framework defaults                (e.g., Spring Boot defaults)

# Example: same app in dev and prod
# dev namespace:  ConfigMap with LOG_LEVEL=debug, REPLICAS_CACHE=1
# prod namespace: ConfigMap with LOG_LEVEL=warn,  REPLICAS_CACHE=3
# Same image, different behavior

What Goes Where

2. Hot-Reload Patterns

How do you update configuration without restarting Pods?

Pattern 1: Volume Mount Auto-Sync (Simplest)

# ConfigMap mounted as volume → files auto-update in ~60s
# App watches file for changes (inotify, polling, or framework support)

# Works for: nginx (with reload signal), Spring Boot (actuator refresh),
#            Prometheus (config reload endpoint)

# nginx reload on config change:
spec:
  containers:
    - name: nginx
      image: nginx:1.25
      volumeMounts:
        - name: config
          mountPath: /etc/nginx/conf.d
    - name: reloader             # ← sidecar watches for file changes
      image: jimmidyson/configmap-reload:v0.9.0
      args:
        - --volume-dir=/etc/nginx/conf.d
        - --webhook-url=http://localhost:80/-/reload
      volumeMounts:
        - name: config
          mountPath: /etc/nginx/conf.d

Pattern 2: Reloader Operator (Stakater)

# Stakater Reloader watches ConfigMaps/Secrets and triggers
# rolling restarts of Deployments that reference them.

# Annotate the Deployment:
metadata:
  annotations:
    reloader.stakater.com/auto: "true"
# OR target specific ConfigMaps:
    configmap.reloader.stakater.com/reload: "app-config"

# When app-config ConfigMap changes → Reloader triggers rollout restart
# No sidecar needed — cluster-level operator

Pattern 3: Config Hash Annotation (CI/CD Driven)

# CI/CD pipeline computes hash of ConfigMap content:
CONFIG_HASH=$(kubectl get configmap app-config -o json | sha256sum | cut -d' ' -f1)

# Patches the Deployment template annotation:
kubectl patch deployment web -p \
  "{\"spec\":{\"template\":{\"metadata\":{\"annotations\":{\"configHash\":\"$CONFIG_HASH\"}}}}}"

# Annotation change → template change → rolling update triggered
# Fully declarative in Helm/Kustomize:
spec:
  template:
    metadata:
      annotations:
        checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }}

Pattern 4: Immutable ConfigMaps + Name Versioning

# CI creates: app-config-v7 (immutable: true)
# Deployment references: configMap.name: app-config-v7
# On config change:
#   1. Create app-config-v8
#   2. Update Deployment to reference v8
#   3. Rolling update triggered naturally
#   4. Rollback = point back to v7

# This is the safest pattern for critical systems

3. Multi-Environment Configuration

Kustomize Overlays (Built into kubectl)

# Directory structure:
base/
  deployment.yaml
  configmap.yaml
  kustomization.yaml
overlays/
  dev/
    configmap-patch.yaml   # LOG_LEVEL=debug
    kustomization.yaml
  prod/
    configmap-patch.yaml   # LOG_LEVEL=warn
    kustomization.yaml

# Apply:
kubectl apply -k overlays/prod/

Helm Values Files

# values-dev.yaml:
config:
  logLevel: debug
  replicas: 1

# values-prod.yaml:
config:
  logLevel: warn
  replicas: 5

# helm install myapp ./chart -f values-prod.yaml

Namespace-per-Environment

# Simple and effective:
# Namespace: dev    → ConfigMap "app-config" (debug settings)
# Namespace: prod   → ConfigMap "app-config" (production settings)
# Same Deployment manifest, different namespace = different config
# Works because ConfigMaps are namespaced

4. Anti-Patterns to Avoid

5. Configuration Checklist

✅ Same image across all environments (config is external)
✅ Secrets in external store (Vault/AWS/GCP) — synced via ESO
✅ ConfigMaps split by concern (app, logging, features)
✅ Volume mounts for config files; env vars only for simple key-values
✅ Secrets mounted as files (not env vars) with 0400 permissions
✅ Immutable ConfigMaps in high-scale clusters
✅ Config hash annotation (or Reloader) for automatic rollouts
✅ All config changes go through Git (GitOps)
✅ readinessProbe on Pods that depend on config (fail fast on bad config)
✅ Encryption at rest enabled for Secrets in etcd

Summary