Mises à niveau et migration

Mettre à niveau l'opérateur

L'opérateur est mis à niveau de la même façon qu'il a été installé :

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.

Au démarrage, le nouvel opérateur réconcilie toutes les ressources existantes. Les releases d'opérateurs de capacité qu'il possède sont mises à niveau vers les versions embarquées avec la nouvelle build de l'opérateur ; les releases adoptées sont laissées intactes. Parce que chaque apply est idempotent et que le modèle de réconciliation est conditionné par la disponibilité, une mise à niveau est non destructive — les workloads continuent de tourner pendant que l'opérateur converge.

Examinez toujours les notes de version pour les changements de schéma de CRD. L'application des CRDs mis à jour (make install ou la mise à niveau Helm/OLM) est additive au sein de v1alpha1.

Changer le mode ou le type d'une ressource

Les ressources datastore prennent en charge le changement de mode (managed ↔ adopt ↔ external) et de type. Lorsque vous le faites, l'opérateur effectue un ramasse-miettes de migration : il diffère l'ancien et le nouveau status et ne supprime que les ressources désormais orphelines possédées par l'opérateur, puis libère tout opérateur de capacité dont on n'a plus besoin. Les ressources adoptées et externes ne sont jamais touchées. Voir Provenance et cycle de vie.

Par exemple, faire passer un PostgresCluster de managed à external :

1. L'opérateur câble le connectionSecretRef externe fourni.
2. Il supprime le Cluster CNPG qu'il avait créé.
3. Si aucun autre consommateur n'a besoin de CloudNativePG, il désinstalle l'opérateur (uniquement parce que l'opérateur le possède).

La migration des données est de votre responsabilité

Changer le mode d'un datastore modifie où vivent les données, pas les données elles-mêmes. L'opérateur ne copie pas les données entre un cluster managed et un hôte externe — migrez les données (dump/restore, réplication) avant ou après le changement selon ce qui convient.

Migrer depuis le déploiement Helm + ArgoCD

L'opérateur remplace la livraison Helm + ArgoCD antérieure de la plateforme. Le chemin de migration :

1. Montez l'opérateur à côté du déploiement existant.
2. Adoptez, ne combattez pas. Pointez les ressources datastore vers les datastores in-cluster existants avec mode: adopt, ou vers des hôtes externes avec mode: external, afin que l'opérateur n'essaie pas de recréer ce qui tourne déjà. Adoptez tout opérateur de capacité que vous avez déjà installé — l'opérateur les détecte et coexiste avec eux.
3. Faites tourner les secrets précédemment commités. Les anciens charts commitaient des secrets actifs dans git ; faites-les tourner dans votre vault et sourcez-les via SecretsManagement. Voir Gestion des secrets.
4. Basculez les workloads en créant des ressources Gateway, Observability et ChatUI qui référencent les datastores adoptés.
5. Mettez ArgoCD hors service pour la plateforme une fois que l'opérateur possède les workloads.

Parce que l'opérateur est sensible à la Provenance, vous pouvez migrer de façon incrémentale sans qu'il n'écrase les ressources que vous gérez encore à la main.

Versions des charts embarqués

Chaque build d'opérateur épingle des versions spécifiques de charts amont (voir Charts embarqués). Mettre à niveau l'opérateur est la façon dont vous passez à des charts embarqués plus récents pour les releases que l'opérateur possède. Les montées de version sont pilotées en amont par Renovate/Dependabot surveillant les dépôts de charts sources.