Upgrades & Migration

Upgrade des Operators

Der Operator wird auf dieselbe Weise upgegradet, wie er installiert wurde:

Helm

helm upgrade navique-ai-core-operator \
  oci://ghcr.io/scigility/charts/navique-ai-core-operator \
  --namespace navique-system

kustomize

make deploy IMG=ghcr.io/scigility/navique-ai-core-operator:<new-tag>

OLM

# Managed by the Operator Lifecycle Manager's upgrade channel.

Beim Start reconciled der neue Operator alle vorhandenen Resources. Capability-Operator-Releases, die er besitzt, werden auf die mit dem neuen Operator-Build gebündelten Versionen upgegradet; adoptierte Releases bleiben unberührt. Da jeder Apply idempotent ist und das Reconcile-Modell readiness-gated ist, ist ein Upgrade zerstörungsfrei — Workloads laufen weiter, während der Operator konvergiert.

Prüfen Sie immer die Release Notes auf CRD-Schema-Änderungen. Das Anwenden aktualisierter CRDs (make install oder das Helm-/OLM-Upgrade) ist innerhalb von v1alpha1 additiv.

Ändern von Modus oder Typ einer Resource

Datenspeicher-Resources unterstützen das Ändern von mode (managed ↔ adopt ↔ external) und type. Wenn Sie dies tun, führt der Operator eine Migrations-Garbage-Collection durch: er vergleicht den alten mit dem neuen Status und entfernt nur die nun verwaisten operator-owned Resources, gibt dann jeden nicht mehr benötigten Capability-Operator frei. Adopted- und External-Resources werden niemals angefasst. Siehe Provenance & Lebenszyklus.

Beispielsweise das Umschalten eines PostgresCluster von managed auf external:

1. Der Operator verdrahtet den angegebenen externen connectionSecretRef.
2. Er löscht das CNPG-Cluster, das er erstellt hatte.
3. Falls kein anderer Konsument CloudNativePG benötigt, deinstalliert er den Operator (nur weil der Operator ihn besitzt).

Die Datenmigration liegt in Ihrer Verantwortung

Das Umschalten des Modus eines Datenspeichers ändert, wo die Daten liegen, nicht die Daten selbst. Der Operator kopiert keine Daten zwischen einem managed Cluster und einem externen Host — migrieren Sie die Daten (Dump/Restore, Replikation) vor oder nach dem Umschalten, je nach Bedarf.

Migration vom Helm- + ArgoCD-Deployment

Der Operator ersetzt die bisherige Helm- + ArgoCD-Auslieferung der Plattform. Der Migrationspfad:

1. Operator bereitstellen neben dem bestehenden Deployment.
2. Übernehmen, nicht bekämpfen. Richten Sie Datenspeicher-Resources mit mode: adopt auf die bestehenden clusterinternen Datenspeicher aus oder mit mode: external auf externe Hosts, sodass der Operator nicht versucht, neu zu erstellen, was bereits läuft. Adoptieren Sie alle Capability-Operatoren, die Sie bereits installiert haben — der Operator erkennt sie und koexistiert mit ihnen.
3. Rotieren Sie die zuvor committeten Secrets. Die alten Charts haben Live-Secrets nach git committet; rotieren Sie sie in Ihrem Vault und beziehen Sie sie über SecretsManagement. Siehe Secrets-Verwaltung.
4. Workloads umstellen, indem Sie Gateway-, Observability- und ChatUI-Resources erstellen, die die adoptierten Datenspeicher referenzieren.
5. ArgoCD außer Betrieb nehmen für die Plattform, sobald der Operator die Workloads besitzt.

Da der Operator provenance-aware ist, können Sie inkrementell migrieren, ohne dass er Resources überschreibt, die Sie noch von Hand verwalten.

Gebündelte Chart-Versionen

Jeder Operator-Build pinnt bestimmte Upstream-Chart-Versionen (siehe Gebündelte Charts). Das Upgrade des Operators ist der Weg, um für die operatoreigenen Releases auf neuere gebündelte Charts zu wechseln. Versionssprünge werden upstream von Renovate/Dependabot getrieben, die die Quell-Chart-Repositories beobachten.