ConfigMaps Kubernetes : gérer la configuration de vos applications

Un ConfigMap stocke la configuration non sensible de vos applications (variables, fichiers de config) séparément du code. Vous pouvez ainsi réutiliser la même image dans plusieurs environnements et faire évoluer la configuration sans reconstruire l’image. Selon le mode d’injection choisi, la mise à jour peut être automatique ou nécessiter un redémarrage des Pods.

Ce guide vous montre comment créer des ConfigMaps, les injecter dans vos Pods, et éviter les pièges courants lors des mises à jour.

Prérequis : un cluster Kubernetes avec kubectl configuré.

Ce que vous allez apprendre

• Créer un ConfigMap (littéraux, fichiers, YAML)
• Injecter la configuration via variables d’environnement ou fichiers montés
• Comprendre les différences entre env, envFrom et volumes
• Éviter les pièges de mise à jour (env, subPath, propagation)
• Utiliser les ConfigMaps immutables en production

Ce qu’est un ConfigMap

Un ConfigMap est une ressource Kubernetes qui stocke des paires clé-valeur non sensibles. Il permet de :

• Externaliser la configuration du code
• Réutiliser la même image dans différents environnements
• Modifier la configuration sans redéployer l’application

Analogie

Un ConfigMap est comme un fichier .env ou application.properties que vous pouvez modifier sans toucher au code de l’application.

ConfigMap ≠ Secret

Un ConfigMap stocke des données en clair. Pour les mots de passe, clés API et certificats, utilisez un Secret.

ConfigMap ou Secret ?

Ressource	Usage
ConfigMap	Configuration non sensible (variables, fichiers de config)
Secret	Données sensibles (mots de passe, tokens, certificats)

Glissez pour voir

Dans la plupart des cas, vous utiliserez le champ data du ConfigMap. Kubernetes prend aussi en charge binaryData pour des données binaires encodées en base64.

Créer un ConfigMap

Depuis des valeurs littérales

La méthode la plus rapide pour quelques variables :

kubectl create configmap app-settings \
  --from-literal=APP_ENV=production \
  --from-literal=LOG_LEVEL=info \
  --from-literal=MAX_CONNECTIONS=100

Vérifiez la création :

kubectl get configmap app-settings

Sortie

NAME           DATA   AGE
app-settings   3      5s

Depuis un fichier

Pour un fichier de configuration complet :

Créer le fichier

cat > nginx.conf << 'EOF'
server {
    listen 80;
    server_name localhost;
    location / {
        root /usr/share/nginx/html;
    }
}
EOF

Créer le ConfigMap

kubectl create configmap nginx-config --from-file=nginx.conf

Le nom du fichier devient la clé, son contenu la valeur :

kubectl get configmap nginx-config -o yaml

Sortie

apiVersion: v1
kind: ConfigMap
data:
  nginx.conf: |
    server {
        listen 80;
        server_name localhost;
        ...

Depuis un fichier YAML

Pour un contrôle total et la gestion en GitOps :

app-config.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-settings
data:
  APP_ENV: production
  LOG_LEVEL: info
  MAX_CONNECTIONS: "100"

kubectl apply -f app-config.yaml

Valeurs toujours en string

Toutes les valeurs d’un ConfigMap sont des chaînes. Même les nombres doivent être entre guillemets : "100".

Observer et inspecter

Vue d’ensemble

kubectl get configmap

Sortie

NAME               DATA   AGE
app-settings       3      2m
nginx-config       1      1m
kube-root-ca.crt   1      10d

Contenu détaillé

kubectl describe configmap app-settings

Sortie

Name:         app-settings
Namespace:    default

Data
====
APP_ENV:
----
production

LOG_LEVEL:
----
info

Format YAML complet

kubectl get configmap app-settings -o yaml

Injecter un ConfigMap dans un Pod

Trois méthodes principales, chacune avec ses cas d’usage :

Méthode	Cas d’usage	Mise à jour auto
env + valueFrom	Variables spécifiques	Non
envFrom	Toutes les variables d’un coup	Non
Volume	Fichiers de configuration	Oui, après propagation

Glissez pour voir

Méthode 1 : Variable d’environnement spécifique

Injectez une ou plusieurs clés comme variables :

deployment-env.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: app
        image: nginx
        env:
        - name: APP_ENV
          valueFrom:
            configMapKeyRef:
              name: app-settings
              key: APP_ENV
        - name: LOG_LEVEL
          valueFrom:
            configMapKeyRef:
              name: app-settings
              key: LOG_LEVEL

La variable APP_ENV dans le conteneur prend la valeur de la clé APP_ENV du ConfigMap.

Méthode 2 : Toutes les variables avec envFrom

Injectez automatiquement toutes les clés du ConfigMap :

deployment-envfrom.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: app
        image: nginx
        envFrom:
        - configMapRef:
            name: app-settings

Chaque clé du ConfigMap devient une variable d’environnement :

kubectl exec deploy/myapp -- env | grep -E 'APP_|LOG_|MAX_'

Sortie

APP_ENV=production
LOG_LEVEL=info
MAX_CONNECTIONS=100

Méthode 3 : Monter comme volume

Pour des fichiers de configuration complets :

deployment-volume.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        volumeMounts:
        - name: config
          mountPath: /etc/nginx/conf.d
      volumes:
      - name: config
        configMap:
          name: nginx-config

Le fichier /etc/nginx/conf.d/nginx.conf contient le contenu du ConfigMap.

Volume = fichiers mis à jour automatiquement

Quand vous modifiez le ConfigMap, Kubernetes met à jour les fichiers montés automatiquement (délai ~60 secondes). Les variables d’environnement ne bénéficient pas de cette mise à jour.

Les pièges de la mise à jour

Modifier un ConfigMap ne met pas automatiquement à jour vos Pods dans tous les cas. Comprendre ces comportements évite de mauvaises surprises en production.

Piège 1 : Variables d’environnement jamais rafraîchies

Les variables d’environnement sont lues une seule fois au démarrage du conteneur :

# Modifier le ConfigMap
kubectl patch configmap app-settings --type merge -p '{"data":{"APP_ENV":"staging"}}'

# La variable dans le Pod garde l'ancienne valeur
kubectl exec deploy/myapp -- printenv APP_ENV
# Affiche : production (pas staging !)

Solution : redémarrer les Pods

kubectl rollout restart deployment myapp

Piège 2 : subPath ne se met jamais à jour

Si vous utilisez subPath pour monter un fichier spécifique, il n’est jamais mis à jour :

NE SERA PAS MIS À JOUR

volumeMounts:
- name: config
  mountPath: /etc/nginx/nginx.conf
  subPath: nginx.conf              # ⚠️ Pas de refresh auto

Le fichier garde son contenu initial, même après modification du ConfigMap.

Solution : éviter subPath ou redémarrer le Pod

SE MET À JOUR

volumeMounts:
- name: config
  mountPath: /etc/nginx/conf.d     # Dossier entier, pas subPath

Piège 3 : Délai de propagation

Même pour les volumes sans subPath, la propagation prend jusqu’à 60 secondes (selon le sync period du kubelet).

# Modifier le ConfigMap
kubectl patch configmap nginx-config --type merge \
  -p '{"data":{"nginx.conf":"server { listen 8080; }"}}'

# Attendre ~60 secondes
sleep 60

# Vérifier la mise à jour
kubectl exec deploy/nginx -- cat /etc/nginx/conf.d/nginx.conf

Récapitulatif des comportements

Injection	Mise à jour auto ?	Action requise
env / envFrom	Non	kubectl rollout restart
Volume	Oui (~60s)	Attendre ou restart
Volume + subPath	Non	kubectl rollout restart

Glissez pour voir

Conseil production

Pour les configurations critiques, préférez un rollout restart explicite après modification du ConfigMap. Cela garantit que tous les Pods utilisent la nouvelle configuration.

ConfigMap immutable

En production, marquez vos ConfigMaps comme immutables pour :

• Empêcher les modifications accidentelles
• Améliorer les performances (Kubernetes ne surveille plus les changements)

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-settings-v1
data:
  APP_ENV: production
immutable: true

Un ConfigMap immutable améliore la sécurité opérationnelle et limite les modifications accidentelles, mais il impose un workflow de versionnement explicite.

Toute tentative de modification échoue :

kubectl patch configmap app-settings-v1 --type merge -p '{"data":{"APP_ENV":"staging"}}'

Sortie

The ConfigMap "app-settings-v1" is invalid: data: Forbidden: field is immutable when `immutable` is set

Workflow avec ConfigMaps immutables :

1. Créer un nouveau ConfigMap avec un nom versionné (ex: app-settings-v2)
2. Mettre à jour le Deployment pour pointer vers le nouveau ConfigMap
3. Supprimer l’ancien ConfigMap quand il n’est plus utilisé

Bonnes pratiques

Nommer clairement

Bon

myapp-config
nginx-config-prod
database-settings

À éviter

config1
test-config
temp-settings

Organiser par namespace

Un ConfigMap par environnement, dans son namespace :

kubectl create configmap myapp-config -n production --from-file=config.yaml
kubectl create configmap myapp-config -n staging --from-file=config-staging.yaml

Limiter la taille

Un ConfigMap ne peut pas dépasser 1 Mo. Pour des fichiers volumineux, utilisez un PersistentVolume ou une ConfigMap par fichier.

Versionner en GitOps

Stockez vos ConfigMaps en YAML dans Git pour tracer les changements et permettre les rollbacks.

Debug : problèmes courants

1. Le ConfigMap existe-t-il ?

   kubectl get configmap app-settings

   Si “NotFound”, créez-le d’abord.

2. La clé existe-t-elle ?

   kubectl get configmap app-settings -o jsonpath='{.data.APP_ENV}'

   Vérifiez l’orthographe exacte de la clé.

3. Le Pod référence-t-il le bon ConfigMap ?

   kubectl describe pod myapp-xxx | grep -A5 "Environment\|Mounts"

4. Le Pod a-t-il redémarré après modification ?

   Pour les variables d’environnement, un rollout restart est nécessaire.

Erreurs fréquentes

Erreur	Cause	Solution
CreateContainerConfigError	ConfigMap ou clé introuvable	Vérifier le nom et la clé
Variable vide	Clé mal orthographiée	kubectl describe cm pour vérifier
Fichier non mis à jour	subPath utilisé	Éviter subPath ou restart

Glissez pour voir

Testez vos Connaissances

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

7 questions

5 min.

80% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

1. Un ConfigMap stocke la configuration non sensible sous forme de paires clé-valeur
2. Trois méthodes d’injection : env, envFrom, volume
3. Les variables d’environnement ne sont jamais rafraîchies sans redémarrer le Pod
4. Les volumes se mettent à jour automatiquement (~60s), sauf avec subPath
5. Utiliser immutable: true en production pour éviter les modifications accidentelles
6. Pour les données sensibles, utilisez un Secret

Prochaines étapes

Secrets Stocker les données sensibles (mots de passe, clés API)

StorageClass Comprendre le stockage persistant dans Kubernetes

Deployments Gérer le cycle de vie de vos applications

×

📖 Voir la documentation →