Обновление кластера Milvus с помощью Milvus Operator

В этом руководстве описано, как обновить кластер Milvus с помощью Milvus Operator.

Обновление оператора Milvus

Выполните следующую команду, чтобы обновить версию вашего Milvus Operator до v1.2.0.

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

После обновления оператора Milvus до последней версии у вас будут следующие возможности:

• Чтобы обновить Milvus с версии 2.2.3 или более поздних выпусков до версии 2.5.4, вы можете провести скользящее обновление.
• Чтобы обновить Milvus с минорного выпуска до v2.2.3 до 2.5.4, рекомендуется обновить Milvus, изменив версию образа.
• Чтобы обновить Milvus с v2.1.x до 2.5.4, необходимо перенести метаданные до фактического обновления.

Проведение скользящего обновления

Начиная с Milvus 2.2.3, вы можете настроить координаторы Milvus на работу в режиме активного ожидания и включить для них функцию скользящего обновления, чтобы Milvus мог отвечать на входящие запросы во время обновления координаторов. В предыдущих выпусках координаторы должны были удаляться, а затем создаваться во время обновления, что могло привести к некоторому простою службы.

Основываясь на возможностях скользящего обновления, предоставляемых Kubernetes, оператор Milvus обеспечивает упорядоченное обновление развертываний в соответствии с их зависимостями. Кроме того, Milvus реализует механизм, гарантирующий, что его компоненты останутся совместимыми с теми, которые зависят от них во время обновления, что значительно сокращает потенциальное время простоя сервиса.

По умолчанию функция скользящего обновления отключена. Вам необходимо явно включить ее через конфигурационный файл.

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

В приведенном выше файле конфигурации установите spec.components.enableRollingUpdate на true и установите spec.components.image на нужную версию Milvus.

По умолчанию Milvus выполняет обновление координаторов в упорядоченном порядке, заменяя образы капсул координаторов один за другим. Чтобы сократить время обновления, установите spec.components.imageUpdateMode на all, чтобы Milvus заменял все образы стручков одновременно.

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

Вы можете установить spec.components.imageUpdateMode на rollingDowngrade, чтобы Milvus заменял образы координаторов более низкой версией.

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

Затем сохраните свою конфигурацию в виде YAML-файла (например, milvusupgrade.yaml) и подключите этот файл конфигурации к экземпляру Milvus следующим образом:

kubectl patch -f milvusupgrade.yaml --patch-file milvusupgrade.yaml --type merge 

Обновление Milvus путем изменения его образа

В обычных случаях вы можете просто обновить свой Milvus до последней версии, изменив его образ. Однако учтите, что при обновлении Milvus таким способом будет наблюдаться определенное время простоя.

Создайте конфигурационный файл следующим образом и сохраните его под именем milvusupgrade.yaml:

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

Затем выполните следующие действия, чтобы выполнить обновление:

kubectl patch -f milvusupgrade.yaml --patch-file milvusupgrade.yaml --type merge 

Перенос метаданных

Начиная с Milvus 2.2.0, метаданные несовместимы с метаданными предыдущих выпусков. Следующие фрагменты примеров предполагают обновление с Milvus 2.1.4 до Milvus 2.5.4.

1. Создание файла .yaml для миграции метаданных

Создайте файл миграции метаданных. Ниже приведен пример. В файле конфигурации необходимо указать name, sourceVersion и targetVersion. Следующий пример устанавливает name в my-release-upgrade, sourceVersion в v2.1.4, а targetVersion в v2.5.4. Это означает, что ваш кластер Milvus будет обновлен с версии 2.1.4 до версии 2.5.4.

apiVersion: milvus.io/v1beta1
kind: MilvusUpgrade
metadata:
  name: my-release-upgrade
spec:
  milvus:
    namespace: default
    name: my-release
  sourceVersion: "v2.1.4"
  targetVersion: "v2.5.4"
  # below are some omit default values:
  # targetImage: "milvusdb/milvus:v2.5.4"
  # toolImage: "milvusdb/meta-migration:v2.2.0"
  # operation: upgrade
  # rollbackIfFailed: true
  # backupPVC: ""
  # maxRetry: 3

2. Примените новую конфигурацию

Выполните следующую команду, чтобы создать новую конфигурацию.

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

3. Проверьте состояние миграции метаданных

Выполните следующую команду, чтобы проверить статус миграции метаданных.

kubectl describe milvus release-name

Статус ready в выводе означает, что миграция метаданных прошла успешно.

Также можно выполнить команду kubectl get pod, чтобы проверить все поды. Если все капсулы имеют статус ready, миграция метаданных выполнена успешно.

4. Удалить my-release-upgrade

После успешного обновления удалите my-release-upgrade в YAML-файле.