Mise à niveau d'un cluster Milvus avec Milvus Operator
Ce guide décrit comment mettre à niveau un cluster Milvus 2.6.x vers la version 3.0.3 à l'aide de Milvus Operator.
Cette procédure a été validée pour une mise à niveau de Milvus 2.6.20 vers Milvus v3.0.3 avec Milvus Operator 1.3.0, MixCoord, StreamingNode, Woodpecker, etcd au sein du cluster et MinIO au sein du cluster. Si vous utilisez une autre version de patch Milvus 2.6.x, une autre version d’Operator, une topologie de composants différente, une file d’attente de messages différente ou une configuration de dépendances différente, validez d’abord la mise à niveau dans un environnement hors production.
Prérequis
- Un cluster Kubernetes comprenant un cluster Milvus 2.6.x géré par Milvus Operator
kubectlAccès au cluster- Le manifeste complet de la ressource personnalisée (CR) Milvus utilisé pour le déploiement existant
- La méthode d’installation et les manifests utilisés pour l’Operator Milvus existant
- Une sauvegarde récente des métadonnées et des données persistantes de Milvus
Limitations relatives aux files d’attente de messages: lors de la mise à niveau vers Milvus v3.0.3, vous devez conserver votre choix actuel de file d’attente de messages. Le passage d’un système de file d’attente de messages à un autre pendant la mise à niveau n’est pas pris en charge. La prise en charge du changement de système de file d’attente de messages sera disponible dans les versions futures.
Appliquez la CR Milvus complète pour cette mise à niveau. N’utilisez pas de patch de fusion contenant uniquement une image. L’Operator peut remplacer par défaut les champs de composants omis sans réplique, ce qui peut réactiver un composant que le déploiement 2.6.x existant avait désactivé.
Cette procédure ne valide pas une rétrogradation ou une annulation de la mise à jour consistant à ramener l’image Milvus à la version 2.6.x. Une fois que la version 3.0.3 a écrit des données, une annulation portant uniquement sur l’image peut ne pas parvenir à lire l’état mis à jour. Si la mise à niveau échoue, arrêtez les écritures et utilisez un plan de reprise qui restaure les métadonnées antérieures à la mise à niveau ainsi que les sauvegardes des données persistantes. Validez d’abord le plan de reprise dans un environnement hors production.
Processus de mise à niveau
Étape 1 : Sauvegardez le CR Milvus actuel
Enregistrez le CR actuel avant de modifier le déploiement :
kubectl get milvus <instance-name> \
--namespace <namespace> \
--output yaml > milvus-before-upgrade.yaml
Utilisez le manifeste source de votre déploiement existant comme manifeste de mise à niveau. N’appliquez pas directement le fichier de sauvegarde exporté sans avoir préalablement supprimé les métadonnées gérées par le serveur et les champs d’état.
Étape 2 : Vérifier la version de Milvus Operator
Vérifiez l’image utilisée par Milvus Operator installé :
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
La mise à niveau validée a conservé Milvus Operator à la version 1.3.0. Conservez la version de l’Operator qui gère actuellement votre déploiement Milvus 2.6.x, sauf si votre politique de support exige une mise à niveau distincte de l’Operator. Ne revenez pas à une version antérieure d’un Operator plus récent vers la version testée. Si vous devez modifier la version de l’Operator, utilisez la même méthode d’installation (Helm ou kubectl ) ainsi que le même nom de version et le même espace de noms que l’installation existante, puis validez la modification de l’Operator avant de mettre à jour le CR Milvus.
Étape 3 : Mettre à jour l’image Milvus
Dans le manifeste CR Milvus complet, remplacez ` spec.components.image ` par la version cible. Conservez le mode actuel, la topologie des composants, la file d’attente de messages, l’etcd, le stockage et les autres paramètres de dépendances. L’extrait suivant présente les champs à vérifier ; ne remplacez pas votre CR complet par cet extrait.
Avant d’appliquer la CR cible, vérifiez que indexNode.replicas correspond bien à 0. La configuration validée de Milvus 2.6.20 utilisait déjà ce paramètre. Conservez le paramètre explicite « zero-replica » dans la CR cible.
apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
name: <instance-name>
namespace: <namespace>
spec:
components:
image: milvusdb/milvus:v3.0.3
indexNode:
replicas: 0
Appliquez le manifeste CR complet :
kubectl apply --filename milvus.yaml
Vérifiez la mise à niveau
Vérifiez l’état du CR, l’état des pods et les images de conteneurs :
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}'
Vérifiez que le CR Milvus indique « Healthy », que tous les composants Milvus utilisent « milvusdb/milvus:v3.0.3 », qu’aucun pod IndexNode n’est en cours d’exécution et que les collections existantes restent consultables et recherchables. Effectuez ces vérifications avant d’activer toute fonctionnalité spécifique à la version 3.0.3.
