Eine ConfigMap ist eine Kubernetes-Ressource zum Einschleusen 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 zur Verfügung.
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 übertragen. 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 bereitgestellten Volume.
Wofür sollten sie nicht verwendet werden?
Es gibt Situationen, in denen eine ConfigMap nicht verwendet werden sollte.
ConfigMaps werden nicht sicher gespeichert und ihre Werte werden nicht verschlüsselt. Sie dürfen keine sensiblen oder vertraulichen Daten enthalten, die bei einem Durchsickern ein Sicherheits- oder Datenschutzrisiko darstellen würden.
Werbung
Legen Sie keine Passwörter, API-Schlüssel oder Verschlüsselungsschlüssel in ein KonfigMap – 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 ablegen.
Einzelne ConfigMaps dürfen eine Größe von 1 MB nicht überschreiten. Systeme, die mehr Konfigurationsschlüssel benötigen, können durch einen alternativen Ansatz besser bedient werden, z. B. das Einschleusen von manuell generierten Konfigurationsdateien über ein Volume.
Wenn Sie bei ConfigMaps bleiben möchten, sollten Sie Ihre Konfiguration auf mehrere ConfigMap-Ressourcen aufteilen. Dieser Ansatz sollte die Obergrenze von 1 MB vermeiden, während Sie jeden Ihrer Pods mit dem minimalen Satz von Konfigurationsschlüsseln versorgen können, die er benötigt.
ConfigMap-Werte können entweder UTF-8-Strings oder als Base64-String codierte Binärdaten sein. Schlüsselnamen können alphanumerische, . (Punkt), – (Bindestrich) und _ (Unterstrich). 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 a ConfigMap
ConfigMaps haben einfache YAML-Manifeste. Jede ConfigMap benötigt einen Namen im Standard-Kubernetes-Format und ein Datenfeld mit Ihren Schlüssel-Wert-Paaren:
apiVersion: v1 Art: ConfigMap-Metadaten: Name: Beispiel-Configmap-Daten: database_host: "192.168.0.10" system_email: "k8s@example.com"
Das Datenfeld dient zum Angeben von Schlüsseln mit Zeichenfolgenwerten. Sie können binaryData stattdessen oder zusätzlich zu data verwenden, um base64-codierte Binärwerte hinzuzufügen. Schlüssel müssen sowohl für data als auch für binaryData eindeutig sein.
Werbung
Wenden Sie das Manifest mit kubectl oder Ihrem bevorzugten Tool auf Ihren Cluster an.
Verknüpfen von ConfigMaps und Pods
Eine ConfigMap macht nichts alleine. Sie haben Ihrem Cluster einige Daten hinzugefügt. Jetzt verknüpfen wir es mit einem Pod:
apiVersion: v1 Art: Pod-Metadaten: Name: example-pod spec: container: – name: example-container image: example-image:latest envFrom: – configMapRef : name: example-configmap
Das Feld envFrom ruft Umgebungsvariablen ab, die von einer anderen referenzierten Ressource definiert wurden. In diesem Fall identifiziert eine configMapRef die zuvor erstellte ConfigMap. Die Container des Pods werden mit den definierten Umgebungsvariablen database_host und system_email gestartet.
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 einen regulären env-Abschnitt, definieren Sie einzelne 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 dem database_host-Schlüssel aus der ConfigMap gestartet werden kann. Der Schlüssel wird auch vor der Injektion umbenannt, sodass der Pod ihn als DATABASE_HOST_IP empfängt.
Verwenden von ConfigMaps mit Volumes
ConfigMaps können als . gemountet werden Dateien in Pods. Kubernetes erstellt ein Volume, fügt den Inhalt der ConfigMap als eine Reihe von Dateien ein und mountet das Volume in Ihrem Pod.
apiVersion: v1 Art: Pod-Metadaten: Name: Beispiel-Pod-Spezifikation: Container: – Name: Beispiel-Container-Image: Beispiel-Image: Neueste VolumeMounts: – Name: App-Config mountPath: "/etc/config-data" readOnly: true volume: – name: app-config configMap: name: example-configmap Werbung
Dieses Pod-Manifest erstellt ein Volume namens app-config. Das configMap-Feld füllt das Volume vorab mit den Daten in der angegebenen ConfigMap.
Der Pod mountet das Volume in /etc/config-data. Ihre Container können die Dateien im Verzeichnis lesen, um auf Ihre Konfigurationswerte zuzugreifen. Jeder ConfigMap-Schlüssel hat seine eigene Datei innerhalb des Mount-Punkts.
Aktualisieren von ConfigMap-Werten
Da eine ConfigMap eine standardmäßige Kubernetes-API-Ressource ist, Sie können Werte jederzeit aktualisieren, indem Sie Ihr Manifest ändern und es erneut auf Ihren Cluster anwenden. Wie die neuen Werte Ihre Pods erreichen, hängt vom verwendeten Injektionsmechanismus ab.
Mounted Volumes
ConfigMaps, die über ein Volume in Pods eingebunden sind, 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 vorhandene Pods, die über diesen Mechanismus auf Schlüssel verweisen, nicht erreichen. 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.
Immutable ConfigMaps
ConfigMaps haben ein optionales unveränderliches Feld, das verhindert, dass sie aktualisiert werden. Wenn dieses Feld festgelegt ist, können Sie die Daten der ConfigMap nicht aktualisieren oder den unveränderlichen Status entfernen.
apiVersion: v1 Art: ConfigMap-Metadaten: Name: immutable-configmap data: foo: bar immutable: true Advertisement
Dies kann nützlich sein, wenn Sie sicher sind, dass sich die Konfigurationswerte nie ändern. Es verbessert die Sicherheit, indem es die Möglichkeit versehentlicher Bearbeitungen beseitigt. Die Leistung kann auch verbessert werden, da Kubernetes die ConfigMap nicht mehr überwachen muss, um Wertänderungen in Ihre Pods zu übertragen.
Zusammenfassung
ConfigMaps sollten Ihre erste Wahl sein für die Bereitstellung nicht sensibler Konfigurationsschlüssel für Ihre Kubernetes-Pods. Sie sind eine erstklassige API-Ressource, die Sie als Umgebungsvariablen oder gemountete Dateien in Volumes verwenden können.
Passwörter und andere Anmeldeinformationen gehören zu Secrets. Diese funktionieren sehr ähnlich wie ConfigMaps und werden von Pods auf die gleiche Weise referenziert. Ersetzen Sie configMapRef durch secretRef, um einen Schlüssel aus einem benannten Secret anstelle einer ConfigMap zu ziehen.