Agence web » Actualités du digital » Comment utiliser ConfigMaps pour la configuration Kubernetes

Comment utiliser ConfigMaps pour la configuration Kubernetes

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é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 y a des situations où un ConfigMap devrait ne 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.

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 à 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, . (période), - (trait d’union), et _ (souligné) caractères. 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éer une ConfigMap

Les ConfigMaps ont des manifestes YAML simples. Chaque ConfigMap a besoin d’un name au format Kubernetes standard et un data champ contenant vos paires clé-valeur :

apiVersion: v1
kind: ConfigMap
metadata:
  name: example-configmap
data:
  database_host: "192.168.0.10"
  system_email: "k8s@example.com"

Les data Le champ sert à spécifier des clés avec des valeurs de chaîne. Vous pouvez utiliser binaryData à la place ou aussi bien que data pour ajouter des valeurs binaires codées en base64. Les clés doivent être uniques dans les deux data et binaryData.

Appliquez le manifeste à votre cluster en utilisant kubectl ou votre outil préféré.

Lier des ConfigMaps et des pods

Un ConfigMap ne fait rien tout seul. Vous avez ajouté des données à votre cluster ; lions-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

Les envFrom Le champ 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 database_host et system_email variables d’environnement définies.

Ajout sélectif de variables d’environnement

envFrom est utile lorsque vous souhaitez utiliser chaque clé 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 un env section, définissez des clés individuelles et extrayez la valeur de chaque clé du 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 juste le database_host clé de la ConfigMap. La clé est également renommée avant l’injection afin que le Pod la reçoive comme 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 la ConfigMap sous forme d’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. Les configMap Le champ pré-remplira le volume à l’aide des données du ConfigMap spécifié.

Le Pod monte le volume sur /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, 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 afin que Kubernetes la recrée.

ConfigMaps immuables

Les ConfigMaps ont une option immutable champ 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

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.

Sommaire

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 à 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. Remplacer configMapRef avec secretRef pour extraire une clé d’un secret nommé au lieu d’un ConfigMap.