## Introduction L'exploitation des ConfigMaps en production exige une approche disciplinée et fondée sur des listes de contrôle. Une ConfigMap est un objet Kubernetes essentiel qui découple la configuration du code applicatif, permettant d'injecter des variables d'environnement, des arguments de ligne de commande ou des fichiers de configuration dans les Pods sans reconstruire les images de conteneurs. Toutefois, cette flexibilité introduit des risques opérationnels : une ConfigMap mal formée peut casser plusieurs déploiements simultanément, une clé manquante peut provoquer des boucles de crash, et une modification non autorisée peut exposer des réglages sensibles. Cet article fournit une liste de contrôle pratique pour l'exploitation des ConfigMaps Kubernetes en production, destinée aux développeurs, consultants DevOps et équipes techniques de startups. L'objectif est la sécurité opérationnelle : observer avant de modifier, limiter le rayon d'impact, utiliser des espaces réservés au lieu de secrets, vérifier le résultat et documenter les chemins de récupération. Nous parcourrons des scénarios concrets, des commandes, des sorties attendues, des signaux d'échec et des décisions de récupération. Chaque section s'appuie sur la précédente, de l'inventaire de l'environnement aux chemins de configuration sûrs, en passant par la vérification, le diagnostic, les modes de défaillance et une liste de contrôle consolidée. Avant de commencer, assurez-vous de disposer d'un cluster Kubernetes en cours d'exécution (la version 1.21 ou ultérieure est supposée) et de kubectl configuré avec les autorisations appropriées. Toutes les commandes sont illustratives ; remplacez les noms de ressources et les espaces de noms par les vôtres. ## Inventaire des versions et de l'environnement Avant toute modification, établissez l'état actuel de votre cluster, des ressources ConfigMap et des charges de travail qui les consomment. Cet inventaire réduit le risque d'affecter une ressource non prévue et fournit une base de référence pour le retour en arrière. ### Vérifier la version du cluster et de kubectl Vérifiez la version de votre cluster et la compatibilité de kubectl : ```bash kubectl version --client ``` La sortie attendue inclut la version du client. Par exemple : ``` Client Version: v1.24.2 ``` Si vous avez besoin de la version du serveur, exécutez `kubectl version` sans l'option obsolète `--short` ou utilisez `kubectl get nodes` ; toutefois, pour les ConfigMaps, l'API v1 est stable depuis Kubernetes 1.6, donc les différences de version sont rarement un problème, mais il vaut la peine de confirmer la compatibilité du client. ### Identifier les espaces de noms et les ConfigMaps Listez toutes les ConfigMaps dans l'espace de noms cible. Supposons que votre application s'exécute dans l'espace de noms `payment-processing` : ```bash kubectl get configmaps -n payment-processing ``` Exemple de sortie : ``` NAME DATA AGE app-config 4 12d db-config 2 30d logging-config 1 7d ``` Notez le nom, le nombre de clés de données et l'âge. Une ConfigMap anormalement ancienne peut indiquer une configuration obsolète encore utilisée. ### Déterminer quelles charges de travail utilisent une ConfigMap Trouvez les Deployments, StatefulSets, DaemonSets ou Pods qui référencent une ConfigMap spécifique. Pour une ConfigMap nommée `app-config` : ```bash kubectl get deployments,statefulsets,daemonsets -n payment-processing -o json | jq '.items[] | select(.spec.template.spec.volumes[]?.configMap.name == "app-config" or .. | .configMapKeyRef?.name? == "app-config" or .configMapRef?.name? == "app-config") | {kind: .kind, name: .metadata.name}' ``` Si vous n'avez pas jq, une approche plus simple mais moins précise consiste à filtrer les exportations YAML avec grep : ```bash kubectl get deployments -n payment-processing -o yaml | grep -B5 -A10 "app-config" ``` Cela vous aide à comprendre le rayon d'impact d'un changement de ConfigMap. Par exemple, si trois Deployments utilisent `app-config`, une valeur incorrecte pourrait tous les mettre hors service. ### Capturer le contenu actuel de la ConfigMap Exportez la ConfigMap vers un fichier de sauvegarde avant toute modification : ```bash kubectl get configmap app-config -n payment-processing -o yaml > app-config-backup-$(date +%Y%m%d%H%M%S).yaml ``` Cette sauvegarde est essentielle pour le retour en arrière. Conservez-la dans un système de contrôle de version ou un emplacement sécurisé. ### Vérification des prérequis Assurez-vous de disposer des éléments suivants : - Les autorisations pour obtenir, lister et mettre à jour les ConfigMaps dans l'espace de noms cible (rôles RBAC `get`, `list`, `update`, `patch` sur `configmaps`). - Une compréhension claire de la version de l'application qui attend quelles clés de configuration. Si une application exige une nouvelle clé absente de la ConfigMap, elle peut échouer. - Une fenêtre de maintenance si le changement est risqué. ## Chemin de configuration sûr Un chemin de configuration sûr signifie effectuer des modifications de manière à minimiser les risques. Cela implique d'utiliser des pratiques immuables lorsque c'est possible, de tester dans un espace de noms de staging et d'appliquer les modifications de manière incrémentale. Comme les ConfigMaps ne sont pas immuables par défaut, vous devez imposer vos propres contrôles de sécurité. ### Traiter les ConfigMaps comme immuables lorsque c'est possible Depuis Kubernetes 1.21, vous pouvez définir le champ `immutable` d'une ConfigMap sur true. Cela empêche les mises à jour accidentelles et vous oblige à créer une nouvelle ConfigMap et à déployer un nouveau Deployment lorsque la configuration change. Pour les configurations de production critiques, c'est une protection solide. Exemple de déclaration de ConfigMap immuable : ```yaml apiVersion: v1 kind: ConfigMap metadata: name: payment-gateway-config namespace: payment-processing immutable: true data: gateway.endpoint: "https://api.example.com" retry.maxAttempts: "3" ``` Lorsque vous essayez de mettre à jour une ConfigMap immuable, kubectl renvoie une erreur : ``` configmap/payment-gateway-config is immutable ``` Vous devez alors créer une nouvelle ConfigMap (par exemple, `payment-gateway-config-v2`) et mettre à jour le Deployment pour la référencer. Un redémarrage en continu des Pods est nécessaire pour prendre en compte la nouvelle configuration. Ce processus rend le changement explicite et révisable. ### Utiliser un espace de noms de staging pour les tests Avant d'appliquer des modifications à la production, testez-les dans un espace de noms comme `staging` ou un espace de noms de développement dédié. Créez la même ConfigMap là-bas et déployez un Pod ou un Deployment de test qui la consomme. Exemple : créez une ConfigMap de test à partir d'un fichier en utilisant une kustomization. Créez un `kustomization.yaml` dans un répertoire : ```yaml apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization configMapGenerator: - name: app-config-test files: - config.properties ``` Ensuite, appliquez-le à l'espace de noms de staging : ```bash kubectl apply -k . -n staging ``` Cela génère une ConfigMap avec un nom haché basé sur le contenu. Utilisez `kubectl get configmaps -n staging` pour voir le nom généré. Ensuite, exécutez un Pod temporaire qui affiche la valeur d'une clé pour vérifier : ```bash kubectl run config-test-pod --image=busybox -n staging --restart=Never --rm -it -- /bin/sh -c 'echo $CONFIG_KEY' ``` Définissez les variables d'environnement à partir de la ConfigMap en utilisant `--env-from` ou définissez-les dans un Deployment de test. ### Appliquer les modifications avec kubectl apply et enregistrer l'intention Utilisez `kubectl apply` au lieu de `kubectl edit` pour les changements en production. L'application d'un fichier YAML depuis un système de contrôle de version fournit une piste d'audit. Avant d'appliquer, examinez la différence : ```bash kubectl diff -f updated-app-config.yaml -n payment-processing ``` La sortie attendue montre les différences, par exemple : ```diff --- /tmp/LIVE-123/configmap/app-config +++ /tmp/MERGED-456/configmap/app-config @@ -3,7 +3,7 @@ data: db.host: db.internal - db.port: "5432" + db.port: "5433" ``` Si la différence est correcte, appliquez : ```bash kubectl apply -f updated-app-config.yaml -n payment-processing ``` Enregistrez le changement dans votre système de gestion des changements avec un plan de retour en arrière. ### Limiter le rayon d'impact en utilisant des ConfigMaps séparées Ne mettez pas toute la configuration de différents services dans une seule ConfigMap géante. Créez plutôt une ConfigMap par application ou par préoccupation (par exemple, `db-config`, `cache-config`, `app-config`). Ainsi, modifier la chaîne de connexion à la base de données n'affecte pas un service non lié. ### Éviter de stocker des secrets dans les ConfigMaps Les ConfigMaps ne sont pas chiffrées au repos par défaut. Ne mettez jamais de mots de passe, de clés API ou de jetons dans les ConfigMaps. Utilisez les Secrets Kubernetes pour les données sensibles et envisagez des outils de gestion de secrets externes comme Vault ou Sealed Secrets. Si vous trouvez un secret dans une ConfigMap, migrez-le immédiatement et faites tourner les informations d'identification. Exemple d'entrée de ConfigMap non sécurisée : ```yaml data: database.password: "S3cr3t!" ``` Au lieu de cela, stockez le mot de passe dans un Secret et référencez-le dans la spécification de votre Pod : ```yaml env: - name: DB_PASSWORD valueFrom: secretKeyRef: name: db-secret key: password ``` ## Vérification et diagnostic Après avoir appliqué un changement de ConfigMap, vérifiez qu'il a pris effet correctement et que les applications sont saines. La vérification est un processus actif : ne présumez pas du succès sans vérifier. ### Vérifier les données de la ConfigMap Récupérez la ConfigMap et confirmez les clés et valeurs attendues : ```bash kubectl get configmap app-config -n payment-processing -o yaml ``` Recherchez les données mises à jour. Si vous avez utilisé `kubectl apply`, la version de la ressource changera. Vous pouvez également utiliser `kubectl describe` pour un résumé : ```bash kubectl describe configmap app-config -n payment-processing ``` ### Déclencher une mise à jour en continu Si votre Deployment consomme la ConfigMap via des variables d'environnement ou des montages de volume, les Pods ne redémarreront pas automatiquement lorsque la ConfigMap change (sauf si vous utilisez un outil comme Reloader). Pour appliquer la nouvelle configuration, vous devez redémarrer les Pods. Pour un Deployment nommé `payment-service` : ```bash kubectl rollout restart deployment/payment-service -n payment-processing ``` Surveillez l'état du déploiement : ```bash kubectl rollout status deployment/payment-service -n payment-processing ``` Sortie attendue en cas de succès : ``` deployment "payment-service" successfully rolled out ``` Si le déploiement échoue, la commande se termine avec un code non nul et affiche une erreur, telle que : ``` error: deployment "payment-service" exceeded its progress deadline ``` ### Vérifier les journaux des Pods et l'environnement Inspectez les Pods pour vous assurer qu'ils ont démarré avec la nouvelle configuration. Listez les Pods : ```bash kubectl get pods -n payment-processing -l app=payment-service -o wide ``` Vérifiez les journaux pour les erreurs indiquant des problèmes de configuration : ```bash kubectl logs deployment/payment-service -n payment-processing --tail=50 ``` Si un Pod spécifique est en boucle de crash, utilisez `--previous` : ```bash kubectl logs --previous -n payment-processing ``` Vérifiez la variable d'environnement réelle dans un Pod en cours d'exécution (si la ConfigMap est utilisée comme variable d'environnement) : ```bash kubectl exec -n payment-processing -- printenv DB_HOST ``` Pour les fichiers de configuration montés en volume, exécutez une commande dans le Pod et affichez le fichier : ```bash kubectl exec -n payment-processing -- cat /etc/config/db.properties ``` ### Utiliser le transfert de port pour la vérification locale Si votre application expose un endpoint HTTP qui reflète sa configuration (comme un endpoint de santé ou d'information), vous pouvez transférer un port local vers le Pod et l'interroger : ```bash kubectl port-forward deployment/payment-service 8080:8080 -n payment-processing ``` Ensuite, dans un autre terminal : ```bash curl http://localhost:8080/health ``` Vérifiez que la réponse indique un état sain et une configuration correcte. ## Modes de défaillance et récupération Même avec une planification minutieuse, les changements de ConfigMap peuvent provoquer des défaillances. Cette section répertorie les modes de défaillance courants et les étapes de récupération concrètes. ### Défaillance : clé de ConfigMap manquante Si une application attend une clé qui n'est pas présente dans la ConfigMap, elle peut échouer au démarrage avec une erreur comme `Environment variable DB_HOST not set`. **Diagnostic :** ```bash kubectl get configmap app-config -n payment-processing -o jsonpath='{.data}' ``` Comparez avec les clés attendues. **Récupération :** 1. Restaurez la clé en appliquant une ConfigMap corrigée. 2. Si vous avez une sauvegarde, utilisez `kubectl apply -f backup.yaml`. 3. Redémarrez le Deployment : `kubectl rollout restart deployment/payment-service`. ### Défaillance : erreur de référence de ConfigMap Si une spécification de Pod référence une ConfigMap qui n'existe pas, le Pod ne démarrera pas et le journal des événements affichera `MountVolume.SetUp failed for volume ... configmap not found`. **Diagnostic :** ```bash kubectl describe pod -n payment-processing ``` Recherchez les événements : ``` Warning FailedMount 10s (x10 over 2m) kubelet MountVolume.SetUp failed for volume "config-volume" : configmap "missing-config" not found ``` **Récupération :** - Créez la ConfigMap manquante avec le nom et les données corrects. - Ou corrigez la spécification du Pod pour référencer la bonne ConfigMap (nécessite de mettre à jour le Deployment). ### Défaillance : ConfigMap trop volumineuse Les ConfigMaps sont stockées dans etcd et ont une taille maximale de 1 Mio (1 048 576 octets). Si vous essayez de créer ou de mettre à jour une ConfigMap plus grande que cela, le serveur d'API la rejette : ``` configmap "large-config" is invalid: metadata.annotations: Too long: must have at most 262144 bytes ``` C'est une erreur rare mais possible. Elle peut également se produire si la taille totale des métadonnées dépasse les limites. **Récupération :** - Divisez la configuration en plusieurs ConfigMaps. - Pour les fichiers volumineux, envisagez d'utiliser un PersistentVolume ou un conteneur d'initialisation pour récupérer la configuration à partir d'une source distante. ### Défaillance : application non réactive après la mise à jour de la ConfigMap L'application peut démarrer mais se comporter incorrectement en raison d'une mauvaise valeur de configuration (par exemple, un mauvais port de base de données). **Diagnostic :** - Vérifiez les journaux de l'application pour les erreurs. - Vérifiez la valeur réelle dans le Pod : `kubectl exec -- printenv DB_PORT`. - Comparez avec la valeur attendue. **Récupération :** - Revenez à la version précédente de la ConfigMap en utilisant le fichier de sauvegarde : ```bash kubectl apply -f app-config-backup-YYYYMMDDHHMMSS.yaml ``` - Redémarrez le Deployment : `kubectl rollout restart deployment/payment-service`. - Surveillez les journaux et les endpoints de santé. ### Défaillance : Pod bloqué dans CrashLoopBackOff Le Pod plante de manière répétée en raison d'une configuration invalide. La ConfigMap elle-même peut être valide, mais l'application l'interprète incorrectement. **Diagnostic :** ```bash kubectl get pods -n payment-processing ``` Recherchez le statut `CrashLoopBackOff` : ``` NAME READY STATUS RESTARTS AGE payment-service-6d4b7c9f8-abcde 0/1 CrashLoopBackOff 5 4m ``` Inspectez les journaux : ```bash kubectl logs payment-service-6d4b7c9f8-abcde --previous -n payment-processing ``` Erreur courante : `Invalid value for DB_PORT: 'abc'`. **Récupération :** - Corrigez la valeur de la ConfigMap. - Si le déploiement ne peut pas être corrigé rapidement, envisagez de revenir à une ConfigMap précédente connue comme bonne et de redémarrer. - Utilisez `kubectl scale deployment payment-service --replicas=0` pour arrêter les boucles de crash pendant la correction (uniquement si le service peut être brièvement indisponible). ## Liste de contrôle des opérations Utilisez la liste de contrôle suivante comme référence rapide pour chaque changement de ConfigMap en production. Chaque élément comprend une commande ou une action et le résultat attendu. ### Avant le changement - [ ] Vérifiez les versions du cluster et de kubectl : `kubectl version --client` (attendez la sortie de la version du client ; utilisez `kubectl version` sans `--short` pour la version du serveur). - [ ] Listez les ConfigMaps cibles : `kubectl get configmaps -n ` (notez les noms, les nombres de données et les âges). - [ ] Identifiez les consommateurs : utilisez `grep` ou `jq` pour trouver les Deployments qui référencent la ConfigMap. Documentez le rayon d'impact. - [ ] Exportez la sauvegarde : `kubectl get configmap -n -o yaml > backup.yaml`. Stockez la sauvegarde en lieu sûr. - [ ] Vérifiez les données sensibles : inspectez visuellement le YAML de la ConfigMap pour les mots de passe ou les jetons. Si trouvés, migrez-les vers les Secrets et faites tourner les informations d'identification. - [ ] Examinez le changement dans le staging : appliquez la nouvelle ConfigMap dans l'espace de noms `staging`, testez avec un Pod temporaire. - [ ] Préparez le plan de retour en arrière : connaissez l'emplacement du fichier de sauvegarde et la procédure de redémarrage. ### Pendant le changement - [ ] Modifiez le YAML de la ConfigMap dans le contrôle de version (n'utilisez jamais `kubectl edit` directement). - [ ] Prévisualisez la différence : `kubectl diff -f updated.yaml -n ` (assurez-vous que seuls les changements prévus sont présents). - [ ] Appliquez : `kubectl apply -f updated.yaml -n `. - [ ] Enregistrez le changement dans le système de gestion des changements. ### Après le changement - [ ] Vérifiez le contenu de la ConfigMap : `kubectl get configmap -n -o yaml | grep `. - [ ] Redémarrez les consommateurs : `kubectl rollout restart deployment/ -n ` pour chaque Deployment affecté. - [ ] Surveillez le déploiement : `kubectl rollout status deployment/ -n ` (attendez le succès). - [ ] Vérifiez les journaux des Pods : `kubectl logs deployment/ -n --tail=50` pour les erreurs de configuration. - [ ] Validez la configuration à l'exécution : `kubectl exec -- printenv ` ou `kubectl exec -- cat /path/to/config/file`. - [ ] Testez l'endpoint de santé ou la fonctionnalité de l'application. - [ ] En cas d'échec, exécutez le retour en arrière : appliquez la ConfigMap de sauvegarde, redémarrez le déploiement, vérifiez la récupération. ### Maintenance continue - [ ] Examinez périodiquement les ConfigMaps pour les clés inutilisées ou obsolètes. - [ ] Utilisez des ConfigMaps immuables pour les configurations critiques. - [ ] Implémentez GitOps pour la gestion des ConfigMaps si possible. - [ ] Surveillez la taille des ConfigMaps approchant la limite de 1 Mio. - [ ] Auditez l'accès : assurez-vous que seuls les utilisateurs autorisés peuvent modifier les ConfigMaps (RBAC). ## Conclusion L'exploitation des ConfigMaps Kubernetes en production exige la même rigueur que tout changement d'infrastructure. La liste de contrôle présentée ici met l'accent sur l'observation avant l'intervention, la manipulation sécurisée des données sensibles, l'application contrôlée des changements, la vérification approfondie et des procédures de récupération claires. Une ConfigMap est un objet simple, mais son mauvais usage peut provoquer des pannes généralisées. En suivant cette liste de contrôle, vous réduisez le risque de conséquences imprévues, raccourcissez le temps de réponse aux incidents et construisez une culture de gestion de configuration sûre. N'oubliez pas : l'objectif opérationnel n'est pas seulement d'apporter des modifications, mais de les rendre visibles, réversibles et vérifiables. Comme prochaine étape, sélectionnez une amélioration de ConfigMap à faible risque dans votre environnement actuel. Appliquez les pratiques d'inventaire et de chemin de configuration sûr, et documentez le résultat. Ensuite, étendez la même discipline à d'autres ressources de configuration Kubernetes, telles que les Secrets et les Deployments, pour créer un cadre opérationnel cohérent. Un flux de travail technique fiable rend les défaillances visibles, protège les valeurs sensibles, limite les changements à la ressource prévue et définit la vérification de la récupération avant qu'un incident ne force la décision.