Ich hatte bereits am Ende des letzten Blogposts angerissen, dass ich geplant hatte KubeDB zu verwenden um PostgreSQL-Instanzen im Kubernetescluster aufzusetzen. KubeDB hat bei einigen meiner Versuche sehr gut funktioniert. AppsCode hat dann allerdings die Community Edition stark beschnitten. Auch der Operator von Zalando (https://github.com/zalando/postgres-operator) hat sich für mich als ungeeignet erwiesen. Die Prozessarchitektur arm64 wird nicht unterstüzt. Ich habe mich dann entschieden keinen Operator zu verwenden und PostgreSQL per Helm-Chart zu installieren.

Abgesehen davon, dass der produktive Betrieb einer Datenbank im Kubernetescluster wohl überlegt sein sollte, empfehle ich nicht das Helm-Chart für wirklich produktive Umgebungen zu nutzen. Für den Produktivbetrieb würde ich aktuell empfehlen einen genaueren Blick auf den Zalando-Operator zu werfen. Zalando schreibt in der Dokumentation:

This project is currently in active development. It is however already used internally by Zalando in order to run Postgres clusters on K8s in larger numbers for staging environments and a growing number of production clusters.

Auf der Suche nach einem geeigneten Helm-Chart bin ich irgendwann auf das Github-Repository https://github.com/cetic/helm-postgresql gestoßen. Nachdem es für mehrere Wochen keine Reaktion auf einen von mir erstellten Pull Request gab, habe ich mich entschlossen das Repository zu forken. Das Repository des Forks ist zu finden unter https://codeberg.org/saretter/helm-postgresql.

Wie gewohnt gehe ich nun zunächst auf die manuelle Installation per Helm ein, bevor ich beschreibe, wie das Setup mit GitOps aussieht.

PostgreSQL-Installation per Helm

# Add helm-repository
helm repo add nettistanet https://nettistanet.codeberg.page/charts

# Add helm-repository
helm repo update

# Create namespace for postgresql
kubectl create namespace postgresql

# Install postgresql
helm install postgresql --namespace postgresql --name postgresql nettistanet/postgresql

GitOps / flux

Zunächst erzeugen wir in unserem Flux GitOps repository einen Ordner für PostgreSQL.

# Create directory longhorn
mkdir apps/postgresql

Danach fügen wir im kustomizations Manifest im Verzeichnis infrastructure unter resources die Zeile - ./postgresql ein.

Im apps/sources-Verzeichnis legen wir die Datei postgresql.yaml mit dem HelmRepository-Kubernetes-Manifest an. Die Datei sollte folgenden Inhalt enthalten.

apiVersion: source.toolkit.fluxcd.io/v1beta1
kind: HelmRepository
metadata:
  name: postgresql
spec:
  interval: 30m
  url: https://nettistanet.codeberg.page/charts

Nun legen wir die Dateien apps/postgresql/namespace.yaml und apps/postgresql/release.yaml an.

apiVersion: v1
kind: Namespace
metadata:
  name: postgresql

apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: postgresql
spec:
  releaseName: postgresql
  chart:
    spec:
      chart: nettistanet/postgresql
      sourceRef:
        kind: HelmRepository
        name: postgresql
        namespace: flux-system
      version: v1.2.0
  interval: 1h0m0s
  install:
    remediation:
      retries: 3
  values:

Jetzt benötigen wir noch die Datei kustomization.yaml, die namespace.yaml und release.yaml referenziert.

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: postgresql
resources:
- namespace.yaml
- release.yaml

Im nächsten Blogpost war ursprünglich geplant explizit auf Backups auf Basis von AppsCode Stash einzugegehen. Da mich die Strategie von AppsCode bei KubeDB nachträglich Features zu entfernen abgeschreckt hat, werde ich nun an dieser Stelle nicht auf Stash eingehen. In Sachen Backups möchte ich daher lediglich auf die Longhorn Dokumentation und auf die README.md (BACKUP / RESTORE) des Helm-Charts verweisen.

Der nächste Blogpost wird sich dann mit dem Thema Monitoring und Alerting auf Basis von Prometheus und Grafana beschäftigen.