Updates und Upgrades

Plattform-Updates werden als neue Helm-Chart-Versionen über das Customer Portal bereitgestellt. Manuelle Befehle auf der VM sind nicht erforderlich.

Release Channels¶

Kanal	Filter	Empfehlung
`stable`	Nur Production-Releases (exkl. -dev, -rc, -alpha, -beta)	Empfohlen für Produktion
`latest`	Alle Releases (exkl. -dev, -alpha)	Für Early Adopters
`dev`	Alle Versionen inkl. Entwicklungs-Builds	Nur für Testinstanzen

Update-Prozess¶

Customer Portal → Update-Seite öffnen
Verfügbare Updates werden angezeigt (basierend auf Release Channel)
Release Notes lesen — pro Release den Button „Release Notes anzeigen" klicken (die Release Notes werden vom Anbieter direkt mit dem Update-Paket bereitgestellt)
Update starten — das Portal führt ein helm upgrade im Hintergrund aus
Fortschritt verfolgen — Status im Portal sichtbar
Verifizierung — alle Pods müssen Status Running erreichen

Kein manuelles helm upgrade

Updates niemals über helm upgrade auf der Konsole durchführen. Das Customer Portal verwaltet den Zustand und die Konfiguration.

Release Notes im Portal

Das Customer Portal zeigt pro Release einen Button „Release Notes anzeigen". Die Release Notes werden vom Anbieter direkt mit dem Update-Paket bereitgestellt und im Portal angezeigt. Falls für ein Release keine Notes angezeigt werden, kontaktieren Sie bitte den Anbieter, bevor Sie das Update einspielen.

Vor dem Update¶

[ ] Aktuelles Backup erstellen (siehe Backup und Restore)
[ ] Release Notes im Portal lesen (Button „Release Notes anzeigen")
[ ] Wartungsfenster kommunizieren (bei Major-Updates)
[ ] Aktuelle Helm Values exportieren (Portal → Einstellungen)

Nach dem Update¶

[ ] Alle Pods Running: kubectl get pods -n inovetra-platform
[ ] Health-Checks grün: curl https://<domain>/api/customer/health
[ ] Login funktioniert
[ ] Chat funktioniert
[ ] RAG-Suche funktioniert (falls genutzt)

Beim Sprung auf 0.76.0: Connector-Full-Resync nötig

Helm Chart 0.76.0 bringt den Viewer-Button „Originalquelle öffnen" für Connector-Dokumente. Dieser benötigt die URL zum Quellsystem im Qdrant-Chunk-Payload. Bestehende Dokumente, die vor 0.76.0 ingestiert wurden, haben dieses Feld noch nicht. Nach dem Update auf 0.76.0 pro Konnektor (Confluence, SharePoint, GitHub) einmalig „Komplett neu synchronisieren" auf der Konnektor-Detailseite im Customer Portal auslösen, damit der Button auch für ältere Dokumente erscheint. Neu hinzukommende oder beim normalen Sync aktualisierte Dokumente erhalten die URL automatisch.

Beim Sprung auf 0.80.0: Confluence-PAT-Konnektoren umkonfigurieren

Helm Chart 0.80.0 bringt zwei neue On-Premise-Konnektoren (Bitbucket Data Center / Server und SMB-/Netzwerkfreigabe) und vereinfacht die Confluence-Anmeldung. Der Confluence-Konnektor authentifiziert sich jetzt ausschließlich über Benutzername + Passwort — die bisherige Personal-Access-Token-(PAT)-Variante wurde entfernt, da sie mit On-Premise-Confluence-Server-Installationen nicht zuverlässig funktionierte.

Migration (Breaking Change): Bestehende Confluence-Konnektoren, die mit einem PAT konfiguriert wurden, müssen nach dem Update einmalig im Customer Portal auf Benutzername/Passwort umgestellt werden (Konnektor öffnen → Konnektor bearbeiten → Benutzername und Passwort hinterlegen). Bis dahin schlägt die Synchronisation dieser Konnektoren fehl.

Websuche-Scaling bleibt bei Updates erhalten (ab 0.81.67)

Die on-demand-Deployments inovetra-searxng und inovetra-web-scraper (Websuche für Inovetra AI) starten im Chart mit replicas 0. Der zur Laufzeit gesetzte Replica-Count wird beim Update über ein lookup-Pattern erhalten (analog web-scraper/Embedding Service) — ein eingeschalteter Websuche-Schalter wird durch ein Update also nicht zurückgesetzt. Steuerung und Diagnose: Websuche und Runbook Websuche.

Wartungsmodus während Updates (ab 0.81.20)¶

Was Anwender während eines Updates sehen

Seit Helm Chart 0.81.20 gibt es einen Wartungsmodus: Während des Updates zeigt das Customer Portal ein blockierendes Overlay mit Phasen-Fortschritt, und LibreChat-Nutzer landen automatisch auf einer gebrandeten Wartungsseite. Niemand muss eine Seite manuell neu laden.

Ablauf aus Betreibersicht¶

Admin startet das Update auf der Update-Seite des Customer Portals.
Das Portal zeigt den Fortschritt in Phasen: Vorbereitung/Bereinigung → Helm-Upgrade → Datenbank-Migration → Rollout → Abschluss. Nach Erfolg erscheint kurz „Update abgeschlossen".
Während die Pods neu rollen, liefert der Ingress-Controller bei 502/503/504 eine gebrandete Wartungsseite (Auto-Refresh) statt roher Fehler.
Offene LibreChat-Tabs werden über ein injiziertes Watcher-Script automatisch neu geladen und sehen ebenfalls die Wartungsseite.

Reload-fester Status

Die Update-Status-Quelle ist eine Kubernetes-ConfigMap (inovetra-upgrade-status), die vom OS Manager (DaemonSet) geschrieben wird. Da das DaemonSet das Helm-Upgrade überlebt, bleibt der Fortschritt auch dann sichtbar, wenn die Customer API selbst gerade neu startet. 502/Timeouts werden im Portal als „Dienste starten neu…" dargestellt, nicht als Fehler.

Voraussetzung: NetworkPolicy `allow-maintenance`¶

Wartungsseite erscheint nicht ohne diese Policy

Unter der default-deny-NetworkPolicy ist der inovetra-maintenance-Pod nur über die NetworkPolicy allow-maintenance erreichbar (Ingress-Controller → inovetra-maintenance:8080). Diese ist Teil des Helm Charts und wird mit ingress.maintenancePage.enabled (Standard: aktiv) ausgerollt. Bei eigenen NetworkPolicy-Anpassungen darauf achten, dass diese Regel erhalten bleibt — sonst sehen Anwender während eines Updates weiterhin rohe 502/503/504.

Troubleshooting Wartungsmodus¶

Symptom	Ursache / Prüfung	Maßnahme
Overlay bleibt dauerhaft hängen	Update überschritt die Deadline → Status `stale`, oder Job `failed`	Das Portal zeigt nach Ablauf einen Fehler-Screen; Pod-Status prüfen: `kubectl get pods -n inovetra-platform`, ggf. Rollback
Anwender sehen rohe 502/503/504 statt Wartungsseite	NetworkPolicy `allow-maintenance` fehlt/blockiert, oder `inovetra-maintenance`-Pod nicht `Running`	`kubectl get pods,networkpolicy -n inovetra-platform`; Policy bzw. Pod wiederherstellen
LibreChat-Tab lädt nicht automatisch neu	Watcher-Script nicht aktiv (TLS-Sidecar bzw. `tls.enabled`)	`tls.enabled` prüfen; betroffene Nutzer einmalig manuell neu laden lassen
Status hängt, obwohl Pods schon `Running`	ConfigMap `inovetra-upgrade-status` nicht aktualisiert	`kubectl get configmap inovetra-upgrade-status -n inovetra-platform -o yaml` prüfen; OS-Manager-Logs ansehen

Rollback¶

Bei Problemen nach einem Update:

# Letzte Helm-Revision anzeigen
helm history ai-platform -n inovetra-platform

# Rollback auf vorherige Version
helm rollback ai-platform <revision> -n inovetra-platform --timeout 15m

Datenbankmigrationen bei Rollback

Ein Rollback setzt nur die Kubernetes-Ressourcen zurück. Datenbankmigrationen können nicht automatisch rückgängig gemacht werden. Bei Migrationsproblemen → Runbook Datenbank.

Major Upgrades¶

PostgreSQL Major Version: Automatisch durch OS Manager (Backup → Upgrade → Restore)
Kubernetes/K3s Upgrade: Über OS Manager via Customer Portal (Plattform → System-Update)
Helm Chart Breaking Changes: Immer Changelog beachten