Un ConfigMap est une ressource Kubernetes pour injecter la configuration dans vos conteneurs. Ils vous permettent de conserver les paramètres de votre pile séparément de son code. Voici comment travailler avec ConfigMaps et les fournir à vos pods.
À quoi servent les ConfigMaps ?
Les ConfigMaps sont spécialement conçues pour encapsuler de petites quantités de données de configuration non sensibles. Il s'agit d'un mécanisme permettant d'obtenir des paires clé-valeur arbitraires dans vos pods. Ils sont couramment utilisés pour stocker l'adresse IP de votre serveur de base de données, l'adresse e-mail sortante de votre application et d'autres paramètres spécifiques à l'application que vous devez configurer en dehors de vos pods.
Le ConfigMap vous permet de gérer ces données dans une ressource Kubernetes dédiée. Les pods reçoivent les paires clé-valeur sous forme de variables d'environnement ou de fichiers dans un volume monté.
Pour quoi ne pas les utiliser ?
Il existe certaines situations où un ConfigMap ne devrait pas être utilisé.
Les ConfigMaps ne sont pas stockées en toute sécurité et leurs valeurs ne sont pas chiffrées. Ils ne doivent contenir aucune donnée sensible ou confidentielle qui constituerait un risque pour la sécurité ou la confidentialité en cas de fuite.
Ne mettez pas de mots de passe, de clés API ou de clés de chiffrement dans un ConfigMap - utilisez plutôt un secret Kubernetes, car ils fonctionnent de la même manière que ConfigMaps mais avec des protections supplémentaires. Les systèmes nécessitant une connexion à la base de données doivent placer le nom d'hôte dans un ConfigMap et les informations d'identification dans un secret séparé.
Les ConfigMaps individuelles ne peuvent pas dépasser 1 Mo. Les systèmes qui ont besoin de plus de clés de configuration peuvent être mieux servis par une approche alternative telle que l'injection de fichiers de configuration générés manuellement via un volume.
Si vous souhaitez vous en tenir à ConfigMaps, envisagez de répartir votre configuration sur plusieurs ressources ConfigMap. Cette approche devrait éviter le plafond de 1 Mo tout en vous permettant de fournir à chacun de vos pods le jeu minimal de clés de configuration dont il a besoin.
Les valeurs ConfigMap peuvent être des chaînes UTF-8 ou des données binaires encodées sous forme de chaîne base64. Les noms de clé peuvent contenir des caractères alphanumériques, . (point), - (trait d'union), et _ (trait de soulignement). Certains langages de programmation et frameworks peuvent avoir une convention différente pour les variables de configuration. Assurez-vous donc d'utiliser un format pris en charge à la fois par Kubernetes et votre application.
Créer une ConfigMap
Les ConfigMaps ont des manifestes YAML simples. Chaque ConfigMap a besoin d'un name au format Kubernetes standard et une data champ contenant vos paires clé-valeur :
apiVersion: v1 kind: ConfigMap metadata: name: example-configmap data: database_host: "192.168.0.10" system_email: "[email protected]"
Les data champ sert à spécifier des clés avec des valeurs de chaîne. Vous pouvez utiliser binaryData à la place ou en plus de data pour ajouter des valeurs binaires encodées en base64. Les clés doivent être uniques pour les deux data et binaryData .
Appliquez le manifeste à votre cluster à l'aide de kubectl ou votre outil préféré.
Lier ConfigMaps et Pods
Un ConfigMap ne fait rien par lui-même. Vous avez ajouté des données à votre cluster ; Associons-le maintenant à un pod :
apiVersion: v1
kind: Pod
metadata:
name: example-pod
spec:
containers:
- name: example-container
image: example-image:latest
envFrom:
- configMapRef:
name: example-configmap
Le envFrom champ récupère les variables d'environnement définies par une autre ressource référencée. Dans ce cas, un configMapRef identifie la ConfigMap créée précédemment. Les conteneurs du pod seront démarrés avec database_host et system_email variables d'environnement définies.
Ajout sélectif de variables d'environnement
envFrom est utile lorsque vous souhaitez consommer toutes les clés de la ConfigMap et que vous êtes certain qu'il n'y aura pas de conflits avec les autres variables d'environnement de votre Pod. Dans des situations plus contrôlées, utilisez un env normal section, définissez des clés individuelles et extrayez la valeur de chaque clé de la ConfigMap :
env:
- name: DATABASE_HOST_IP
valueFrom:
configMapKeyRef:
name: example-configmap
key: database_host
Cet exemple montre comment un pod peut être démarré avec uniquement le database_host clé de la ConfigMap. La clé est également renommée avant l'injection afin que le pod la reçoive en tant que DATABASE_HOST_IP .
Utilisation de ConfigMaps avec des volumes
Les ConfigMaps peuvent être montés sous forme de fichiers dans les pods. Kubernetes crée un volume, injecte le contenu de ConfigMap sous la forme d'un ensemble de fichiers et monte le volume sur votre pod.
apiVersion: v1
kind: Pod
metadata:
name: example-pod
spec:
containers:
- name: example-container
image: example-image:latest
volumeMounts:
- name: app-config
mountPath: "/etc/config-data"
readOnly: true
volumes:
- name: app-config
configMap:
name: example-configmap
Ce manifeste de pod crée un volume appelé app-config . La configMap préremplira le volume en utilisant les données du ConfigMap spécifié.
Le pod monte le volume sur /etc/config-data . Vos conteneurs peuvent lire les fichiers du répertoire pour accéder à vos valeurs de configuration. Chaque clé ConfigMap aura son propre fichier dans le point de montage.
Mise à jour des valeurs ConfigMap
Comme un ConfigMap est une ressource d'API Kubernetes standard, vous pouvez mettre à jour les valeurs à tout moment en modifiant votre manifeste et en le réappliquant à votre cluster. La façon dont les nouvelles valeurs atteignent vos pods dépend du mécanisme d'injection que vous utilisez.
Volumes montés
Les ConfigMaps montés dans les pods via un volume seront mis à jour par Kubernetes. Les modifications apportées à ConfigMaps sont vérifiées périodiquement ; lorsqu'une différence est détectée, les fichiers de votre volume seront mis à jour, de sorte que votre Pod recevra les nouvelles données. Le délai dépend de l'intervalle de synchronisation configuré pour les instances Kubelet sur vos noeuds worker.
Variables d'environnement
La modification des variables d'environnement d'un pod n'est pas possible. Les modifications de ConfigMap n'atteindront donc pas les pods existants qui font référence à des clés via ce mécanisme. Vous devez remplacer vos pods pour utiliser les nouvelles données.
Les pods nouvellement créés recevront toujours les données ConfigMap actuelles, que vous utilisiez des volumes ou des variables d'environnement. Si vous devez forcer une mise à jour de la configuration, modifiez une annotation sur votre pod pour que Kubernetes la recrée.
ConfigMaps immuables
Les ConfigMaps ont un immutable facultatif champ qui empêche leur mise à jour. Lorsque ce champ est défini, vous ne pouvez pas mettre à jour les données de ConfigMap ni supprimer le statut immuable.
apiVersion: v1 kind: ConfigMap metadata: name: immutable-configmap data: foo: bar immutable: true
Cela peut être utile lorsque vous êtes certain que les valeurs de configuration ne changeront jamais. Il améliore la sécurité en supprimant la possibilité de modifications accidentelles. Les performances peuvent également être améliorées car Kubernetes n'a plus besoin de surveiller le ConfigMap pour propager les modifications de valeur dans vos pods.
Résumé
ConfigMaps devrait être votre référence pour fournir des clés de configuration non sensibles à vos pods Kubernetes. Il s'agit d'une ressource API de première classe que vous pouvez utiliser en tant que variables d'environnement ou fichiers montés en volumes.
Les mots de passe et autres informations d'identification appartiennent aux secrets. Ceux-ci fonctionnent de manière très similaire à ConfigMaps et sont référencés par les pods de la même manière. Remplacez configMapRef avec secretRef pour extraire une clé d'un secret nommé au lieu d'un ConfigMap.