Aggiornamento di Milvus standalone con Milvus Operator
Questa guida descrive come aggiornare il vostro Milvus standalone con Milvus operator.
Aggiornare l'operatore Milvus
Eseguite il seguente comando per aggiornare la versione del vostro operatore Milvus alla v1.0.1.
helm repo add zilliztech-milvus-operator https://zilliztech.github.io/milvus-operator/
helm repo update zilliztech-milvus-operator
helm -n milvus-operator upgrade milvus-operator zilliztech-milvus-operator/milvus-operator
Una volta aggiornato l'operatore Milvus alla versione più recente, avete le seguenti possibilità:
- Per aggiornare Milvus dalla versione 2.2.3 o successive alla 2.4.17, è possibile eseguire un aggiornamento continuo.
- Per aggiornare Milvus da una release minore precedente alla v2.2.3 alla 2.4.17, si consiglia di aggiornare Milvus cambiando la versione dell'immagine.
- Per aggiornare Milvus dalla v2.1.x alla 2.4.17, è necessario migrare i metadati prima dell'aggiornamento effettivo.
Eseguire un aggiornamento continuo
A partire da Milvus 2.2.3, è possibile configurare i coordinatori di Milvus per lavorare in modalità active-standby e abilitare la funzione di aggiornamento continuo per loro, in modo che Milvus possa rispondere alle richieste in arrivo durante gli aggiornamenti dei coordinatori. Nelle versioni precedenti, i coordinatori dovevano essere rimossi e poi creati durante un aggiornamento, il che poteva comportare alcuni tempi di inattività del servizio.
Basandosi sulle funzionalità di aggiornamento continuo fornite da Kubernetes, il gestore di Milvus impone un aggiornamento ordinato delle distribuzioni in base alle loro dipendenze. Inoltre, Milvus implementa un meccanismo per garantire che i suoi componenti rimangano compatibili con quelli che dipendono da loro durante l'aggiornamento, riducendo in modo significativo il potenziale downtime del servizio.
La funzione di aggiornamento continuo è disabilitata per impostazione predefinita. È necessario abilitarla esplicitamente attraverso un file di configurazione.
apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
name: my-release
spec:
components:
enableRollingUpdate: true
imageUpdateMode: rollingUpgrade # Default value, can be omitted
image: milvusdb/milvus:v2.4.17
In questo file di configurazione, impostare spec.components.enableRollingUpdate
su true
e spec.components.image
sulla versione di Milvus desiderata.
Per impostazione predefinita, Milvus esegue un aggiornamento continuo dei coordinatori in modo ordinato, sostituendo le immagini dei pod dei coordinatori una dopo l'altra. Per ridurre il tempo di aggiornamento, si può impostare spec.components.imageUpdateMode
su all
, in modo che Milvus sostituisca tutte le immagini dei pod nello stesso momento.
apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
name: my-release
spec:
components:
enableRollingUpdate: true
imageUpdateMode: all
image: milvusdb/milvus:v2.4.17
Si può impostare spec.components.imageUpdateMode
su rollingDowngrade
per far sì che Milvus sostituisca le immagini dei pod coordinatori con una versione inferiore.
apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
name: my-release
spec:
components:
enableRollingUpdate: true
imageUpdateMode: rollingDowngrade
image: milvusdb/milvus:<some-older-version>
Salvare quindi la configurazione in un file YAML (ad esempio, milvusupgrade.yml
) e applicare il file di configurazione alla propria istanza Milvus come segue:
kubectl patch -f milvusupgrade.yml
Aggiornare Milvus cambiando la sua immagine
In casi normali, si può semplicemente aggiornare Milvus alla versione più recente cambiando la sua immagine. Tuttavia, si noti che l'aggiornamento di Milvus in questo modo comporta un certo tempo di inattività.
Comporre un file di configurazione come segue e salvarlo come milvusupgrade.yaml:
apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
name: my-release
labels:
app: milvus
spec:
# Omit other fields ...
components:
image: milvusdb/milvus:v2.4.17
Eseguire quindi quanto segue per eseguire l'aggiornamento:
kubectl patch -f milvusupgrade.yaml
Migrare i metadati
A partire da Milvus 2.2.0, i metadati sono incompatibili con quelli delle versioni precedenti. I seguenti esempi ipotizzano un aggiornamento da Milvus 2.1.4 a Milvus v2.4.17.
1. Creare un file .yaml
per la migrazione dei metadati
Creare un file di migrazione dei metadati. Il seguente è un esempio. È necessario specificare i file name
, sourceVersion
e targetVersion
nel file di configurazione. L'esempio seguente imposta name
su my-release-upgrade
, sourceVersion
su v2.1.4
e targetVersion
su v2.4.17
. Ciò significa che l'istanza di Milvus verrà aggiornata dalla v2.1.4 alla v2.4.17.
apiVersion: milvus.io/v1beta1
kind: MilvusUpgrade
metadata:
name: my-release-upgrade
spec:
milvus:
namespace: default
name: my-release
sourceVersion: "v2.1.4"
targetVersion: "v2.4.17"
# below are some omit default values:
# targetImage: "milvusdb/milvus:v2.4.17"
# toolImage: "milvusdb/meta-migration:v2.2.0"
# operation: upgrade
# rollbackIfFailed: true
# backupPVC: ""
# maxRetry: 3
2. Applicare la nuova configurazione
Eseguite il seguente comando per applicare la nuova configurazione.
$ kubectl create -f https://raw.githubusercontent.com/zilliztech/milvus-operator/main/config/samples/milvusupgrade.yaml
3. Controllare lo stato della migrazione dei metadati
Eseguire il seguente comando per verificare lo stato della migrazione dei metadati.
kubectl describe milvus release-name
Lo stato di ready
nell'output significa che la migrazione dei metadati è riuscita.
In alternativa, è possibile eseguire kubectl get pod
per controllare tutti i pod. Se tutti i pod sono ready
, la migrazione dei metadati è riuscita.
4. Eliminazione my-release-upgrade
Quando l'aggiornamento è riuscito, cancellare my-release-upgrade
nel file YAML.