Eine ConfigMap ist eine Kubernetes-Ressource zum Einfügen von Konfigurationen in Ihre Container. Sie ermöglichen es Ihnen, die Einstellungen Ihres Stacks getrennt von seinem Code zu verwalten. So arbeiten Sie mit ConfigMaps und stellen sie Ihren Pods bereit.
Wozu dienen ConfigMaps?
ConfigMaps wurden speziell entwickelt, um kleine Mengen nicht sensibler Konfigurationsdaten zu kapseln. Sie sind ein Mechanismus, um beliebige Schlüssel-Wert-Paare in Ihre Pods zu bekommen. Sie werden häufig verwendet, um die IP-Adresse Ihres Datenbankservers, die ausgehende E-Mail-Adresse für Ihre Anwendung und andere anwendungsspezifische Einstellungen zu speichern, die Sie außerhalb Ihrer Pods konfigurieren müssen.
Mit der ConfigMap können Sie diese Daten in einer dedizierten Kubernetes-Ressource verwalten. Pods erhalten die Schlüssel-Wert-Paare als Umgebungsvariablen oder Dateien in einem gemounteten Volume.
Wofür sollte man sie nicht verwenden?
Es gibt einige Situationen, in denen eine ConfigMap nicht sollte verwendet werden.
ConfigMaps werden nicht sicher gespeichert und ihre Werte sind nicht verschlüsselt. Sie dürfen keine sensiblen oder vertraulichen Daten enthalten, die bei einem Durchsickern ein Sicherheits- oder Datenschutzrisiko darstellen würden.
Fügen Sie keine Passwörter, API-Schlüssel oder Verschlüsselungsschlüssel in eine ConfigMap ein – verwenden Sie stattdessen ein Kubernetes-Secret, da diese ähnlich wie ConfigMaps funktionieren, jedoch mit zusätzlichem Schutz. Systeme, die eine Datenbankverbindung benötigen, sollten den Hostnamen in einer ConfigMap und die Anmeldeinformationen in einem separaten Secret platzieren.
Einzelne ConfigMaps dürfen eine Größe von 1 MB nicht überschreiten. Systeme, die mehr Konfigurationsschlüssel benötigen, sind möglicherweise besser mit einem alternativen Ansatz bedient, wie z. B. dem Einfügen manuell generierter Konfigurationsdateien über ein Volume.
Wenn Sie bei ConfigMaps bleiben möchten, sollten Sie Ihre Konfiguration auf mehrere ConfigMap-Ressourcen aufteilen. Dieser Ansatz sollte die 1-MB-Obergrenze vermeiden, während Sie jeden Ihrer Pods mit dem minimalen Satz an Konfigurationsschlüsseln versorgen können, den er benötigt.
ConfigMap-Werte können entweder UTF-8-Strings oder binäre Daten sein, die als Base64-String codiert sind. Schlüsselnamen können alphanumerische Zeichen enthalten, . (Punkt), - (Bindestrich) und _ (Unterstrich) Zeichen. Einige Programmiersprachen und Frameworks haben möglicherweise eine andere Konvention für Konfigurationsvariablen. Stellen Sie daher sicher, dass Sie ein Format verwenden, das sowohl von Kubernetes als auch von Ihrer App unterstützt wird.
Erstellen einer ConfigMap
ConfigMaps haben einfache YAML-Manifeste. Jede ConfigMap benötigt einen name im Standard-Kubernetes-Format und ein data Feld mit Ihren Schlüssel-Wert-Paaren:
apiVersion: v1 kind: ConfigMap metadata: name: example-configmap data: database_host: "192.168.0.10" system_email: "[email protected]"
Die data Das Feld dient zum Angeben von Schlüsseln mit Zeichenfolgenwerten. Sie können binaryData verwenden stattdessen oder sowie data zum Hinzufügen von base64-codierten Binärwerten. Schlüssel müssen für beide data eindeutig sein und binaryData .
Wenden Sie das Manifest mithilfe von kubectl auf Ihren Cluster an oder Ihr bevorzugtes Tool.
Verknüpfung von ConfigMaps und Pods
Eine ConfigMap allein macht nichts. Sie haben Ihrem Cluster einige Daten hinzugefügt; Verknüpfen wir es jetzt mit einem Pod:
apiVersion: v1
kind: Pod
metadata:
name: example-pod
spec:
containers:
- name: example-container
image: example-image:latest
envFrom:
- configMapRef:
name: example-configmap
Die envFrom field ruft Umgebungsvariablen ab, die von einer anderen referenzierten Ressource definiert wurden. In diesem Fall eine configMapRef identifiziert die zuvor erstellte ConfigMap. Die Container des Pods werden mit database_host gestartet und system_email Umgebungsvariablen definiert.
Selektives Hinzufügen von Umgebungsvariablen
envFrom ist nützlich, wenn Sie jeden Schlüssel in der ConfigMap verwenden möchten und sicher sind, dass es keine Konflikte mit den anderen Umgebungsvariablen Ihres Pods gibt. Verwenden Sie in kontrollierteren Situationen ein normales env Abschnitt, definieren Sie individuelle Schlüssel und ziehen Sie den Wert jedes Schlüssels aus der ConfigMap:
env:
- name: DATABASE_HOST_IP
valueFrom:
configMapKeyRef:
name: example-configmap
key: database_host
Dieses Beispiel zeigt, wie ein Pod nur mit database_host gestartet werden kann Schlüssel aus der ConfigMap. Der Schlüssel wird vor der Injektion auch umbenannt, sodass der Pod ihn als DATABASE_HOST_IP empfängt .
Verwenden von ConfigMaps mit Volumes
ConfigMaps können als Dateien in Pods gemountet werden. Kubernetes erstellt ein Volume, fügt den Inhalt der ConfigMap als Dateisatz ein und stellt das Volume in Ihrem Pod bereit.
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
Dieses Pod-Manifest erstellt ein Volume namens app-config . Die configMap wird das Volume mit den Daten in der angegebenen ConfigMap vorbelegt.
Der Pod stellt das Volume in /etc/config-data bereit . Ihre Container können die Dateien im Verzeichnis lesen, um auf Ihre Konfigurationswerte zuzugreifen. Jeder ConfigMap-Schlüssel hat seine eigene Datei innerhalb des Einhängepunkts.
Aktualisieren von ConfigMap-Werten
Da eine ConfigMap eine standardmäßige Kubernetes-API-Ressource ist, können Sie Werte jederzeit aktualisieren, indem Sie Ihr Manifest ändern und erneut auf Ihren Cluster anwenden. Wie die neuen Werte Ihre Pods erreichen, hängt von dem Injektionsmechanismus ab, den Sie verwenden.
Gemountete Volumes
ConfigMaps, die über ein Volume in Pods bereitgestellt werden, werden von Kubernetes aktualisiert. Änderungen an ConfigMaps werden regelmäßig überprüft; Wenn ein Unterschied festgestellt wird, werden die Dateien in Ihrem Volume aktualisiert, sodass Ihr Pod die neuen Daten empfängt. Die Verzögerung hängt vom Synchronisierungsintervall ab, das für die Kubelet-Instanzen auf Ihren Worker-Knoten konfiguriert ist.
Umgebungsvariablen
Das Ändern der Umgebungsvariablen eines Pods ist nicht möglich, sodass ConfigMap-Änderungen keine vorhandenen Pods erreichen, die über diesen Mechanismus auf Schlüssel verweisen. Sie müssen Ihre Pods ersetzen, um die neuen Daten zu verwenden.
Neu erstellte Pods erhalten immer die aktuellen ConfigMap-Daten, unabhängig davon, ob Sie Volumes oder Umgebungsvariablen verwenden. Wenn Sie eine Konfigurationsaktualisierung erzwingen müssen, ändern Sie eine Anmerkung auf Ihrem Pod, damit Kubernetes sie neu erstellt.
Unveränderliche ConfigMaps
ConfigMaps haben einen optionalen immutable Feld, das verhindert, dass sie aktualisiert werden. Wenn dieses Feld gesetzt ist, können Sie die Daten der ConfigMap nicht aktualisieren oder den unveränderlichen Status entfernen.
apiVersion: v1 kind: ConfigMap metadata: name: immutable-configmap data: foo: bar immutable: true
Dies kann nützlich sein, wenn Sie sicher sind, dass sich die Konfigurationswerte nie ändern werden. Es verbessert die Sicherheit, indem es die Möglichkeit versehentlicher Änderungen beseitigt. Die Leistung kann auch verbessert werden, da Kubernetes die ConfigMap nicht mehr überwachen muss, um Wertänderungen an Ihre Pods weiterzugeben.
Zusammenfassung
ConfigMaps sollte Ihre Anlaufstelle für die Bereitstellung nicht sensibler Konfigurationsschlüssel für Ihre Kubernetes-Pods sein. Sie sind eine erstklassige API-Ressource, die Sie als Umgebungsvariablen oder gemountete Dateien in Volumes nutzen können.
Passwörter und andere Anmeldeinformationen gehören in Secrets. Diese funktionieren sehr ähnlich wie ConfigMaps und werden von Pods auf die gleiche Weise referenziert. Ersetzen Sie configMapRef mit secretRef um einen Schlüssel aus einem benannten Secret anstelle einer ConfigMap zu ziehen.