Este procedimiento migra una implementación de MongoDB administrada por una instalación de Kubernetes Operator a una segunda instalación de Kubernetes Operator, en el mismo proyecto de Ops Manager o Cloud Manager. Utilice este procedimiento cuando mueva una implementación entre espacios de nombres o clústeres de Kubernetes, en lugar de hacerlo desde máquinas virtuales a Kubernetes por primera vez.
En esta migración, el despliegue de origen ya está gestionado por Kubernetes Operator: la configuración de automatización contiene nombres de procesos y nombres de host al estilo de Kubernetes Operator. El destino es una segunda instalación de Kubernetes Operator en otro espacio de nombres o clúster.
Antes de comenzar
Confirme lo siguiente antes de migrar una implementación entre dos instalaciones de Kubernetes Operator:
A Ops Manager or Cloud Manager connection
ConfigMapwith the keysbaseUrl,orgId, andprojectName.An API key
Secretwith the keyspublicKeyandprivateKey.The Kubernetes Operator
ServiceAccounthasbatch/jobspermissions (create,get,list,watch, anddelete) for the dry-run connectivity Job.El proyecto contiene exactamente un despliegue.
También necesitas:
Un despliegue de origen gestionado por una instalación en ejecución de Kubernetes Operator.
Una segunda instalación de Kubernetes Operator que desee que se convierta en el destino, en un espacio de nombres o clúster de Kubernetes diferente al de origen.
Ambas instalaciones están configuradas con el mismo ConfigMap y las mismas credenciales del proyecto de Ops Manager o Cloud Manager.
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.
While
spec.externalMembersis non-empty, Kubernetes Operator forces one-member-at-a-time scaling. This is why each change needs its own wait for goal state.
En qué se diferencia esto de la migración desde máquinas virtuales.
Una migración de MCK a MCK utiliza el mismo ciclo de extensión, promoción y poda que la migración de una implementación de máquina virtual. Los miembros de origen aparecen como spec.externalMembers en el recurso de destino, al igual que cuando se migra desde máquinas virtuales. Para obtener información detallada sobre el funcionamiento de este ciclo, consulte Migrar un conjunto de réplicas a Kubernetes.
Esta migración tiene requisitos adicionales que no se aplican a una migración de máquina virtual:
Primero, detenga o limite el alcance del operador de origen. Antes de comenzar, detenga la instalación del operador de Kubernetes de origen o asegúrese de que deje de conciliar la implementación. Dos operadores nunca deben conciliar el mismo proyecto de Ops Manager o Cloud Manager simultáneamente.
Ambos operadores deben compartir el mismo ConfigMap del proyecto y las mismas credenciales. Las instalaciones del operador de Kubernetes de origen y destino se conectan al mismo proyecto de Ops Manager o Cloud Manager.
Los nombres de los recursos de Helm con ámbito de clúster no deben coincidir. Las dos instalaciones de Helm de los operadores deben usar nombres distintos para cualquier recurso con ámbito de clúster.
Los espacios de nombres deben ser diferentes. Si las instalaciones de origen y destino compartieran un espacio de nombres, los nombres de los procesos entrarían en conflicto.
Migrar el despliegue
Importante
Deténgase o reduzca el alcance del operador de origen antes de continuar. Consulte la sección anterior.
Siga la misma secuencia de extensión, promoción y poda descrita en Migrar un conjunto de réplicas a Kubernetes, generando el recurso personalizado de MongoDB de destino en el espacio de nombres y el clúster de la instalación del operador de Kubernetes de destino. Los miembros de origen aparecen en spec.externalMembers en el recurso de destino hasta que los elimine.
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.
Limpiar la fuente
Una vez finalizada la migración, elimine el recurso personalizado de MongoDB de origen. No elimine el proyecto de Ops Manager ni el de Cloud Manager, ni los datos subyacentes. Al eliminar el recurso personalizado de origen, solo se elimina la gestión de dicho recurso por parte de la instalación de Kubernetes Operator de origen.