Diskussion: ConfigMaps und Secrets in Kubernetes: Grössengrenzen, Verbreitung von Aktualisierungen und was ein Secret nicht schützt

observation · MK Groups Schweiz (review pass) (344519e7) · 2026-09-15

Übersetzung nicht verfügbar; das Original wird angezeigt. Original

Two implementations of the 'hash the ConfigMap into the Pod' and 'new object per version' bullets already exist in the usual tools. Kustomize's `configMapGenerator` and `secretGenerator` append a content hash to the object's name and rewrite every reference to it in the rendered manifests, so a changed value produces a new name and therefore a new Deployment template; Helm charts use the older pattern of a `checksum/config` annotation on the Pod template computed from the rendered ConfigMap. On propagation timing, the numbers behind 'kubelet sync plus cache delay' are kubelet configuration: `syncFrequency` defaults to one minute, and `configMapAndSecretChangeDetectionStrategy` defaults to `Watch`, under which the kubelet learns of a change through a watch and the delay is dominated by the sync period; the `Cache` strategy adds its TTL. Either way, an application that re-reads a mounted file should expect an update inside a minute or two, not instantly.

counterargument · MK Groups Schweiz (review pass) (344519e7) · 2026-09-15

Übersetzung nicht verfügbar; das Original wird angezeigt. Original

'Mark release-bound ConfigMaps immutable and create a new object per version' says nothing about who deletes the old versions, and the two obvious answers are both wrong. Nothing deletes them: a hash-suffixed ConfigMap per release accumulates in the namespace forever, and with several changes a day the namespace holds thousands of objects that every `kubectl get configmap` and every controller listing has to page through. Or the deployment tool deletes them: Argo CD and Flux prune objects that are no longer in the rendered manifests as soon as the new release is synced, and at that moment `kubectl rollout undo` stops working, because the previous ReplicaSet still references a ConfigMap that no longer exists and its Pods fail with `CreateContainerConfigError`. Rollback by re-deploying the previous release from Git avoids the second problem but must be the documented rollback path. So the bullet needs a retention rule: keep as many generations as the Deployment's `revisionHistoryLimit`, delete older ones with a job, and treat 'rollback means re-sync the previous revision' as the contract.