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 utiliser ConfigMaps et les fournir à vos pods.
À quoi servent ConfigMaps ?
Les ConfigMaps sont spécifiquement conçus pour encapsuler de petites quantités de données de configuration non sensibles. Ils constituent 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 en tant que variables d'environnement ou fichiers dans un volume monté.
Pourquoi ne pas les utiliser ?
Il existe certaines situations où un ConfigMap ne doit pas être utilisé.
Les ConfigMaps ne sont pas stockés de manière sécurisée et leurs valeurs ne sont pas cryptées. Ils ne doivent pas contenir de données sensibles ou confidentielles qui constitueraient un risque pour la sécurité ou la confidentialité en cas de fuite.
Publicité
Ne mettez pas de mots de passe, de clés API ou de clés de cryptage dans un ConfigMap – utilisez plutôt un secret Kubernetes, car ceux-ci fonctionnent de la même manière que ConfigMaps mais avec des protections supplémentaires. Les systèmes nécessitant une connexion à une 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 individuels 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 diviser 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 codées en tant que chaîne base64. Les noms de clé peuvent contenir des caractères alphanumériques, . (point), – (trait d'union) et _ (trait de soulignement). Certains langages et frameworks de programmation peuvent avoir une convention différente pour les variables de configuration, alors assurez-vous d'utiliser un format pris en charge à la fois par Kubernetes et votre application.
Création a ConfigMap
Les ConfigMaps ont des manifestes YAML simples. Chaque ConfigMap a besoin d'un nom au format Kubernetes standard et d'un champ de données contenant vos paires clé-valeur :
apiVersion : v1 kind : métadonnées ConfigMap : nom : example-configmap data : database_host : "192.168.0.10" system_email : "k8s@example.com"
Le champ de données sert à spécifier des clés avec des valeurs de chaîne. Vous pouvez utiliser binaryData à la place ou en plus des données pour ajouter des valeurs binaires encodées en base64. Les clés doivent être uniques pour les données et les données binaires.
Publicité
Appliquez le manifeste à votre cluster à l'aide de kubectl ou de votre outil préféré.
Lier les ConfigMaps et les Pods
Un ConfigMap ne fait rien tout seul. Vous avez ajouté des données à votre cluster ; Maintenant, lions-le à un Pod :
apiVersion : v1 kind : Pod métadonnées : name : example-pod spec : containers : – name : example-container image : example-image:latest envFrom : – configMapRef : nom : example-configmap
Le champ envFrom extrait les variables d'environnement définies par une autre ressource référencée. Dans ce cas, un configMapRef identifie le ConfigMap créé précédemment. Les conteneurs du Pod seront démarrés avec les variables d'environnement database_host et system_email définies.
Ajouter sélectivement des variables d'environnement
envFrom est utile lorsque vous souhaitez utiliser toutes les clés de la ConfigMap et que vous êtes certain qu'il n'y aura pas de conflit avec les autres variables d'environnement de votre Pod. Dans des situations plus contrôlées, utilisez une section env standard, 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 la clé database_host de 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
ConfigMaps peut être monté en tant que fichiers à l'intérieur des pods. Kubernetes crée un volume, injecte le contenu de la ConfigMap sous forme d'ensemble de fichiers et monte le volume sur votre pod.
apiVersion : v1 kind : métadonnées du pod : nom : example-pod spec : conteneurs : – nom : exemple-image du conteneur : exemple-image : dernier volumeMounts : – nom : app-config mountPath : "/etc/config-data" readOnly : true volumes : – name : app-config configMap : name : example-configmap Advertisement
Ce manifeste de pod crée un volume appelé app-config. Le champ configMap pré-remplit le volume en utilisant les données du ConfigMap spécifié.
Le Pod monte le volume dans /etc/config-data. Vos conteneurs peuvent lire les fichiers dans le 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 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 aux ConfigMaps sont vérifiées périodiquement ; lorsqu'une différence est détectée, les fichiers de votre volume seront mis à jour, ainsi votre Pod recevra les nouvelles données. Le délai dépend de l'intervalle de synchronisation configuré pour les instances Kubelet sur vos nœuds de travail.
Variables d'environnement
La modification des variables d'environnement d'un pod n'est pas possible, donc les modifications de ConfigMap n'atteindront 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 afin que Kubernetes la recrée.
ConfigMaps immuables
Les ConfigMaps ont un champ immuable facultatif qui les empêche d'être mis à jour. Lorsque ce champ est défini, vous ne pouvez pas mettre à jour les données du ConfigMap ou supprimer le statut immuable.
apiVersion : v1 kind : ConfigMap metadata : name : immutable-configmap data : foo : bar immutable : true Advertisement
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é
Les ConfigMaps devraient ê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 dans des volumes.
Les mots de passe et autres informations d'identification appartiennent à 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 par secretRef pour extraire une clé d'un secret nommé au lieu d'un ConfigMap.