Solucionar problemas de una migración a Kubernetes

Esta página le ayuda a diagnosticar problemas que pueden surgir al migrar un set de réplicas autogestionado o un clúster de máquinas virtuales a Kubernetes con Kubernetes operador, incluidos los errores de importación de plugins, problemas de ejecución en seco y conectividad, discrepancias de autenticación y errores de validación. Para obtener información de segundo plano sobre el flujo de trabajo de migración, consulte Migrar una implementación autogestionada a Kubernetes.

¿Dónde estoy en la migración?

Lea primero el campo reason de la condición status.conditions[type=Migrating].

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.

Si el motivo sigue siendo Extending, los nodos de Kubernetes que el operador de Kubernetes está añadiendo todavía se están provisionamineto. Espere a que alcancen el estado objetivo.
Si el motivo sigue siendo InProgress y el recuento de nodos externos no cambia, su última edición al recurso fue una operación nula: el operador de Kubernetes no detectó ningún cambio que requiera una acción.

Fallos de importación de plugins

El plugin kubectl mongodb migrate-to-mck valida la configuración de automatización de origen antes de generar cualquier recurso. Sale con un error, en lugar de generar un recurso incompleto o incorrecto, en cada uno de los siguientes casos:

El proyecto de MongoDB Ops Manager o Cloud Manager tiene más de una implementación.
El Proyecto tiene más de un clúster particionado.
El Proyecto tiene set de réplicas que no forman parte del clúster particionado.
El Proyecto no tiene set de réplicas o clúster particionado. El plugin puede migrar solo implementaciones de set de réplicas y de clúster particionado.
La configuración de automatización no tiene procesos.
Una partición en el clúster particionado está respaldada por el mismo set de réplicas que el servidor de configuración. Esta topología de servidor de configuración incrustado no es compatible con la migración.
El plugin no puede encontrar un nodo con derecho a voto y prioridad en un set de réplicas, por lo que no puede determinar el proceso de origen para ese set de réplicas.
Un proceso tiene un processType distinto de mongod o mongos.

Discrepancias en rutas y configuraciones no configurables

El plugin marca las siguientes configuraciones de automatización cuando no coinciden con lo que espera el operador de Kubernetes:

auth.keyFile difiere de la ruta que el operador de Kubernetes deriva de spec.downloadBase.
auth.keyFileWindows está establecido.
monitoringAgentConfig.logPath o backupAgentConfig.logPath está configurado en una ruta no por defecto.
Un proceso tiene un authSchemaVersion que difiere del valor por defecto del operador de Kubernetes.

Errores de autenticación

auth.autoUser está vacío mientras la autenticación está habilitada.
auth.autoUser no tiene una entrada coincidente en auth.usersWanted para su base de datos. Sin una entrada coincidente, la autenticación del agente falla después de la migración.
MONGODB-X509 La autenticación del agente requiere que se establezca tls.autoPEMKeyFilePath en la configuración de automatización. Consulta spec.security.authentication.agents.autoPEMKeyFilePath.
Un LDAP bindMethod que no sea simple no es compatible para la migración.

Heterogeneidad de nodos

El operador de Kubernetes toma spec.additionalMongodConfig y spec.agent.mongod.systemLog de un único proceso de origen. Si su set de réplicas tiene configuraciones diferentes, realice una revisión de todos los nodos y concilie las diferencias antes de migrar — el recurso generado aplica una configuración a todos los nodos de Kubernetes.

Advertencias que merecen atención

Las siguientes configuraciones de automatización por proceso no se transfieren a los nuevos nodos de Kubernetes. Planifíquelos antes de migrar:

secondaryDelaySecs
miembro oculto
buildIndexes: false

Si su implementación de origen tiene nodos de análisis o nodos retrasados, planifique cómo desea representarlos en Kubernetes antes de empezar.

Elementos adicionales para revisar:

El plugin omite un proceso deshabilitado; no aparece como un nodo externo.
Si un proceso no tiene TLS configurado, 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 establezca esto en el recurso MongoDB generado. De lo contrario, la configuración TLS del nodo de Kubernetes no coincide con el proceso de origen, y la migración provoca un cambio de implementación no planificado.
Si la configuración logRotate o auditLogRotate de un proceso difiere de la configuración a nivel de Proyecto, Kubernetes operador utiliza el valor a nivel de Proyecto.

Incompatibilidad de versión

La anotación mongodb.com/migrate-tool-version registra la versión del plugin kubectl mongodb migrate-to-mck que generó el recurso. Kubernetes Operator valida esta anotación con su propia versión en cada reconciliación, incluida la ejecución en seco. Si las versiones son incompatibles, regenere el recurso con una versión de plugin compatible.

Problemas de ejecución en seco

La ejecución de prueba parece atascada

Borrar la tarea <resourceName>-connectivity-check. La siguiente reconciliación lo recrea.

Si la tarea nunca se crea, compruebe que sus permisos RBAC de Kubernetes incluyen batch/jobs. La falta de permisos batch/jobs impide que el operador de Kubernetes cree la tarea de validación de conectividad.

Fallos de conectividad

Código de salida de la tarea del validador	Estado de la condición	Razón	Significado
Tarea aún en ejecución	`Unknown`	`Running`	El `status.phase` es `ConnectivityCheckRunning`.
`0`	`True`	`NetworkValidationPassed`	Todos los nodos externos son accesibles y están autenticados.
`2`	`False`	`AuthenticationFailed`	Credenciales, el mecanismo de autenticación o un rol `__system@local` que falta.
`3`	`False`	`NetworkFailed`	DNS, TLS, tiempos de espera o nodos inaccesibles. Compruebe el registro de la tarea Pod.
`1` o otros	`False`	`UnknownError`	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.

Fallos previos a la tarea

El operador de Kubernetes puede fallar antes de que se inicie la tarea de validación de conectividad por una de las siguientes razones:

OperatorImageUnknown
BuildStatefulSetOptions
AgentCertSecretFailed
AgentCertSubject

Discrepancia de TLS CA

Los certificados de los nodos de Kubernetes deben ser emitidos por la misma autoridad de certificación que firmó los certificados de los nodos de la máquina virtual. Si no lo son, la validación de la conectividad y la replicación entre la máquina virtual y los nodos de Kubernetes fallan.

`memberConfig` Problemas

spec.memberConfig tiene menos entradas que spec.members. Agregue una entrada por nodo.
El operador de Kubernetes ignora el campo spec.memberConfig de nivel superior para clúster particionado.

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.

Problemas de nomenclatura

El nombre del recurso o el nombre del set de réplicas es demasiado largo, o no es un nombre válido según RFC 1123. Utilice spec.replicaSetNameOverride o --resource-name-override para proporcionar un nombre de Kubernetes válido.

Sorpresas de validación

Las validaciones pueden activarse mientras la anotación de ejecución en seco (mongodb.com/migration-dry-run) está establecida, no solo después de iniciar la migración real.
La validación del límite de nodos de votación puede aparecer en la conciliación, en lugar de en el momento de la admisión, si se aplica indirectamente un cambio que superaría el límite.
Agrupar demasiados cambios en una sola edición puede hacer que la implementación pierda el quórum. Realice solo un tipo de cambio a la vez: añadir nodos de Kubernetes, eliminar nodos externos o cambiar votos y prioridad.

Diagnósticos a recopilar

Si el problema persiste después de revisar las secciones anteriores, recopile lo siguiente antes de contactar con soporte:

El YAML del recurso MongoDB, incluido status.conditions:
```
kubectl get mdb <resource-name> -n <namespace> -o yaml
```
Los recursos MongoDBUser para la implementación.
Registros del Operador de Kubernetes.
Los registros del pod de la tarea del validador de conectividad.
El JSON de configuración de automatización de Ops Manager o Cloud Manager.

Luego, póngase en contacto con Soporte técnico.

Obtén más información

Volver

Comando de plugin migrate-to-mck

FAQ