Modifier un ConfigMap via kubectl edit ou kubectl apply change l’objet dans l’API Kubernetes immédiatement, mais ne redémarre aucun pod qui l’utilise : Kubernetes ne surveille jamais les ConfigMaps pour déclencher un rollout automatiquement. Ce qui se passe ensuite dépend entièrement de la façon dont le pod consomme ce ConfigMap, une nuance qui explique la majorité des confusions autour de « rien ne change après ma modification ».

Variable d’environnement : jamais mise à jour sans redémarrage

Un ConfigMap injecté comme variable d’environnement est lu une seule fois, au démarrage du conteneur : la valeur est copiée dans le processus au lancement, puis totalement déconnectée du ConfigMap source. Modifier le ConfigMap après coup n’a strictement aucun effet sur les pods déjà en cours d’exécution, quelle que soit la durée d’attente.

envFrom:
  - configMapRef:
      name: app-config
# La valeur est figée au démarrage du conteneur,
# une modification ultérieure du ConfigMap ne change rien

Seul un redémarrage effectif du pod (recréation, pas juste un signal) relit le ConfigMap et applique la nouvelle valeur.

Volume monté : se met à jour, mais avec un délai et sans redémarrage de l’application

Un ConfigMap monté comme volume se synchronise automatiquement, généralement dans la minute qui suit la modification (le délai exact dépend du cache du kubelet). Le fichier sur disque change bien, mais l’application qui l’a déjà lu au démarrage ne le relit pas d’elle-même : sans logique explicite de rechargement à chaud dans le code applicatif, le fichier change sur disque sans que le processus en cours ne s’en aperçoive.

volumes:
  - name: config-volume
    configMap:
      name: app-config
# Le fichier sur disque se met à jour automatiquement,
# mais l'appli doit elle-même détecter et relire le changement

Forcer un rollout : la solution la plus courante

Puisque ni les variables d’environnement ni les volumes ne redémarrent une application automatiquement, forcer un rollout du Deployment reste le moyen le plus fiable de propager un changement de configuration. Une pratique courante consiste à encoder un hash du contenu du ConfigMap dans une annotation du pod template : changer le ConfigMap change le hash, ce qui change le template, ce qui déclenche un rolling update normal.

spec:
  template:
    metadata:
      annotations:
        checksum/config: "{{ sha256sum (toYaml .Values.config) }}"

Cette technique, popularisée par Helm, transforme un changement de ConfigMap en changement effectif de spec de pod, le seul déclencheur natif d’un rolling update Kubernetes.

immutable: true : empêcher l’incident plutôt que le diagnostiquer

Marquer un ConfigMap ou un Secret comme immutable: true interdit toute modification ultérieure : toute tentative de kubectl edit échoue explicitement, forçant à créer un nouveau ConfigMap (avec un nom versionné) plutôt qu’à modifier l’existant en place.

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config-v2
immutable: true
data:
  key: value

Ce réflexe élimine la classe d’incidents où quelqu’un modifie un ConfigMap en pensant que l’application prendra le changement en compte immédiatement, alors que rien ne se passera avant un rollout explicite. Le bénéfice secondaire, documenté par Kubernetes lui-même, est une charge réduite sur le serveur API : un ConfigMap immuable n’a plus besoin d’être surveillé (watch) pour détecter un changement qui, par construction, ne peut jamais arriver.

À retenir

Modifier un ConfigMap ne redémarre jamais un pod automatiquement : une variable d’environnement reste figée à la valeur lue au démarrage, un volume monté se synchronise sur disque mais sans que l’application ne le relise d’elle-même. Forcer un rollout (via un hash de contenu en annotation, technique popularisée par Helm) reste le mécanisme le plus fiable pour propager un changement. immutable: true empêche l’incident à la source en interdisant toute modification en place, avec un bénéfice de charge sur l’API server en prime, un des réflexes de configuration qui comptent dès qu’une migration Kubernetes doit fiabiliser la propagation de configuration.