Aggiornamenti e migrazione

Aggiornare l'operatore

L'operatore si aggiorna nello stesso modo in cui è stato installato:

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.

All'avvio, il nuovo operatore esegue il reconcile di tutte le risorse esistenti. Le release degli operatori di capacità che possiede vengono aggiornate alle versioni incluse nella nuova build dell'operatore; le release adottate restano invariate. Poiché ogni apply è idempotente e il modello di reconcile è vincolato alla prontezza, un aggiornamento non è distruttivo — i workload continuano a funzionare mentre l'operatore converge.

Consulta sempre le note di rilascio per eventuali modifiche allo schema dei CRD. L'applicazione dei CRD aggiornati (make install o l'aggiornamento Helm/OLM) è additiva all'interno di v1alpha1.

Cambiare mode o type di una risorsa

Le risorse datastore supportano la modifica di mode (managed ↔ adopt ↔ external) e di type. Quando la effettui, l'operatore esegue una garbage collection di migrazione: confronta il vecchio e il nuovo status e rimuove solo le risorse possedute dall'operatore rimaste orfane, quindi rilascia qualsiasi operatore di capacità non più necessario. Le risorse adottate ed esterne non vengono mai toccate. Vedi Provenienza e ciclo di vita.

Per esempio, passando un PostgresCluster da managed a external:

1. L'operatore collega il connectionSecretRef esterno fornito.
2. Elimina il Cluster CNPG che aveva creato.
3. Se nessun altro consumatore ha bisogno di CloudNativePG, disinstalla l'operatore (solo perché l'operatore lo possiede).

La migrazione dei dati è una tua responsabilità

Cambiare la modalità di un datastore cambia dove risiedono i dati, non i dati stessi. L'operatore non copia i dati tra un cluster gestito e un host esterno — migra i dati (dump/restore, replica) prima o dopo il cambio, a seconda dei casi.

Migrare dal deployment Helm + ArgoCD

L'operatore sostituisce la precedente distribuzione della piattaforma tramite Helm + ArgoCD. Il percorso di migrazione:

1. Avvia l'operatore accanto al deployment esistente.
2. Adotta, non combattere. Punta le risorse datastore ai datastore esistenti nel cluster con mode: adopt, oppure a host esterni con mode: external, così che l'operatore non tenti di ricreare ciò che è già in esecuzione. Adotta gli operatori di capacità che hai già installato — l'operatore li rileva e coesiste con essi.
3. Ruota i secret precedentemente committati. I vecchi chart committavano secret reali in git; ruotali nel tuo vault e ricavali tramite SecretsManagement. Vedi Gestione dei secret.
4. Effettua il passaggio dei workload creando risorse Gateway, Observability e ChatUI che fanno riferimento ai datastore adottati.
5. Dismetti ArgoCD per la piattaforma una volta che l'operatore possiede i workload.

Poiché l'operatore è consapevole della provenienza, puoi migrare in modo incrementale senza che sovrascriva le risorse che gestisci ancora a mano.

Versioni dei chart inclusi

Ogni build dell'operatore fissa versioni specifiche dei chart upstream (vedi Chart inclusi). Aggiornare l'operatore è il modo per passare a chart inclusi più recenti per le release possedute dall'operatore. Gli aggiornamenti di versione sono guidati a monte da Renovate/Dependabot, che monitorano i repository dei chart di origine.