Kubernetes Operator puede migrar una implementación que Ops Manager o Cloud Manager gestiona en máquinas virtuales o en hardware sin sistema operativo a Kubernetes. La migración está activa y es incremental. La implementación sigue sirviendo lecturas y guardar durante todo el proceso. Mueve los nodos de las máquinas virtuales a Kubernetes uno a uno, mediante la replicación normal 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:
Extender. Agrega nodos de Kubernetes al set de réplicas existente. El operador de Kubernetes crea los nuevos nodos como no votantes y realizan una sincronización inicial desde los nodos existentes.
Promover. Se trasladan los votos y la prioridad de los nodos de máquinas virtuales a los nodos de Kubernetes. Los nodos externos conservan los votos y la prioridad que ya tienen en la configuración de automatización de origen hasta que los remueva.
Ciruela pasa. Remueve los nodos de la máquina virtual uno a la vez, esperando a que el set de réplicas alcance el estado objetivo entre cada remoción.
La migración se completa cuando el operador de Kubernetes gestiona el 100% de los nodos, spec.externalMembers está vacío y todos los datos residen en las reclamaciones de volumen persistente de Kubernetes. En ese punto, no quedan nodos en las máquinas virtuales.
Por qué la migración no utiliza la restauración de snapshot o Cluster-to-Cluster Sync
El flujo de trabajo de migración no restaura un snapshot y no utiliza mongosync ni otra herramienta Cluster-to-Cluster Sync. Las herramientas Cluster-to-Cluster Sync imponen tiempo de inactividad en la transición, carecen de soporte para colecciones de series de tiempo y, por lo general, requieren ayuda de campo para ejecutarse de forma segura. La migración basada en replicación evita estas limitaciones. Su implementación permanece disponible, la migración admite los mismos tipos de colección que el resto de su implementación y usted mismo dirige el proceso con el plugin 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 drivers deben utilizar escrituras reintentables. La latencia de lectura puede aumentar si un objetivo de lectura se mueve, por lo que ejecute el clúster de Kubernetes en la misma región que las máquinas virtuales. Los cursores de larga duración en un secundario migrado se rompen, porque no hay modo de inactividad.
La operación híbrida es transitoria
Mientras la migración está en curso, su implementación se ejecuta en un estado híbrido con nodos en división entre máquinas virtuales y Kubernetes. El operador de Kubernetes soporta este estado híbrido solo como una condición transitoria durante una migración activa. La migración requiere conectividad de red bidireccional permanente entre los dos entornos durante toda la migración. Kubernetes Operador no admite la ejecución de una implementación de entorno de división indefinidamente.
Qué no hace la migración
Operador de Kubernetes no:
Dar de baja las máquinas virtuales. Usted mismo las retira una vez que finalice la migración.
Revertir una migración. No existe una forma automatizada de revertir una migración una vez iniciada.
Inicialice o precopie los datos. Todo movimiento de datos se realiza a través de la replicación de MongoDB.
migrar MongoDB Ops Manager o Cloud Manager mismo. Solo la implementación de MongoDB se traslada a Kubernetes.