Обновление кластера Milvus с помощью Milvus Operator
В данном руководстве описано, как обновить кластер Milvus версии 2.6.x до версии 3.0.3 с помощью Milvus Operator.
Эта процедура проверена при обновлении с Milvus 2.6.20 до Milvus v3.0.3 с использованием Milvus Operator 1.3.0, MixCoord, StreamingNode, Woodpecker, etcd внутри кластера и MinIO внутри кластера. Если вы используете другой патч-релиз Milvus 2.6.x, версию Operator, топологию компонентов, очередь сообщений или конфигурацию зависимостей, сначала проверьте обновление в тестовой среде.
Необходимые условия
- Кластер Kubernetes с кластером Milvus 2.6.x, управляемым Milvus Operator
kubectlдоступ к кластеру- Полный манифест пользовательского ресурса (CR) Milvus, используемый для существующего развертывания
- Метод установки и манифесты, используемые для существующего Milvus Operator
- Актуальная резервная копия метаданных Milvus и постоянных данных
Ограничения, связанные сочередью сообщений: при обновлении до Milvus v3.0.3 необходимо сохранить текущий выбор системы очереди сообщений. Переключение между различными системами очередей сообщений во время обновления не поддерживается. Поддержка смены систем очередей сообщений будет доступна в будущих версиях.
Примените полный манифест пользовательского ресурса Milvus для данного обновления. Не используйте патч слияния, содержащий только образ. Оператор может по умолчанию заполнить пропущенные поля компонентов с нулевым количеством реплик, что может привести к повторной активации компонента, отключенного в существующем развертывании версии 2.6.x.
Данная процедура не проверяет возможность перехода на более раннюю версию или отката путем возврата образа Milvus к версии 2.6.x. После того как версия v3.0.3 запишет данные, откат, включающий только образ, может не смочь прочитать обновленное состояние. Если обновление завершится сбоем, остановите запись и воспользуйтесь планом восстановления, который восстанавливает метаданные, существовавшие до обновления, и резервные копии постоянных данных. Сначала проверьте план восстановления в непроизводственной среде.
Процесс обновления
Шаг 1: Сделайте резервную копию текущего CR Milvus
Сохраните текущий CR перед изменением развертывания:
kubectl get milvus <instance-name> \
--namespace <namespace> \
--output yaml > milvus-before-upgrade.yaml
Используйте исходный манифест вашего существующего развертывания в качестве манифеста обновления. Не применяйте экспортированный файл резервной копии напрямую, не удалив сначала управляемые сервером метаданные и поля состояния.
Шаг 2: Проверьте версию Milvus Operator
Проверьте образ, используемый установленным Milvus Operator:
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
В ходе проверенного обновления версия Milvus Operator осталась 1.3.0. Сохраните версию Operator, которая в настоящее время управляет вашим развертыванием Milvus 2.6.x, если только ваша политика поддержки не требует отдельного обновления Operator. Не понижайте версию более нового Operator до протестированной версии. Если вам необходимо изменить версию Operator, используйте тот же метод установки (Helm или kubectl ), а также то же имя выпуска и пространство имён, что и в существующей установке, а затем проверьте изменение Operator перед обновлением Milvus CR.
Шаг 3: Обновите образ Milvus
В полном манифесте CR Milvus замените spec.components.image на целевую версию. Сохраните текущие настройки режима, топологии компонентов, очереди сообщений, etcd, хранилища и других зависимостей. В приведенном ниже фрагменте показаны поля, которые необходимо проверить; не заменяйте полный CR этим фрагментом.
Перед применением целевого CR убедитесь, что indexNode.replicas имеет значение 0. В проверенной конфигурации Milvus 2.6.20 уже использовался этот параметр. Сохраните явную настройку с нулевым количеством реплик в целевом CR.
apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
name: <instance-name>
namespace: <namespace>
spec:
components:
image: milvusdb/milvus:v3.0.3
indexNode:
replicas: 0
Примените полный манифест CR:
kubectl apply --filename milvus.yaml
Проверьте обновление
Проверьте статус CR, статус Pod и образы контейнеров:
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}'
Убедитесь, что CR Milvus сообщает Healthy, все компоненты Milvus используют milvusdb/milvus:v3.0.3, ни один Pod IndexNode не запущен, а существующие коллекции по-прежнему доступны для запросов и поиска. Завершите эти проверки, прежде чем включать какие-либо функции, специфичные для версии v3.0.3.
