Kubernetes Operator puede migrar a Kubernetes una implementación gestionada por Ops Manager o Cloud Manager en máquinas virtuales o hardware físico. La migración es incremental y en tiempo real. Su implementación continúa gestionando operaciones de lectura y escritura durante todo el proceso. Los miembros se trasladan de las máquinas virtuales a Kubernetes uno a uno, utilizando la replicación estándar de MongoDB.
Cómo funciona la migración
La migración se basa en la replicación estándar de MongoDB en lugar de una herramienta de copia de datos. Se desarrolla en tres fases:
Ampliar. Se añaden miembros de Kubernetes al conjunto de réplicas existente. El operador de Kubernetes crea los nuevos miembros sin derecho a voto y realiza una sincronización inicial con los miembros existentes.
Promocionar. Transfiere los votos y la prioridad de los miembros de la máquina virtual a los miembros de Kubernetes. Los miembros externos conservan los votos y la prioridad que ya tienen en la configuración de automatización de origen hasta que los elimines.
Poda. Se eliminan los miembros de la máquina virtual uno a uno, esperando a que el conjunto de réplicas alcance el estado deseado entre cada eliminación.
La migración se completa cuando el operador de Kubernetes gestiona el 100% de los miembros, spec.externalMembers está vacío y todos los datos residen en las solicitudes de volumen persistente de Kubernetes. En ese momento, no quedan miembros en las máquinas virtuales.
Por qué la migración no utiliza la restauración de instantáneas ni la sincronización de clúster a clúster.
El flujo de trabajo de migración no restaura una instantánea ni utiliza mongosync ni ninguna otra herramienta de sincronización entre clústeres. Las herramientas de sincronización entre clústeres imponen tiempos de inactividad durante la transición, carecen de soporte para colecciones de series temporales y, por lo general, requieren asistencia técnica para funcionar correctamente. La migración basada en replicación evita estas limitaciones. Su implementación permanece disponible, la migración admite los mismos tipos de colecciones que el resto de su implementación y usted mismo gestiona el proceso con el complemento kubectl mongodb.
Disponibilidad durante la migración
Las lecturas permanecen disponibles durante toda la migración. Las escrituras podrían fallar brevemente durante las elecciones, por lo que sus controladores deben usar escrituras reintentables. La latencia de lectura puede aumentar si un destino de lectura cambia de ubicación, por lo que debe ejecutar el clúster de Kubernetes en la misma región que las máquinas virtuales. Los cursores de larga duración que se ejecutan en un servidor secundario migrado fallan, ya que no existe un modo de inactividad.
El funcionamiento híbrido es transitorio.
Mientras se realiza la migración, su implementación se ejecuta en un estado híbrido, con los miembros distribuidos entre máquinas virtuales y Kubernetes. Kubernetes Operator solo admite este estado híbrido de forma transitoria durante una migración activa. La migración requiere conectividad de red bidireccional permanente entre ambos entornos durante todo el proceso. Kubernetes Operator no admite la ejecución indefinida de una implementación en un entorno dividido.
Lo que la migración no hace
El operador de Kubernetes no hace lo siguiente:
Desactive las máquinas virtuales. Usted mismo las retirará una vez finalizada la migración.
Revertir una migración. No existe una forma automatizada de revertir una migración una vez iniciada.
Copia inicial o previa de datos. Todo el movimiento de datos se realiza mediante la replicación de MongoDB.
Migre Ops Manager o Cloud Manager. Solo la implementación de MongoDB se traslada a Kubernetes.