Este procedimiento migra cualquier set de réplicas que gestiona MongoDB Ops Manager o Cloud Manager en Kubernetes bajo el operador de Kubernetes, mediante la replicación normal de MongoDB. Esto incluye implementaciones que se ejecutan en máquinas virtuales o en hardware sin sistema operativo, e implementaciones ya gestionadas por una instancia de operador de Kubernetes diferente. La migración está activa y es incremental: se extiende el set de réplicas a Kubernetes, se promocionan los nodos de Kubernetes y luego se eliminan los nodos externos. No hay restauración de snapshot y no hay mongosync involucrado.
Antes de comenzar
Confirme lo siguiente antes de migrar un set de réplicas:
Una conexión de Ops Manager o Cloud Manager
ConfigMapcon las clavesbaseUrl,orgIdyprojectName.Una clave API
Secretcon las clavespublicKeyyprivateKey.El operador de Kubernetes
ServiceAccounttienebatch/jobspermisos (create,get,list,watchydelete) para la tarea de conectividad de prueba en seco.El Proyecto contiene exactamente una implementación.
También necesita:
Un set de réplicas existente que gestiona MongoDB Ops Manager o Cloud Manager.
Exactamente una implementación en el MongoDB Ops Manager o Proyecto de Cloud Manager.
Un clúster de Kubernetes con el operador de Kubernetes instalado.
El plugin
kubectl mongodben una versión que coincida con el operador de Kubernetes. El operador de Kubernetes aplica esta coincidencia en cada conciliación, incluida la ejecución de prueba.Conectividad de red bidireccional y resolución de nombres de host entre los host de máquinas virtuales y los Pods de Kubernetes.
Certificados TLS preconfigurados que cubren todos los SAN, si la implementación utiliza TLS.
Las contraseñas de usuario SCRAM a mano. No puede recuperarlos de la configuración de automatización.
Una copia de seguridad realizada antes de empezar.
Una implementación que está en buen estado y en el estado objetivo.
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.externalMembersno 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.
Procedimiento
Generar el recurso personalizado de MongoDB.
Ejecute el comando kubectl mongodb migrate-to-mck mongodb:
kubectl mongodb migrate-to-mck mongodb \ --config-map-name <configmap> \ --secret-name <secret> \ --namespace <namespace> \ -o mongodb-cr.yamlInspeccionar el archivo generado. Contiene:
spec.externalMembers, enumerando los procesos de origen.spec.membersSe debe establecer en0.La anotación
mongodb.com/migration-dry-run: true, que el plugin siempre añade.
El comando también admite estas banderas opcionales:
--certs-secret-prefix: obligatorio cuando TLS está habilitado. Establecespec.security.certsSecretPrefix.--prometheus-secret-name: usar cuando Prometheus está habilitado. ElSecretya debe existir y tener una clavepassword.--resource-name-override: establecemetadata.nameen el recurso generado. El plugin normaliza el nombre del set de réplicas automáticamente cuando no es un nombre de Kubernetes válido, y establecespec.replicaSetNameOverridepor usted.
Generar los recursos personalizados de MongoDBUser.
Complete este paso solo si desea migrar sus usuarios de base de datos. La migración no lo requiere.
Precree un Secret por usuario SCRAM, cada uno con una clave password. Ejecuta:
kubectl mongodb migrate-to-mck users \ --config-map-name <configmap> \ --secret-name <secret> \ --namespace <namespace> \ --users-secrets-file users.csv \ -o users-cr.yamlEl archivo CSV asigna usuarios a Secretos, uno por línea, en el formato username:database,secret-name. Omita --users-secrets-file para que se le solicite información para cada usuario en su lugar.
El plugin genera usuarios X.509 y LDAP en la base de datos $external. Omite el usuario del agente de automatización.
Si la implementación utiliza TLS, emita los certificados de nodo de Kubernetes.
Emita los certificados de nodo de Kubernetes de la misma autoridad de certificación que firmó los certificados de la máquina virtual.
El operador de Kubernetes espera un kubernetes.io/tls Secret llamado <certsSecretPrefix>-<resourceName>-cert y un CA ConfigMap llamado <resourceName>-ca que contenga tanto una clave ca-pem como una clave mms-ca.crt. Los certificados necesitan SAN que cubran los nombres DNS por Pod y de servicio, y los usos de autenticación de servidor y de cliente.
Si la implementación de origen no utiliza TLS, establezca net.tls.mode en disabled en MongoDB Ops Manager o Cloud Manager, en la implementación de máquina virtual existente, antes de migrar. No es necesario configurar nada en el recurso personalizado de MongoDB para este caso.
Nota
Una discrepancia de CA es detectada por la ejecución de prueba en el siguiente paso, por diseño.
Configure el acceso externo.
Antes de ejecutar la prueba en seco, configure spec.externalAccess para que los nodos de la máquina virtual puedan acceder a los Pods de Kubernetes. Para permitir que esos nodos resuelvan los Pods por nombre de host, también puede establecer spec.externalAccess.externalDomain. Para obtener información sobre los campos implicados y los requisitos de DNS, consulte Requisitos de red para la migración.
Esta configuración la gestiona el usuario: configura los LoadBalancers o NodePorts y los registros DNS para su entorno.
Importante
No establezca externalDomain si utiliza MongoDB Search o búsqueda vectorial con esta implementación. MongoDBSearch no admite un recurso MongoDB que establezca externalDomain, y no puede remover el campo después de crear el clúster. Para obtener más información, consulte Interacción de MongoDB Search con la migración.
Ejecute la simulación y compruebe la conectividad.
Aplique el recurso generado con la anotación mongodb.com/migration-dry-run todavía presente. Mientras la anotación está establecida, el operador de Kubernetes no realiza cambios en la configuración de automatización y solo valida la conectividad.
El operador de Kubernetes crea una tarea llamada <resourceName>-connectivity-check, que llama a cada nodo externo y se autentica. La tarea se borra a sí misma usando ttlSecondsAfterFinished, y la siguiente reconciliación la vuelve a crear, por lo tanto, la revalidación es automática. Puede solucionar problemas en Kubernetes o en la Interfaz de Usuario de Ops Manager y volver a ejecutar libremente.
La ejecución de prueba comprueba la accesibilidad de Kubernetes a la máquina virtual (DNS, TLS, firewalls y direcciones de nodo) y las credenciales, incluido el rol __system en la base de datos local y la CA cuando TLS está habilitado. No comprueba la conectividad de entrada de máquina virtual a Kubernetes.
Dado que esa dirección depende completamente de su configuración de configurar red, ningún comando único puede garantizarlo. En su lugar, recorra esta lista de comprobación:
Confirme que los nombres de host que tendrán los nodos de Kubernetes, siguiendo el patrón
<metadata.name>-0.<spec.externalAccess.externalDomain>, se pueden resolver desde los nodos de la máquina virtual.Confirme que se puede acceder al nodo de Kubernetes o a las IP del equilibrador de carga desde las máquinas virtuales.
Lea el resultado de status.conditions[type=NetworkConnectivityVerified]:
Código de salida de la tarea del validador | Estado de la condición | Razón | Significado |
|---|---|---|---|
Tarea aún en ejecución |
|
| El |
|
|
| Todos los nodos externos son accesibles y están autenticados. |
|
|
| Credenciales, el mecanismo de autenticación o un rol |
|
|
| DNS, TLS, tiempos de espera o nodos inaccesibles. Compruebe el registro de la tarea Pod. |
|
|
| Error sin clasificar. Compruebe el registro de la tarea Pod. |
Los errores que se producen antes de que se inicie la tarea utilizan los motivos OperatorImageUnknown, BuildStatefulSetOptions, AgentCertSecretFailed y AgentCertSubject.
El operador de Kubernetes remueve la condición NetworkConnectivityVerified de status.conditions por completo una vez que no queden nodos externos.
Extender el set de réplicas en Kubernetes.
Remover la anotación dry-run:
kubectl annotate mdb <resourceName> \ mongodb.com/migration-dry-run-Este es el punto en el que el operador de Kubernetes asume la propiedad del Proyecto de MongoDB Ops Manager.
Levantar spec.members y guardar a mano spec.memberConfig juntos.
Advertencia
Establecer spec.memberConfig antes de aumentar el número de nodos
Por defecto, los nuevos nodos de Kubernetes se unen como nodos con derecho a voto. Los valores por defecto de CRD son votes: 1 y priority: "1", que permiten que un nodo que aún se está sincronizando participe en una elección antes de que haya terminado su sincronización inicial.
MongoDB recomienda que guarde una entrada spec.memberConfig por cada nodo nuevo de Kubernetes con votes: 0 y priority: "0" antes de aumentar el recuento de nodos, para que un nodo que se está sincronizando no pueda ganar una elección. votes es un número entero. priority es un string.
Por ejemplo, para añadir tres nodos de Kubernetes sin derecho a voto:
spec: memberConfig: - votes: 0 priority: "0" - votes: 0 priority: "0" - votes: 0 priority: "0"Espere a la sincronización inicial completa y al estado objetivo. Si generó recursos de MongoDBUser en el paso opcional anterior, aplíquelos ahora y confirme que cada uno alcance un status.phase de Updated.
Promover los nodos de Kubernetes.
Traslade los votos y la prioridad a los nodos de Kubernetes editando spec.memberConfig. votes es un entero. priority es un string que contiene un flotante.
Los nodos externos conservan los votos y la prioridad que tengan en la configuración de automatización de origen. spec.externalMembers no tiene el campo votes ni priority.
Esperar el estado objetivo.
Podar los nodos externos.
Importante
Remover solo una entrada de spec.externalMembers a la vez. Esperar el estado objetivo después de cada remoción antes de remover la siguiente entrada.
Por ejemplo:
kubectl patch mdb <resourceName> --type=json \ -p='[{"op":"remove","path":"/spec/externalMembers/0"}]'Puede remover entradas, pero nunca agregarlas una vez que la migración haya comenzado.
Vea a status.conditions[type=Migrating].reason moverse a través de Extending, InProgress y Pruning:
Razón | Estado | Significado |
|---|---|---|
|
| La anotación de dry-run está establecida. |
|
| El recuento de nodos de Kubernetes deseado supera el último recuento conciliado. |
|
| El recuento de |
|
| Existen nodos externos, pero nada está cambiando. Esta es también la razón de la primera conciliación. |
|
| 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.
Verificar y finalizar.
La migración se completa cuando spec.externalMembers está vacío, la condición Migrating es False con el motivo MigrationComplete, y todos los datos residen en reclamaciones de volumen persistente:
kubectl wait --for=condition=Migrating=False mdb/<resourceName>Actualice las cadenas de conexión de su aplicación y retire las máquinas virtuales. El operador de Kubernetes no da de baja las máquinas virtuales por usted.
Secreto de la cadena de conexión
El operador de Kubernetes genera automáticamente una cadena de conexión Secret que no contiene credenciales, denominada <metadata.name>-cluster-connection-string, y la mantiene sincronizada con los nodos activos. Apunte sus aplicaciones a esta Secret en lugar de codificar rígidamente una cadena de conexión.
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.