Skip to content
AITroveRead. Build. Understand.
Reading list
Make this comfortable

Immutable configuration: bind each release to one named generation

Last updated: 1 Oct 20266 min read
tutorial
AdvancedBy AITrove Editorial

An immutable ConfigMap refuses data changes after creation. A new configuration generation therefore needs a new object name, and the workload must reference that name to receive it. This makes the release's configuration identity explicit and avoids an in-place change that silently reaches already-running Pods at different times. The object is not a secret and immutability does not validate its contents.

Operational decision

A settlement calculator needs a new rounding policy for one release. Produce a named ConfigMap from a reviewed document, set immutable to true, and record a content digest in the release evidence. Update the Deployment Pod template to point to the new name, then canary the new calculator against synthetic and shadowed production-shaped cases before increasing traffic. The fragment defines only the configuration object; the Deployment reference is a separate reviewed change. Keep the prior immutable object while rollback remains possible. After the rollback window closes, inventory live Pod references, retained ReplicaSets, and disaster-recovery manifests before deleting old generations. Reusing a deleted name is unsafe because old Pods may retain mounts and operators can no longer tell which bytes that name once represented. Prefer a generation name derived from a verified build or policy revision rather than a mutable label such as latest.

yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: settlement-rounding-r47
  namespace: checkout
immutable: true
data:
  policy.yaml: |
    currency: INR
    rounding: HALF_EVEN
    minor_unit: 2

Cost and verification

Versioned objects consume API storage and need garbage collection. They also make rollback and incident reconstruction cheaper because the workload references a specific generation. Measure failed configuration validations, old-generation object count, mixed-version Pod duration, and rollback time. The cost of retaining a small ConfigMap is usually lower than the cost of losing the exact configuration that produced a financial result, but retention still needs an owner and expiry rule.

Common Mistakes

  • Do not mutate a released generation by deleting and recreating the same name.
  • Do not purge a prior object while rollback or an old ReplicaSet still references it.
  • Do not treat immutable as proof that the policy is valid or confidential.

Connected lessons

Practice and check

devops
operations
Storage details