PostgreSQL mit Helm in Kubernetes betreiben
Im vorherigen Artikel PostgreSQL in Kubernetes und OpenShift wurden die Grundlagen zum Betrieb von PostgreSQL in Containern und Kubernetes vorgestellt.
Für eine einzelne Umgebung funktioniert das Verfahren soweit ganz gut.
Wenn jedoch verschiedene Varianten, z.B. für mehrere Umgebungen, bereitgestellt werden sollen, steigt der Aufwand und auch das Risiko von Configuration Drift.
Helm tritt an, um dabei Abhilfe zu schaffen.
Bei Helm handelt es sich um einen Package-Manager für Kubernetes. Von https://helm.sh/ kann Helm bezogen und installiert werden.
Für verschiedene Anwendungen werden Helm Charts angeboten, die die zu verwaltenden Objekte in Kubernetes (Deployments, Services etc.) und zugehörigen Konfigurationsparameter beschreiben.
Helm Charts werden in Repositories bereitgestellt.
Darüber können auch eigene Helm Charts publiziert werden.
Für PostgreSQL gibt es z.B. von Bitnami vorbereitete Container Images und Helm Charts, die über charts.bitnami.com/bitnami bezogen werden können.
Das Repository wird mit helm repo add angelegt.
$ helm repo add bitnami https://charts.bitnami.com/bitnamiSo hinzugefügte Repositories können nach Stichworten durchsucht werden. Alternativ gibt es den Hub unter https://artifacthub.io/ (ehemals https://hub.helm.sh/ ), in dem u.a. auch Helm Charts abgelegt sind.
$ helm search repo postgresql
NAME CHART VERSION APP VERSION DESCRIPTION
bitnami/postgresql 10.16.2 11.14.0 Chart for PostgreSQL, an object-relational data...
bitnami/postgresql-ha 8.2.8 11.14.0 This PostgreSQL cluster solution includes the P...Wenn ein passender Chart, hier für PostgreSQL, gefunden wurde, kann die Installation beginnen.
Die Anpassung an eine Umgebung erfolgt durch Setzen von Variablen, mit denen der Helm Chart konfiguriert wird.
Dabei hängen die zur Verfügung stehenden Variablen und Werte zum einen vom jeweiligen Chart und zum anderen von der bereitzustellenden Anwendung bzw. den verwendeten Container Images ab.
Bei dem Bitnami PostgreSQL Image existiert z.B. das Flag volumePermissions.enabled.
Wird es aktiviert, so wird ein initContainer erzeugt, mit dem die Berechtigungen des verwendeten Volumes angepasst werden.
Da der Init-Container als root läuft, ist das Verhalten standardmäßig deaktiviert.
$ helm install pg bitnami/postgresql \ --set volumePermissions.enabled=true
Ein Upgrade von Helm Charts und damit verbundenen Anwendungen ist ebenfalls sehr leicht möglich:
Nachdem mit helm repo update die Chart Metadaten aktualisiert werden, kann durch helm upgrade eine Aktualisierung vorgenommen werden.
Das funktioniert am besten mit zustandslosen Anwendungen.
Gerade PostgreSQL ist das nicht, und das Bitnami Image hat kein automatisches Konzept, um eine Migration der Datenbankdaten auf eine neuere PostgreSQL Version vorzunehmen.
Die Umsetzung davon könnte theoretisch mit Helm Hooks erfolgen oder auch Init-Containern.
Fazit
Helm bringt viele Features mit, die den Lebenszyklus typischer Anewndungen in Kubernetes unterstützen. Am Beispiel PostgreSQL sieht man die Vorteile, aber auch die Einschränkungen von Helm: Eine zustandsbehaftete Anwendung, wie PostgreSQL, benötigt eine gewisse Betreuung wenn es um einen langfristigen, kontinuierlichen Betrieb geht.
Lassen sich regelmäßige Datensicherungen und Wartungsaufgaben wie VACUUM noch gut durch Kubernetes Jobs umsetzen, wird die Verwaltung von PostgreSQL HA Clustern und kontrollierte Versionsupgrades schon kniffliger.
Für solche speziellen Fälle lohnt der Griff zu einem Kubernetes Operator.
Und der kann dann wiederum durch Helm verwaltet werden.
Zu den Themen Kubernetes, Docker und Cloudarchitektur bieten wir sowohl Beratung, Entwicklungsunterstützung als auch passende Schulungen an:
Auch für Ihren individuellen Bedarf können wir Workshops und Schulungen anbieten. Sprechen Sie uns gerne an.