Migrar entre dos instancias de MCK

Este procedimiento migra una implementación de MongoDB gestionada por una instalación de Kubernetes Operator a una segunda instalación de Kubernetes Operator, en el mismo Ops Manager o proyecto de Cloud Manager. Utilice este procedimiento cuando mueva una implementación entre namespaces o entre clústeres de Kubernetes, en lugar de desde máquinas virtuales a Kubernetes por primera vez.

En esta migración, la implementación de origen ya está gestionada por el operador de Kubernetes: la configuración de automatización contiene nombres de procesos estilo operador de Kubernetes y nombres de host. El destino es una segunda instalación del operador de Kubernetes en otro namespace o clúster.

Antes de comenzar

Confirme lo siguiente antes de migrar una implementación entre dos instalaciones del operador de Kubernetes:

Una conexión de Ops Manager o Cloud Manager ConfigMap con las claves baseUrl, orgId y projectName.
Una clave API Secret con las claves publicKey y privateKey.
El operador de Kubernetes ServiceAccount tiene batch/jobs permisos (create, get, list, watch y delete) para la tarea de conectividad de prueba en seco.
El Proyecto contiene exactamente una implementación.

También necesita:

Una implementación de origen que gestiona una instalación de operador de Kubernetes en ejecución.
Una segunda instalación del operador de Kubernetes que desea que se convierta en el destino, en un namespace o clúster de Kubernetes diferente al de origen.
Ambas instalaciones configuradas con el mismo ConfigMap y credenciales del proyecto de MongoDB Ops Manager o Cloud Manager.

Mantenga al menos 3 nodos de votación en todo momento. El operador de Kubernetes rechaza más de 7 nodos de votación. Si supera los 7, agregue nodos de Kubernetes sin derecho a voto o remueva nodos externos con derecho a voto.
Realice solo un tipo de cambio a la vez: agregue nodos de Kubernetes, elimine nodos externos o cambie los votos y la prioridad de solo un nodo a la vez. La validación de admisión rechaza los cambios mixtos una vez que la migración ha comenzado, y también rechaza remover nodos de Kubernetes o agregar nodos externos a mitad de la migración.
Actúe solo cuando la implementación esté en el estado objetivo.
Migre el primario al final. Cambiar los votos y la prioridad a un nodo puede ser un activador de una elección, y las operaciones de guardar pueden fallar brevemente mientras el set de réplicas elige un nuevo primario. Migrar el primario en último lugar evita activar esa elección y el tiempo de inactividad de guardado que provoca hasta el último paso.

Nota
También puede activar una reelección aumentando la prioridad de un nodo en Kubernetes.
Mientras spec.externalMembers no esté vacío, el operador de Kubernetes fuerza el escalado de un nodo a la vez. Por eso, cada cambio necesita su propia espera para el estado objetivo.

En qué se diferencia esto de migrar de máquinas virtuales

Una migración de MCK a MCK utiliza el mismo bucle de extensión, promoción y poda que la migración de una implementación de máquina virtual. Los nodos de origen aparecen como spec.externalMembers en el recurso de destino, de la misma manera que lo hacen al migrar desde máquinas virtuales. Para conocer la mecánica detallada paso a paso de ese bucle, consulte Migrar un set de réplicas a Kubernetes.

Esta migración tiene requisitos adicionales que no se aplican a una migración de máquinas virtuales:

Detenga o reduzca el alcance del operador de origen primero. Antes de empezar, detenga la instalación del operador de Kubernetes de origen o asegúrese de que deje de conciliar la implementación. Dos operadores nunca deben conciliar el mismo Proyecto de MongoDB Ops Manager o Cloud Manager al mismo tiempo.
Ambos operadores deben compartir el mismo ConfigMap del Proyecto y las credenciales. Las instalaciones del operador de Kubernetes de origen y de destino se conectan al mismo Proyecto de MongoDB Ops Manager o Cloud Manager.
Los nombres de recursos de Helm con alcance de clúster no deben entrar en conflicto. Las dos instalaciones de Helm de los operadores deben usar nombres distintos para cualquier recurso con ámbito de clúster.
Los namespace deben diferir. Si las instalaciones de origen y de destino compartieran un namespace, los nombres de los procesos chocarían.

Migrar la implementación

Importante

Detenga o reduzca el alcance del operador de origen antes de continuar. Consulte la sección anterior.

Siga la misma secuencia de extender, promover y podar descrita en Migrar un set de réplicas a Kubernetes, generando el recurso personalizado de MongoDB de destino en el namespace y clúster de la instalación del operador de Kubernetes de destino. Los nodos de origen aparecen en spec.externalMembers en el recurso de destino hasta que los pode.

Razón	Estado	Significado
`Validating`	`True`	La anotación de dry-run está establecida.
`Extending`	`True`	El recuento de nodos de Kubernetes deseado supera el último recuento conciliado.
`Pruning`	`True`	El recuento de `externalMembers` cayó por debajo de `status.migrationObservedExternalMembersCount`.
`InProgress`	`True`	Existen nodos externos, pero nada está cambiando. Esta es también la razón de la primera conciliación.
`MigrationComplete`	`False`	Todos los nodos externos han sido eliminados.

La precedencia es Validating > Extending > Pruning > InProgress. Una poda que también hace crecer el lado de Kubernetes informa Extending, lo cual es otra razón para hacer un cambio a la vez.

No se permite la poda y la extensión al mismo tiempo.

Para crear un script para la finalización de la migración, utilice kubectl wait --for=condition=Migrating=False en lugar de sondear status.phase.

Limpiar la fuente

Una vez finalizada la migración, borre el recurso personalizado de MongoDB de origen. No borre el Ops Manager o el Proyecto de Cloud Manager, y no borre los datos subyacentes. Al borrar el recurso personalizado de origen, solo se remueve la gestión de ese recurso por parte de la instalación del operador de Kubernetes de origen.

Obtén más información

Volver

Clúster fragmentado

Interacción de MongoDB Search