Inhaltsverzeichnis
Methode 1: Verwenden Sie ConfigMap-Reload Sidecar
Methode 2: Verwenden Sie CI-Skripte, um das ConfigMap-Hot-Update zu implementieren
Methode 3: Verwenden Sie Controller, um das ConfigMap-Hot-Update zu implementieren
Hintergrund
ConfigMap ist ein Ressourcentyp, der zum Speichern von Konfigurationsinformationen in Kubernetes verwendet wird. In Kubernetes-Clustern wird ConfigMap häufig zum Speichern von Anwendungskonfigurationsinformationen verwendet. Zu diesen Konfigurationsinformationen können Umgebungsvariablen, Konfigurationsdateien, Befehlszeilenparameter usw. gehören. Wenn während der Ausführung der Anwendung die Konfigurationsinformationen aktualisiert werden müssen, muss die Anwendung neu gestartet werden. In einer Produktionsumgebung kann ein Neustart der Anwendung jedoch gewisse Auswirkungen haben. Daher müssen einige Methoden angewendet werden, um eine Hot-Aktualisierung von ConfigMap zu erreichen. In diesem Artikel werden drei Methoden zur Implementierung des ConfigMap-Hot-Updates vorgestellt und die Vor- und Nachteile dieser Methoden analysiert.
Methode 1: Verwenden Sie ConfigMap-Reload Sidecar
ConfigMap-Reload Sidecar ist eine sehr beliebte ConfigMap-Hot-Update-Methode. Die Grundidee dieser Methode besteht darin, im Pod der Anwendung einen Sidecar-Container zu starten, der die Änderungen der ConfigMap überwachen kann. Wenn sich die ConfigMap ändert, lädt der Sidecar-Container die Konfigurationsinformationen der Anwendung neu und benachrichtigt die Anwendung, die Konfigurationsinformationen über eine HTTP-Anfrage erneut zu lesen.
Der Vorteil von ConfigMap-Reload Sidecar besteht darin, dass es einfach zu implementieren ist und schnell in Form eines Spiegels bereitgestellt werden kann. Da der Sidecar-Container und der Anwendungscontainer außerdem im selben Pod ausgeführt werden, können sie sich dasselbe Netzwerk und Speichervolumen teilen, sodass die Datenübertragungsgeschwindigkeit hoch ist und synchrone Aktualisierungen einfach implementiert werden können.
Allerdings hat ConfigMap-Reload Sidecar auch einige Nachteile. Wenn sich eine Umgebungsvariable in der ConfigMap ändert, muss die Anwendung zunächst noch neu gestartet werden, damit sie wirksam wird. Zweitens sind ihre Lebenszyklen ebenfalls konsistent, da der Sidecar-Container und der Anwendungscontainer im selben Pod ausgeführt werden, was zu unnötigen Neustarts führen kann.
Wenn Sie die erste Methode verwenden, können Sie das configmap-reload-Image von Prometheus verwenden. Hier ist eine Beispiel-YAML-Datei:
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
spec:
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: myapp
image: myapp
env:
- name: MY_APP_CONFIG
valueFrom:
configMapKeyRef:
name: myapp-config
key: config.yaml
- name: config-reloader
image: prometheus-community/configmap-reload:v0.5.0
args:
- --webhook-url=http://localhost:5000/-/reload
- --volume-dir=/etc/config
- --watched-dir=/etc/config
volumeMounts:
- name: config-volume
mountPath: /etc/config
volumes:
- name: config-volume
configMap:
name: myapp-config
In dieser Yaml-Datei verwenden wir zwei Container: einer ist unsere Anwendung und der andere ist der Sidecar von configmap-reload. Wir mounten die Konfigurationsdateien in der ConfigMap in den Umgebungsvariablen des Anwendungscontainers und mounten die ConfigMap im Config-Reloader-Container. Im Config-Reloader-Container haben wir das überwachte Verzeichnis und das Volume-Verzeichnis der ConfigMap angegeben und die Webhook-URL als localhost:5000/-/reload angegeben. Wenn sich die ConfigMap ändert, sendet Config-Reloader eine HTTP-POST-Anfrage , was ein erneutes Lesen der Anwendung auslöst.
Methode 2: Verwenden Sie CI-Skripte, um das ConfigMap-Hot-Update zu implementieren
Die zweite Methode besteht darin, CI-Skripte zu verwenden, um das ConfigMap-Hot-Update zu implementieren. Die Grundidee dieser Methode besteht darin, den MD5-Wert der Datei in der ConfigMap zu berechnen, wenn sich die ConfigMap ändert, und ihn in die Annotation oder das Label der Bereitstellung zu schreiben. Auf diese Weise aktualisiert Kubernetes den Pod bei der nächsten Bereitstellung automatisch fortlaufend und erreicht so ein Hot-Update.
Der Vorteil dieses Ansatzes besteht darin, dass er einfach zu implementieren ist und automatisch über den CI/CD-Prozess bereitgestellt werden kann. Da Kubernetes außerdem Pods automatisch rollt und aktualisiert, sind keine manuellen Vorgänge erforderlich, wodurch menschliche Fehler reduziert werden.
Allerdings hat diese Methode auch einige Nachteile. Zunächst müssen CI-Skripte geschrieben werden, die Konfiguration ist komplex und es sind gewisse Programmierkenntnisse erforderlich. Zweitens ist diese Methode nur auf die ConfigMap des Dateityps anwendbar. Wenn die Konfigurationsinformationen in der ConfigMap eine Umgebungsvariable oder ein Befehlszeilenparameter sind, muss die Anwendung noch neu gestartet werden, damit sie wirksam wird.
Beim zweiten Ansatz müssen wir ein CI-Skript schreiben, um die Anmerkungen oder Beschriftungen des Pods automatisch zu aktualisieren. Hier ist ein Beispielskript:
#!/bin/bash
set -e
configmap_name=myapp-config
deployment_name=myapp
namespace=default
# Get current deployment image tag
current_image_tag=$(kubectl get deployment $deployment_name -n $namespace -o jsonpath='{.spec.template.spec.containers[0].image}' | cut -d: -f2)
# Get current configmap md5
configmap_md5=$(kubectl get configmap $configmap_name -n $namespace -o jsonpath='{.data.config\.yaml}' | md5sum | cut -d' ' -f1)
# Update deployment image tag and configmap md5 as annotations
kubectl patch deployment $deployment_name -n $namespace -p "{\"spec\":{\"template\":{\"metadata\":{\"annotations\":{\"configmap-md5\":\"$configmap_md5\"}}},\"spec\":{\"containers\":[{\"name\":\"myapp\",\"image\":\"myapp:$configmap_md5\"}]}}}"
Das Skript ruft das von der aktuellen Bereitstellung verwendete Image-Tag und den MD5-Wert der ConfigMap ab und verwendet dann den Befehl kubectl patch, um den Kommentar und das Container-Image-Tag der Bereitstellung zu aktualisieren. Wenn sich die ConfigMap ändert, kann die Ausführung dieses Skripts das Image-Tag der Bereitstellung und den MD5-Wert der ConfigMap automatisch aktualisieren.
Methode 3: Verwenden Sie Controller, um das ConfigMap-Hot-Update zu implementieren
Die dritte Methode besteht darin, den Controller zum Implementieren des ConfigMap-Hot-Updates zu verwenden.
Die Grundidee dieser Methode besteht darin, einen Controller zu schreiben, der eine automatische Aktualisierung durch Abhören des Änderungsereignisses von ConfigMap realisiert. Wenn sich die ConfigMap ändert, aktualisiert der Controller die Anmerkung oder Beschriftung des entsprechenden Pods und löst die Aktualisierung des Pods aus.
Ähnlich wie bei Methode 2 besteht der Vorteil der Verwendung von Controller zur Implementierung des ConfigMap-Hot-Updates darin, dass es einen hohen Automatisierungsgrad aufweist, keine manuelle Bedienung erfordert und menschliche Fehler reduzieren kann. Gleichzeitig ist diese Methode im Vergleich zu Methode 1 und Methode 2 flexibler und kann verschiedene Arten von ConfigMaps unterstützen, einschließlich Umgebungsvariablen, Befehlszeilenparametern, Dateien usw. Darüber hinaus kann der Controller auch an verschiedene Geschäftsszenarien angepasst werden, um die Flexibilität zu verbessern.
Allerdings gibt es auch einige Nachteile bei der Verwendung von Controller zur Implementierung des ConfigMap-Hot-Updates. Erstens ist die Implementierungskomplexität dieser Methode im Vergleich zu Methode 1 und Methode 2 höher und der Code des Controllers muss geschrieben werden, was eine gewisse Entwicklungserfahrung erfordert. Zweitens kann dies die Belastung des Clusters erhöhen und die Stabilität des Clusters beeinträchtigen, da der Controller auf ConfigMap-Änderungsereignisse hören und die entsprechenden Pods aktualisieren muss.
abschließend
Die oben genannten drei Methoden können das Hot-Update von ConfigMap realisieren und haben unterschiedliche Vor- und Nachteile. Bei der Auswahl der zu verwendenden Methode müssen Sie Kompromisse auf der Grundlage spezifischer Geschäftsszenarien und -anforderungen eingehen. Wenn Sie einfache und schnelle Hot-Updates implementieren müssen, können Sie die Verwendung von Methode 1 in Betracht ziehen. Wenn Sie eine automatisierte Bereitstellung und fortlaufende Updates benötigen, können Sie die Verwendung von Methode 2 in Betracht ziehen. Wenn Sie mehr Flexibilität und Anpassbarkeit benötigen, können Sie die Verwendung von Methode 3 in Betracht ziehen.
In praktischen Anwendungen können wir auch einige Open-Source-Projekte verwenden, um das Hot-Update von ConfigMap zu realisieren. Reloader ist beispielsweise ein relativ beliebtes Open-Source-Projekt, das das Änderungsereignis von ConfigMap automatisch überwachen und die Aktualisierung des entsprechenden Pods auslösen kann. ConfigmapController und k8s-trigger-controller sind ebenfalls einige optionale Open-Source-Projekte, die je nach Bedarf ausgewählt und verwendet werden können.
Kurz gesagt, die Implementierung des Hot-Updates von ConfigMap ist eine sehr wichtige Funktion in Kubernetes. Durch den Einsatz geeigneter Methoden und Tools können die Verfügbarkeit und Stabilität von Anwendungen verbessert werden, um den Anforderungen verschiedener Geschäftsszenarien gerecht zu werden.