Comprendre Kubernetes ConfigMaps
Dans le référentiel d’applications, il existe un fichier config chargé dans le fichier index.html pour permettre la mise à jour des variables d’environnement sans qu’une build d’image complète soit nécessaire.
Le fichier config ne contient pas d’informations sensibles, il doit simplement être chargé avec le conteneur. Comment le fichier peut-il être monté dans le conteneur sans nécessiter de chiffrement ou d’encodage ?
Comprendre les ConfigMaps
Les ConfigMaps sont les équivalents des secrets. Alors que les secrets fournissent un moyen de stocker et de délivrer des données sensibles, les ConfigMaps sont des objets qui offrent un moyen de stocker des données non sensibles en utilisant la même structure clé-valeur qu’un secret. L’objet ConfigMaps vous autorise à découpler des configurations des images conteneur, ce qui permet à ces images de rester sans état.
Vous créez un ConfigMap pour stocker les données de configuration séparément du code de l’application et de les charger presque de manière similaire à la façon dont nous chargeons des objets Secret dans le pod. Vous pouvez référencer des ConfigMaps uniquement à l’aide d’une variable d’environnement, ou en les montant en tant que fichier dans un volume à l’intérieur du conteneur.
Les ConfigMaps ont une limitation pour la taille des données : vous pouvez stocker jusqu’à 1 Mio de données dans un ConfigMap. La limitation de taille vous permet d’éviter les grands fichiers config complexes, en vous faisant diviser les grandes configurations en blocs plus petits. Avec les ConfigMaps, vous pouvez monter seulement les fichiers config nécessaires dans vos conteneurs, ce qui permet davantage de granularité.
Comme les secrets, les ConfigMaps sont limités à un espace de noms. Vous pouvez accéder à un ConfigMap et le monter uniquement à l’aide des conteneurs présents dans le même espace de noms que celui dans lequel il a été créé.
Les ConfigMaps sont aussi largement utilisés par d’autres outils, comme Helm et les opérateurs Kubernetes, pour stocker et lire des états.
Mises à jour des ConfigMaps
Tous les ConfigMaps qui sont montés en tant que volumes à l’intérieur d’un pod sont automatiquement mis à jour quand leur valeur est modifiée. Cette modification peut ne pas se produire immédiatement en raison de la configuration de Kubelet, mais elle se produit automatiquement ; il n’est par conséquent pas nécessaire de redémarrer le pod.
Lorsqu’un ConfigMap est lié à des variables d’environnement, il n’est pas mis à jour automatiquement. Dans ce cas, il est nécessaire de redémarrer le pod pour que les modifications prennent effet.
Créer et utiliser des ConfigMaps
Vous pouvez créer un ConfigMap en utilisant la même approche que pour le secret : un fichier YAML. La spécification du ConfigMap se fait comme suit :
apiVersion: v1
kind: ConfigMap
metadata:
name: configmap-name
namespace: default
data:
key-name: "value as key"
key.name: |
multi line
property, called "file-like" values
Vous pouvez référencer les ConfigMaps par une ou plusieurs clés dans la spécification d’un pod ou d’un déploiement, comme dans l’exemple suivant :
apiVersion: v1
kind: Pod
metadata:
name: configmap-as-env
namespace: default
spec:
containers:
- name: configmap-env
image: alpine
command: ["sleep", "3600"]
env:
- name: ENVIRONMENT_VARIABLE_NAME
valueFrom:
configMapKeyRef:
name: configmap-name
key: key-name
Vous pouvez également les monter en tant que fichiers à l’intérieur du pod à l’aide de volumes en lecture seule, comme dans l’exemple suivant :
apiVersion: v1
kind: Pod
metadata:
name: configmap-as-env
namespace: default
spec:
containers:
- name: configmap-env
image: alpine
command: ["sleep", "3600"]
volumeMounts:
- name: volume-name
mountPath: "/path/to/mount"
readOnly: true
volumes:
- name: volume-name
configMap:
name: configmap-name
items:
- key: "key-name"
path: "path/to/mount/the/key"