Este procedimiento migra cualquier conjunto de réplicas administrado por Ops Manager o Cloud Manager a Kubernetes bajo Kubernetes Operator, utilizando la replicación estándar de MongoDB. Esto incluye implementaciones que se ejecutan en máquinas virtuales o hardware físico, así como implementaciones ya administradas por una instancia diferente de Kubernetes Operator. La migración es incremental y en tiempo real: se extiende el conjunto de réplicas a Kubernetes, se promueven los miembros de Kubernetes y, finalmente, se eliminan los miembros externos. No se requiere restauración de instantáneas ni se utiliza mongosync.
Antes de comenzar
Confirme lo siguiente antes de migrar un conjunto 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
ServiceAccounttiene permisosbatch/jobs(create,get,list,watchydelete) para el trabajo de conectividad de prueba.El proyecto contiene exactamente un despliegue.
También necesitas:
Un conjunto de réplicas existente que gestiona Ops Manager o Cloud Manager.
Exactamente una implementación en el proyecto de Ops Manager o Cloud Manager.
Un clúster de Kubernetes con el operador de Kubernetes instalado.
El complemento
kubectl mongodbdebe tener una versión compatible con Kubernetes Operator. Kubernetes Operator aplica esta compatibilidad en cada reconciliación, incluida la prueba en seco.Conectividad de red bidireccional y resolución de nombres de host entre los hosts de las máquinas virtuales y los Pods de Kubernetes.
Certificados TLS preconfigurados que cubren todas las SAN, si la implementación utiliza TLS.
Las contraseñas de usuario de SCRAM están en nuestro poder. No se pueden recuperar desde la configuración de automatización.
Realiza una copia de seguridad antes de comenzar.
Un despliegue que funciona correctamente y ha alcanzado el estado deseado.
Mantén siempre al menos 3 miembros con derecho a voto. El operador de Kubernetes rechaza más de 7 miembros con derecho a voto. Si superas los 7, añade miembros de Kubernetes sin derecho a voto o elimina los miembros externos con derecho a voto.
Realice solo un tipo de cambio a la vez: agregue miembros de Kubernetes, elimine miembros externos o modifique los votos y la prioridad de un solo miembro a la vez. La validación de admisión rechaza los cambios mixtos una vez iniciada la migración, y también rechaza la eliminación de miembros de Kubernetes o la adición de miembros externos durante la migración.
Actúa únicamente cuando el despliegue haya alcanzado el estado deseado.
Migrar el nodo primario al final. Cambiar los votos y la prioridad a un miembro puede desencadenar una elección, y las escrituras pueden fallar brevemente mientras el conjunto de réplicas elige un nuevo nodo primario. Migrar el nodo primario al final evita que se desencadene dicha elección, y el tiempo de inactividad de escritura que provoca, hasta el paso final.
Nota
También puedes provocar una reelección aumentando la prioridad de un miembro en Kubernetes.
Mientras
spec.externalMembersno esté vacío, el operador de Kubernetes fuerza el escalado de un miembro a la vez. Por eso, cada cambio requiere su propio tiempo de espera para alcanzar 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.yaml
Inspeccione el archivo generado. Contiene:
spec.externalMembers, enumerando los procesos fuente.spec.membersSe debe establecer en0.La anotación
mongodb.com/migration-dry-run: true, que el complemento siempre agrega.
El comando también admite estas opciones:
--certs-secret-prefix: requerido 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 complemento normaliza automáticamente el nombre del conjunto de réplicas cuando no es un nombre válido de Kubernetes y establecespec.replicaSetNameOverridepor usted.
Generar los recursos personalizados de MongoDBUser.
Complete este paso únicamente si desea migrar los usuarios de su base de datos. La migración no lo requiere.
Precrea un Secret por usuario de SCRAM, cada uno con una clave password. Ejecutar:
kubectl mongodb migrate-to-mck users \ --config-map-name <configmap> \ --secret-name <secret> \ --namespace <namespace> \ --users-secrets-file users.csv \ -o users-cr.yaml
El 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 para cada usuario.
El complemento genera usuarios X.509 y LDAP contra la base de datos $external. Omite el usuario del agente de automatización.
Si el despliegue utiliza TLS, emita los certificados de miembro de Kubernetes.
Emita los certificados de miembro de Kubernetes desde la misma autoridad de certificación que firmó los certificados de la máquina virtual.
Kubernetes Operator espera un certificado kubernetes.io/tls Secret llamado <certsSecretPrefix>-<resourceName>-cert y una CA ConfigMap llamada <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 Servicio, así como los usos de autenticación de servidor y cliente.
Si la implementación de origen no utiliza TLS, configure net.tls.mode a disabled en 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 en este caso.
Nota
Un desajuste de CA se detecta mediante la prueba en seco en el siguiente paso, de forma intencionada.
Configurar el acceso externo.
Antes de ejecutar la prueba, configure spec.externalAccess para que los miembros de la máquina virtual puedan acceder a los Pods de Kubernetes. Para que estos miembros puedan resolver los Pods por nombre de host, también puede configurar spec.externalAccess.externalDomain. Para obtener más información sobre los campos involucrados y los requisitos de DNS, consulte Requisitos de red para la migración.
Esta configuración es responsabilidad del usuario: usted configura los LoadBalancers o NodePorts y los registros DNS para su entorno.
Importante
No configure externalDomain si utiliza MongoDB Search o Vector Search con esta implementación. MongoDBSearch no admite un recurso MongoDB que configure externalDomain, y no podrá eliminar 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.
Realice una prueba y compruebe la conectividad.
Aplique el recurso generado con la anotación mongodb.com/migration-dry-run aún presente. Mientras la anotación esté activada, Kubernetes Operator no realiza cambios en la configuración de automatización y solo valida la conectividad.
El operador de Kubernetes crea un trabajo llamado <resourceName>-connectivity-check, que se conecta a cada miembro externo y se autentica. El trabajo se elimina a sí mismo mediante ttlSecondsAfterFinished, y la siguiente reconciliación lo vuelve a crear, por lo que la revalidación es automática. Puede solucionar los problemas en Kubernetes o en la interfaz de usuario de Ops Manager y volver a ejecutarlo sin problemas.
La prueba en seco verifica la accesibilidad de Kubernetes a la máquina virtual (DNS, TLS, cortafuegos y direcciones de miembros) y las credenciales, incluido el rol __system en la base de datos local y la CA cuando TLS está habilitado. No verifica la conectividad entrante de la máquina virtual a Kubernetes.
Dado que esa dirección depende completamente de la configuración de su red, ningún comando por sí solo puede garantizarla. En su lugar, siga esta lista de verificación:
Confirme que los nombres de host que tendrán los miembros de Kubernetes, siguiendo el patrón
<metadata.name>-0.<spec.externalAccess.externalDomain>, se puedan resolver desde los miembros de la máquina virtual.Confirme que las direcciones IP del nodo de Kubernetes o del LoadBalancer sean accesibles desde las máquinas virtuales.
Lee el resultado de status.conditions[type=NetworkConnectivityVerified]:
Código de salida del trabajo del validador | Estado de la condición | Razón | Significado |
|---|---|---|---|
El trabajo sigue en marcha. |
|
| The |
|
|
| Todos los miembros externos son accesibles y están autenticados. |
|
|
| Credentials, the authentication mechanism, or a missing |
|
|
| Problemas con DNS, TLS, tiempos de espera o miembros inaccesibles. Consulte los registros del Job Pod. |
|
|
| Error no clasificado. Compruebe los registros del Job Pod. |
Failures that occur before the Job starts use the reasons OperatorImageUnknown, BuildStatefulSetOptions, AgentCertSecretFailed, and AgentCertSubject.
Kubernetes Operator removes the NetworkConnectivityVerified condition from status.conditions entirely once no external members remain.
Extienda el conjunto de réplicas a Kubernetes.
Elimine la anotación de prueba:
kubectl annotate mdb <resourceName> \ mongodb.com/migration-dry-run-
Este es el momento en el que el operador de Kubernetes toma posesión del proyecto del administrador de operaciones.
Levanta spec.members y escribe a mano spec.memberConfig al mismo tiempo.
Advertencia
Establezca spec.memberConfig antes de aumentar el número de miembros.
By default, new Kubernetes members join as voting members. The CRD defaults are votes: 1 and priority: "1", which let a still-syncing member participate in an election before it has finished its initial sync.
MongoDB recommends that you write one spec.memberConfig entry per new Kubernetes member with votes: 0 and priority: "0" before you raise the member count, so that a still-syncing member cannot win an election. votes is an integer. priority is a string.
Por ejemplo, para agregar tres miembros de Kubernetes como no votantes:
spec: memberConfig: - votes: 0 priority: "0" - votes: 0 priority: "0" - votes: 0 priority: "0"
Espere a que se complete la sincronización inicial y el estado del objetivo. Si generó recursos MongoDBUser en el paso opcional anterior, aplíquelos ahora y confirme que cada uno alcance un status.phase de Updated.
Promocionar a los miembros de Kubernetes.
Cambia los votos y la prioridad a los miembros de Kubernetes editando spec.memberConfig. votes es un entero. priority es una cadena que contiene un número decimal.
Los miembros externos conservan los votos y la prioridad que tengan en la configuración de automatización de origen. spec.externalMembers no tiene campo votes ni priority.
Esperar a que se alcance el estado objetivo.
Poda los miembros externos.
Importante
Elimina solo una entrada de spec.externalMembers a la vez. Espera a que se alcance el estado objetivo después de cada eliminación antes de eliminar la siguiente entrada.
Por ejemplo:
kubectl patch mdb <resourceName> --type=json \ -p='[{"op":"remove","path":"/spec/externalMembers/0"}]'
Puedes eliminar entradas, pero nunca añadirlas una vez que haya comenzado la migración.
Observa cómo status.conditions[type=Migrating].reason se mueve a través de Extending, InProgress y Pruning:
Razón | Estado | Significado |
|---|---|---|
|
| La anotación de prueba está configurada. |
|
| El número deseado de miembros de Kubernetes supera el último recuento conciliado. |
|
| The |
|
| Existen miembros externos, pero nada cambia. Esta es también la razón de la primera reconciliación. |
|
| Todos los miembros externos han sido eliminados. |
Precedence is Validating > Extending > Pruning > InProgress. A prune that also grows the Kubernetes side reports Extending, which is another reason to make one change at a time.
No está permitido podar y alargar al mismo tiempo.
To script against migration completion, use kubectl wait --for=condition=Migrating=False rather than polling status.phase.
Verificar y finalizar.
La migración se completa cuando spec.externalMembers está vacío, la condición Migrating es False con motivo MigrationComplete, y todos los datos residen en reclamaciones de volumen persistentes:
kubectl wait --for=condition=Migrating=False mdb/<resourceName>
Actualiza las cadenas de conexión de tu aplicación y desactiva las máquinas virtuales. Kubernetes Operator no desactiva las máquinas virtuales automáticamente.
Secreto de la cadena de conexión
Kubernetes Operator genera automáticamente una cadena de conexión Secret sin credenciales, denominada <metadata.name>-cluster-connection-string, y la mantiene sincronizada con los nodos activos. En lugar de codificar una cadena de conexión fija, dirija sus aplicaciones a esta Secret.
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.