Betrieb in Kubernetes¶

Für einen einzelnen Server ist Docker Compose der einfachere Weg. Kubernetes lohnt sich, wenn Sie ohnehin einen Cluster betreiben, mehrere Instanzen der Anwendung brauchen oder Datenbank und Cache als verwaltete Dienste nutzen wollen.

Voraussetzungen¶

• Kubernetes 1.27 oder neuer, kubectl mit Zugriff auf den Cluster
• Eine Speicherklasse (kubectl get storageclass)
• Für den Zugriff aus dem Internet ein Ingress-Controller und cert-manager. Den Ingress-Controller erkennt der Installer (auf k3s das mitgelieferte Traefik, sonst die Standardklasse des Clusters; --ingress-class gibt sie vor), er installiert aber selbst keinen. cert-manager bietet er an, falls er fehlt.
• Helm 3, wird bei Bedarf nachinstalliert

Bedarf: etwa 4 GB Arbeitsspeicher mit Volltextsuche, rund 2 GB ohne.

Installation¶

git clone https://github.com/mandariOSS/mandari.git
cd mandari
./install-k8s.sh

./install-k8s.sh --unattended \
  --domain ris.meine-kommune.de \
  --namespace mandari \
  --tag latest

helm upgrade --install mandari deploy/kubernetes/helm/mandari \
  --namespace mandari --create-namespace \
  --set domain=ris.meine-kommune.de \
  --set adminUser.email=admin@meine-kommune.de \
  --set adminUser.password='EinLangesPasswort' \
  --wait --wait-for-jobs

kubectl create namespace mandari
# In deploy/kubernetes/manifests/mandari.yaml alle Werte "BITTE-ERSETZEN-*" und die
# Domain anpassen (Werte unter data: sind Base64-kodiert), dann:
kubectl kustomize deploy/kubernetes/manifests | kubectl apply -f -
kubectl -n mandari apply -f deploy/kubernetes/manifests/job-migrate.yaml

Migrationen¶

Wie update.sh bei Docker Compose läuft die Migration in zwei Schritten:

Anwendung, Worker und Ingestor warten in einem Init-Container (wait-for-schema), bis alle Migrationen eingespielt sind, die vor dem Ausrollen laufen dürfen. So startet nichts gegen ein zu altes Schema, auch nicht bei der Erstinstallation mit --wait.

Worker¶

Wie in Docker Compose laufen Ereignisse, Aufträge und alle Zeitpläne in eigenen Deployments aus dem Anwendungs-Image, mit derselben Umgebung wie die Anwendung:

Ist ein eigener Worker abgeschaltet, bedient der Hauptworker dessen Warteschlangen mit. values-minimal.yaml arbeitet so mit einem einzigen Worker. Start- und Liveness-Probe fragen /health auf Port 9091 ab; hängt eine Rolle länger als fünf Minuten, startet Kubernetes den Pod neu. Mehrere Repliken teilen sich die Arbeit ohne Doppelläufe.

Den Protokoll-Orchestrator für GPU-Rechenknoten (minutes-orchestrator in Docker Compose) bringt das Chart nicht mit.

Nach der Installation¶

Die Domain muss auf den Ingress-Controller zeigen:

kubectl -n mandari get ingress mandari

Zugangsdaten sichern. Beim ersten Installieren erzeugt das Chart Schlüssel und Passwörter; bei Upgrades bleiben sie erhalten.

kubectl -n mandari get secret mandari-secrets -o yaml > mandari-secrets-backup.yaml

Wichtige Werte¶

Vollständige Liste im Chart unter deploy/kubernetes/helm/mandari/values.yaml, Beschreibung in deploy/kubernetes/README.md. Vorlagen für kleine und große Installationen liegen als values-minimal.yaml und values-production.yaml daneben.

Ereignistechnik einschalten: erst events.producers (Ereignisse zum RIS-Bestand), danach events.changesFeed (Änderungsfeed und Snapshot). Beides erst, wenn der Worker läuft (kubectl -n mandari get pods -l app.kubernetes.io/component=worker).

Aktualisieren¶

Die Migrationen laufen vor und nach dem Ausrollen von selbst (siehe Migrationen):

helm upgrade mandari deploy/kubernetes/helm/mandari -n mandari \
  --reset-then-reuse-values --set image.tag=v0.11.0 --wait --wait-for-jobs

--reset-then-reuse-values (Helm 3.14 oder neuer) übernimmt neue Standardwerte des Charts und behält Ihre eigenen Werte.

Skalieren¶

Mehr Repliken der Anwendung brauchen eine Speicherklasse mit ReadWriteMany (zum Beispiel NFS, CephFS, Longhorn). Der Ingestor bleibt bei einer Instanz, damit Quellen nicht doppelt abgefragt werden. Die Worker binden media und files ein wie die Anwendung: Mit ReadWriteOnce (Standard) müssen auf einem Cluster mit mehreren Knoten Anwendung, Ingestor und Worker auf demselben Knoten laufen, sonst bleibt ein Pod mit „Multi-Attach“ hängen. Dafür worker.affinity und app.affinity auf denselben Knoten legen oder ReadWriteMany verwenden.

Sichern¶

# Datenbank
kubectl -n mandari exec statefulset/mandari-postgres -- \
  pg_dump -U mandari mandari | gzip > mandari-$(date +%F).sql.gz

# Dateien: die Volumes mandari-media und mandari-files in die Sicherung des
# Clusters aufnehmen (z. B. Velero) oder aus einem Pod kopieren
kubectl -n mandari cp mandari-<pod>:/app/media ./media-backup

Dazu gehört die Sicherung des Secrets (siehe oben). Siehe auch Updates und Backups.

Fehlersuche¶

Logs der Dienste:

kubectl -n mandari logs -f deploy/mandari
kubectl -n mandari logs -f deploy/mandari-ingestor
kubectl -n mandari logs -f deploy/mandari-worker
kubectl -n mandari logs -f deploy/mandari-worker-heavy
kubectl -n mandari logs -f deploy/mandari-worker-live

Ohne Ingress erreichen Sie die Installation direkt:

kubectl -n mandari port-forward svc/mandari 8080:80

Deinstallieren¶

./install-k8s.sh --uninstall --namespace mandari

Daten und Zugangsdaten bleiben absichtlich erhalten. Vollständig entfernen, nicht umkehrbar:

kubectl delete namespace mandari