Aggiornamento del cluster Milvus con Milvus Operator
Questa guida descrive come aggiornare un cluster Milvus 2.6.x alla versione 3.0.0 con Milvus Operator.
Questa procedura è stata verificata per il passaggio da Milvus 2.6.20 a Milvus v3.0.0 con Milvus Operator 1.3.0, MixCoord, StreamingNode, Woodpecker, etcd all'interno del cluster e MinIO all'interno del cluster. Se si utilizza un’altra versione patch di Milvus 2.6.x, una versione diversa di Operator, una topologia dei componenti diversa, una coda di messaggi diversa o una configurazione delle dipendenze diversa, verificare prima l’aggiornamento in un ambiente non di produzione.
Prerequisiti
- Un cluster Kubernetes con un cluster Milvus 2.6.x gestito da Milvus Operator
kubectlaccesso al cluster- Il manifesto completo della risorsa personalizzata (CR) di Milvus utilizzato per la distribuzione esistente
- Il metodo di installazione e i manifest utilizzati per l’Operatore Milvus esistente
- Un backup aggiornato dei metadati e dei dati persistenti di Milvus
Limitazioni relative alle code di messaggi: durante l'aggiornamento a Milvus v3.0.0, è necessario mantenere la scelta attuale della coda di messaggi. Il passaggio tra diversi sistemi di code di messaggi durante l'aggiornamento non è supportato. Il supporto per la modifica dei sistemi di code di messaggi sarà disponibile nelle versioni future.
Applicare la CR completa di Milvus per questo aggiornamento. Non utilizzare una patch di unione che includa solo l’immagine. L’Operator può impostare per impostazione predefinita i campi dei componenti con replica pari a zero, il che può riattivare un componente che la distribuzione 2.6.x esistente aveva disabilitato.
Questa procedura non convalida un downgrade o un rollback che riporti l’immagine di Milvus alla versione 2.6.x. Dopo che la v3.0.0 ha scritto i dati, un rollback solo dell’immagine potrebbe non riuscire a leggere lo stato aggiornato. Se l’aggiornamento fallisce, interrompere le operazioni di scrittura e utilizzare un piano di ripristino che ripristini i metadati precedenti all’aggiornamento e i backup dei dati persistenti. Verificare prima il piano di ripristino in un ambiente non di produzione.
Processo di aggiornamento
Passaggio 1: Eseguire il backup del CR Milvus corrente
Salvare il CR corrente prima di modificare la distribuzione:
kubectl get milvus <instance-name> \
--namespace <namespace> \
--output yaml > milvus-before-upgrade.yaml
Utilizzare il manifesto di origine della distribuzione esistente come manifesto di aggiornamento. Non applicare direttamente il file di backup esportato senza aver prima rimosso i metadati gestiti dal server e i campi di stato.
Passaggio 2: Verifica della versione di Milvus Operator
Verificare l'immagine utilizzata da Milvus Operator installato:
kubectl get deployments --all-namespaces \
-o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{range .spec.template.spec.containers[*]}{.image}{" "}{end}{"\n"}{end}' \
| grep milvus-operator
L'aggiornamento convalidato ha mantenuto Milvus Operator alla versione 1.3.0. Mantieni la versione di Operator che attualmente gestisce la tua distribuzione Milvus 2.6.x, a meno che la tua politica di supporto non richieda un aggiornamento separato di Operator. Non effettuare il downgrade di un Operator più recente alla versione testata. Se è necessario modificare la versione dell’Operator, utilizzare lo stesso metodo di installazione (Helm o kubectl ) e lo stesso nome di release e namespace dell’installazione esistente, quindi convalidare la modifica dell’Operator prima di aggiornare il CR di Milvus.
Passaggio 3: aggiornare l’immagine di Milvus
Nel manifesto CR completo di Milvus, modificare ` spec.components.image ` con la versione di destinazione. Mantenere la modalità corrente, la topologia dei componenti, la coda dei messaggi, etcd, lo storage e le altre impostazioni delle dipendenze. Il seguente estratto mostra i campi da confermare; non sostituire il proprio CR completo con questo estratto.
Prima di applicare il CR di destinazione, verificare che indexNode.replicas sia 0. La configurazione convalidata di Milvus 2.6.20 utilizzava già questa impostazione. Mantenere l’impostazione esplicita a zero repliche nel CR di destinazione.
apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
name: <instance-name>
namespace: <namespace>
spec:
components:
image: milvusdb/milvus:v3.0.0
indexNode:
replicas: 0
Applicare il manifesto CR completo:
kubectl apply --filename milvus.yaml
Verifica l’aggiornamento
Controllare lo stato del CR, lo stato dei pod e le immagini dei container:
kubectl get milvus <instance-name> \
--namespace <namespace> \
--output jsonpath='{.status.status}{"\t"}{.status.currentImage}{"\n"}'
kubectl get pods --namespace <namespace>
kubectl get pods --namespace <namespace> \
-o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{range .spec.containers[*]}{.image}{" "}{end}{"\n"}{end}'
Verificare che il CR di Milvus riporti Healthy, che tutti i componenti di Milvus utilizzino milvusdb/milvus:v3.0.0, che nessun Pod IndexNode sia in esecuzione e che le collezioni esistenti rimangano interrogabili e ricercabili. Completare questi controlli prima di abilitare qualsiasi funzionalità specifica della versione v3.0.0.
