Mise à niveau du cluster Milvus avec Milvus Operator

Ce guide décrit comment mettre à niveau votre cluster Milvus avec Milvus Operator.

Mise à niveau de l'opérateur Milvus

Exécutez la commande suivante pour mettre à niveau la version de votre Milvus Operator vers 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

Une fois que vous avez mis à niveau votre opérateur Milvus vers la dernière version, vous avez le choix entre les options suivantes :

• Pour mettre à niveau Milvus à partir de la version 2.2.3 ou de versions ultérieures vers la version 2.4.18, vous pouvez effectuer une mise à niveau continue.
• Pour mettre à niveau Milvus à partir d'une version mineure antérieure à la v2.2.3 vers la version 2.4.18, il est conseillé de mettre à niveau Milvus en modifiant la version de son image.
• Pour mettre à niveau Milvus de la version 2.1.x à la version 2.4.18, vous devez migrer les métadonnées avant la mise à niveau proprement dite.

Effectuer une mise à niveau continue

Depuis Milvus 2.2.3, vous pouvez configurer les coordinateurs Milvus pour qu'ils fonctionnent en mode actif-veille et activer la fonction de mise à niveau continue pour eux, afin que Milvus puisse répondre aux demandes entrantes pendant les mises à niveau des coordinateurs. Dans les versions précédentes, les coordinateurs doivent être supprimés puis créés au cours d'une mise à niveau, ce qui peut entraîner certains temps d'arrêt du service.

Sur la base des capacités de mise à jour en continu fournies par Kubernetes, l'opérateur Milvus applique une mise à jour ordonnée des déploiements en fonction de leurs dépendances. En outre, Milvus met en œuvre un mécanisme garantissant que ses composants restent compatibles avec ceux qui en dépendent pendant la mise à jour, ce qui réduit considérablement les temps d'arrêt potentiels du service.

La fonction de mise à niveau continue est désactivée par défaut. Vous devez l'activer explicitement par le biais d'un fichier de configuration.

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.18

Dans le fichier de configuration ci-dessus, définissez spec.components.enableRollingUpdate comme true et spec.components.image comme la version souhaitée de Milvus.

Par défaut, Milvus effectue une mise à niveau continue pour les coordinateurs de manière ordonnée, c'est-à-dire qu'il remplace les images des pods des coordinateurs l'une après l'autre. Pour réduire le temps de mise à niveau, envisagez de définir spec.components.imageUpdateMode sur all afin que Milvus remplace toutes les images de pods en même temps.

apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
  name: my-release
spec:
  components:
    enableRollingUpdate: true
    imageUpdateMode: all
    image: milvusdb/milvus:v2.4.18

Vous pouvez définir spec.components.imageUpdateMode sur rollingDowngrade pour que Milvus remplace les images de pods coordinateurs par une version inférieure.

apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
  name: my-release
spec:
  components:
    enableRollingUpdate: true
    imageUpdateMode: rollingDowngrade
    image: milvusdb/milvus:<some-old-version>

Enregistrez ensuite votre configuration sous forme de fichier YAML (par exemple, milvusupgrade.yml) et patchez ce fichier de configuration sur votre instance Milvus comme suit :

kubectl patch -f milvusupgrade.yml

Mettre à niveau Milvus en changeant son image

Dans les cas normaux, vous pouvez simplement mettre à jour votre Milvus en changeant son image. Toutefois, il convient de noter qu'il y aura un certain temps d'arrêt lors de la mise à niveau de Milvus de cette manière.

Composez un fichier de configuration comme suit et enregistrez-le sous milvusupgrade.yaml:

apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
  name: my-release
spec:
  # Omit other fields ...
  components:
   image: milvusdb/milvus:v2.4.18

Exécutez ensuite ce qui suit pour effectuer la mise à niveau :

kubectl patch -f milvusupgrade.yaml

Migrer les métadonnées

Depuis Milvus 2.2.0, les métadonnées sont incompatibles avec celles des versions précédentes. Les exemples suivants supposent une mise à niveau de Milvus 2.1.4 vers Milvus 2.4.18.

1. Création d'un fichier .yaml pour la migration des métadonnées

Créer un fichier de migration des métadonnées. Voici un exemple. Vous devez spécifier les fichiers name, sourceVersion, et targetVersion dans le fichier de configuration. L'exemple suivant définit name en my-release-upgrade, sourceVersion en v2.1.4, et targetVersion en v2.4.18. Cela signifie que votre cluster Milvus sera mis à niveau de la v2.1.4 à la v2.4.18.

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.18"
  # below are some omit default values:
  # targetImage: "milvusdb/milvus:v2.4.18"
  # toolImage: "milvusdb/meta-migration:v2.2.0"
  # operation: upgrade
  # rollbackIfFailed: true
  # backupPVC: ""
  # maxRetry: 3

2. Appliquer la nouvelle configuration

Exécutez la commande suivante pour créer la nouvelle configuration.

$ kubectl create -f https://github.com/zilliztech/milvus-operator/blob/main/config/samples/beta/milvusupgrade.yaml

3. Vérifier l'état de la migration des métadonnées

Exécutez la commande suivante pour vérifier l'état de la migration des métadonnées.

kubectl describe milvus release-name

L'état de ready dans la sortie signifie que la migration des métadonnées est réussie.

Vous pouvez également exécuter la commande kubectl get pod pour vérifier tous les pods. Si tous les pods sont ready, la migration des métadonnées est réussie.

4. Supprimer my-release-upgrade

Lorsque la mise à niveau est réussie, supprimez my-release-upgrade dans le fichier YAML.