Kubernetes (9/12) — ConfigMap vs Secret

L’idée reçue

« Pour changer une URL ou une option de mon appli, je modifie le code et je reconstruis l’image. »

Non : l’image se construit une fois (artefact immuable), et la configuration s’injecte au démarrage. Kubernetes structure ça en deux objets : ConfigMap (config non sensible) et Secret (config sensible). Même but qu’en Docker, mais proprement.

À la fin de ce module, tu sauras…

Distinguer ConfigMap et Secret (usage, pas seulement technique)
Créer une ConfigMap et l’injecter comme variables d’environnement
La monter comme fichiers
Comprendre la différence cruciale de mise à jour : ENV vs FILE

01ConfigMap ou Secret : lequel ?

Les deux injectent de la configuration dans les Pods, et sont techniquement très proches. La différence est sémantique et de sécurité :

ConfigMap (non sensible)	Secret (sensible)
feature flags, mode de l’appli	mots de passe
URLs, ports, niveaux de log	tokens d’API, identifiants DB
fichiers de config JSON/YAML	clés privées, certificats TLS

Comprends le lien avec Docker

But partagé Docker/Kubernetes : construire une fois (image immuable), configurer au runtime (changer le comportement sans reconstruire), garder les secrets hors de l’image (pas de fuite dans Git ou les couches). Kubernetes formalise : ConfigMap = config sûre si divulguée ; Secret = config dangereuse si divulguée. Note : un Secret est seulement encodé en base64 par défaut, pas chiffré (sauf chiffrement at-rest activé).

02Créer une ConfigMap

Expérience 1

De la configuration non secrète

Manipule

kubectl create configmap web-config \
--from-literal=APP_NAME=soria-web \
--from-literal=LOG_LEVEL=info \
--from-literal=APP_COLOR=blue
kubectl get configmap web-config -o yaml

Observe

data:
APP_COLOR: blue
APP_NAME: soria-web
LOG_LEVEL: info

La ConfigMap n’est pas un fichier sur ta VM : c’est un objet Kubernetes stocké dans le cluster. On pourra l’attacher aux Pods de deux façons : en ENV ou en fichiers.

Comprends un objet, pas un fichier local

La ConfigMap vit dans le datastore du cluster (etcd), pas sur ton disque. Elle est réutilisable par plusieurs Pods, versionnable dans tes manifestes, et modifiable sans toucher aux images. C’est la config « déportée » du code.

03Injecter en variables d’environnement

Expérience 2

La ConfigMap comme ENV

Crée un Pod qui reçoit la ConfigMap via envFrom, puis vérifie à l’intérieur :

Manipule

kubectl exec -it cm-env-demo -- sh -c 'env | grep -E "APP_NAME|LOG_LEVEL|APP_COLOR"'

Observe

LOG_LEVEL=info
APP_NAME=soria-web
APP_COLOR=blue

Les valeurs de la ConfigMap sont devenues des variables d’environnement dans le conteneur, injectées au démarrage.

Comprends envFrom

envFrom importe toutes les clés de la ConfigMap comme variables d’environnement d’un coup. Simple et parfait pour des flags. Mais retiens « injectées au démarrage » — c’est le cœur de la leçon suivante.

04Monter en fichiers

Expérience 3

La ConfigMap comme répertoire de config

Monte la ConfigMap sous /config : chaque clé devient un fichier.

Manipule

kubectl exec -it cm-file-demo -- sh -c 'ls -la /config; echo; cat /config/APP_COLOR'

Observe

APP_COLOR -> ..data/APP_COLOR
APP_NAME  -> ..data/APP_NAME
LOG_LEVEL -> ..data/LOG_LEVEL
blue

Chaque clé est un fichier (/config/APP_COLOR contient blue). C’est le style « fichier de config », proche d’un volume Docker en lecture seule.

Comprends les symlinks ..data

Kubernetes monte la config via un jeu de symlinks (..data). Ce mécanisme permet des mises à jour « atomiques » : Kubernetes écrit une nouvelle version puis bascule le lien. C’est ce qui rend le montage fichier différent de l’ENV, comme on va le voir.

05La vraie leçon : ENV vs FILE à la mise à jour

Expérience 4

Change la config, observe qui se met à jour

Manipule

kubectl patch configmap web-config --type merge -p '{"data":{"APP_COLOR":"red"}}'
kubectl get configmap web-config -o yaml | grep APP_COLOR

Observe

APP_COLOR: red

Sans redémarrer, vérifie le Pod ENV :

Manipule

kubectl exec -it cm-env-demo -- sh -c 'echo "APP_COLOR(env)=$APP_COLOR"'

Observe

APP_COLOR(env)=blue    # toujours l'ancienne valeur !

La ConfigMap est passée à red, mais le conteneur voit toujours blue en ENV. L’injection ENV est figée au démarrage : elle ne se rafraîchit pas à chaud.

Comprends la règle DevOps à retenir

ENV = start-time only : si tu changes la config livrée en ENV, il faut redémarrer/rollout les Pods pour qu’ils la prennent. Le montage fichier, lui, peut se rafraîchir (via le mécanisme ..data), mais le comportement dépend du runtime et du timing — à vérifier dans ton cluster. En production, on applique les changements de config par un rollout propre et prévisible (ou un hot-reload applicatif pour les fichiers, si l’appli est conçue pour).

✓Ce que tu retiens

ConfigMap = config non sensible, Secret = config sensible ; les deux s’injectent en ENV ou en fichiers. La différence clé : l’ENV est figé au démarrage (il faut un rollout pour le mettre à jour), tandis que les fichiers montés peuvent se rafraîchir. Configurer sans reconstruire l’image : c’est la séparation code/config, proprement.

Mini-projet

Config sans reconstruction

À faire

Crée une ConfigMap web-config avec quelques clés.
Injecte-la en ENV dans un Pod, vérifie les valeurs à l’intérieur.
Monte-la en fichiers dans un autre Pod, lis un fichier de clé.
Modifie une valeur, prouve que l’ENV ne bouge pas sans rollout.
Applique le changement par un rollout et prouve la nouvelle valeur.
Documente dans BookStack : ConfigMap vs Secret, et ENV vs FILE.

Fil rouge — Ton appli est configurable et déployée. Mais Kubernetes sait-il si elle est vraiment en bonne santé et prête à recevoir du trafic ? Au module suivant, on ajoute les probes — l’évolution directe du healthcheck vu en Docker (Phase 3).

?Auto-évaluation

1. Quand utiliser un Secret plutôt qu’une ConfigMap ?

Pour toute donnée sensible (mots de passe, tokens, clés, certificats). La ConfigMap est pour la config non sensible.

2. Un Secret est-il chiffré par défaut ?

Non, seulement encodé en base64. Il faut activer le chiffrement at-rest pour un vrai chiffrement.

3. Pourquoi une config livrée en ENV ne se met-elle pas à jour à chaud ?

Parce que l’injection ENV se fait au démarrage du conteneur. Il faut redémarrer/rollout les Pods pour prendre la nouvelle valeur.