Actualización del clúster de Milvus con Milvus Operator
Esta guía describe cómo actualizar un clúster de Milvus 2.6.x a la versión 3.0.0 con Milvus Operator.
Este procedimiento se ha validado desde Milvus 2.6.20 hasta Milvus v3.0.0 con Milvus Operator 1.3.0, MixCoord, StreamingNode, Woodpecker, etcd dentro del clúster y MinIO dentro del clúster. Si utilizas otra versión de parche de Milvus 2.6.x, otra versión de Operator, otra topología de componentes, otra cola de mensajes o una configuración de dependencias diferente, comprueba primero la actualización en un entorno que no sea de producción.
Requisitos previos
- Un clúster de Kubernetes con un clúster de Milvus 2.6.x gestionado por Milvus Operator
kubectlAcceso al clúster- El manifiesto completo del recurso personalizado (CR) de Milvus utilizado para la implementación existente
- El método de instalación y los manifiestos utilizados para el Milvus Operator existente
- Una copia de seguridad actualizada de los metadatos y los datos persistentes de Milvus
Limitaciones de la cola de mensajes: al actualizar a Milvus v3.0.0, debes mantener tu elección actual de cola de mensajes. No se admite el cambio entre diferentes sistemas de colas de mensajes durante la actualización. La compatibilidad con el cambio de sistemas de colas de mensajes estará disponible en futuras versiones.
Aplica el CR completo de Milvus para esta actualización. No utilices un parche de fusión que solo incluya la imagen. El Operador puede establecer por defecto los campos de componentes omitidos con cero réplicas, lo que puede volver a habilitar un componente que la implementación 2.6.x existente haya deshabilitado.
Este procedimiento no valida una degradación o una reversión mediante el cambio de la imagen de Milvus a la versión 2.6.x. Una vez que la versión 3.0.0 haya escrito datos, una reversión que afecte únicamente a la imagen podría no leer correctamente el estado actualizado. Si la actualización falla, detén las escrituras y utiliza un plan de recuperación que restaure los metadatos previos a la actualización y las copias de seguridad de los datos persistentes. Valida primero el plan de recuperación en un entorno que no sea de producción.
Proceso de actualización
Paso 1: Realizar una copia de seguridad del CR actual de Milvus
Guarde el CR actual antes de modificar la implementación:
kubectl get milvus <instance-name> \
--namespace <namespace> \
--output yaml > milvus-before-upgrade.yaml
Utilice el manifiesto de origen de su implementación existente como manifiesto de actualización. No aplique directamente el archivo de copia de seguridad exportado sin eliminar primero los metadatos gestionados por el servidor y los campos de estado.
Paso 2: Confirma la versión de Milvus Operator
Comprueba la imagen utilizada por el Milvus Operator instalado:
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 actualización validada mantuvo Milvus Operator en la versión 1.3.0. Mantén la versión de Operator que gestiona actualmente tu despliegue de Milvus 2.6.x, a menos que tu política de soporte requiera una actualización independiente de Operator. No rebajes la versión de un Operator más reciente a la versión probada. Si necesitas cambiar la versión del Operator, utiliza el mismo método de instalación (Helm o kubectl ) y el mismo nombre de versión y espacio de nombres que la instalación existente; a continuación, valida el cambio del Operator antes de actualizar el CR de Milvus.
Paso 3: Actualizar la imagen de Milvus
En el manifiesto completo de la CR de Milvus, cambia spec.components.image por la versión de destino. Mantén el modo actual, la topología de componentes, la cola de mensajes, etcd, el almacenamiento y otros ajustes de dependencias. El siguiente extracto muestra los campos que debes confirmar; no sustituyas tu CR completa por este extracto.
Antes de aplicar la CR de destino, compruebe que indexNode.replicas sea 0. La configuración validada de Milvus 2.6.20 ya utilizaba esta configuración. Mantenga la configuración explícita de cero réplicas en la CR de destino.
apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
name: <instance-name>
namespace: <namespace>
spec:
components:
image: milvusdb/milvus:v3.0.0
indexNode:
replicas: 0
Aplica el manifiesto CR completo:
kubectl apply --filename milvus.yaml
Comprueba la actualización
Comprueba el estado del CR, el estado de los pods y las imágenes de los contenedores:
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}'
Comprueba que el CR de Milvus indique « Healthy », que todos los componentes de Milvus utilicen « milvusdb/milvus:v3.0.0 », que no haya ningún pod de IndexNode en ejecución y que las colecciones existentes sigan siendo consultables y buscables. Realiza estas comprobaciones antes de habilitar cualquier función específica de la versión 3.0.0.
