Este procedimiento migra un clúster particionado gestionado por MongoDB Ops Manager o Cloud Manager a Kubernetes bajo el operador de Kubernetes, utilizando el mismo flujo de trabajo extend-promote-prune en vivo e incremental que Migrar un set de réplicas a Kubernetes. Siga ese procedimiento, aplicando las diferencias descritas en esta página. Cuando esta página no menciona un paso, funciona igual que el procedimiento del set de réplicas.
Importante
No se admiten los clústeres particionados con un servidor de configuración integrado. El operador de Kubernetes detecta esta topología y rechaza la importación.
Los nodos externos cubren todos los componentes
Para un clúster particionado, spec.externalMembers es una única lista plana que abarca todos los procesos: servidor de configuración mongods, los mongods de cada partición y los mongos enrutadores. Cada entrada establece spec.externalMembers[].type, y cada entrada mongod también establece spec.externalMembers[].replicaSetName para identificar si el proceso pertenece al set de réplicas del servidor de configuración o al set de réplicas de una partición específica. Para consultar la referencia completa del campo, consulte Configuración de recursos de migración de MongoDB.
Sobrescrituras de nombre conservan los nombres de las configuraciones de automatización
El plugin kubectl mongodb migrate-to-mck establece spec.configServerNameOverride y spec.shardNameOverrides para que el operador de Kubernetes extienda los set de réplicas de partición y servidor de configuración existentes en lugar de crear otros nuevos. El plugin también establece los recuentos de nodos del lado de Kubernetes en 0.
Extender uniformemente o por partición
Puedes extender un clúster particionado en Kubernetes de dos maneras:
Uniformemente, elevando los recuentos por componente
spec.mongodsPerShardCount,spec.configServerCount, yspec.mongosCount. Utilice esto cuando cada partición reciba el mismo número de nodos de Kubernetes.Para cada fragmento, utilice entradas
spec.shardOverridesque nombren el fragmento y establezcan su número de miembros. Utilice esta opción cuando los fragmentos tengan tamaños diferentes, cuando migre fragmento por fragmento o cuando un fragmento necesite su propia distribución de miembros.Nota
No confunda
spec.shardOverrides(configuración por partición) conspec.shardNameOverrides(nomenclatura del set de réplicas de configuración de automatización). Las dos configuraciones no están relacionadas.
Al igual que con el procedimiento del set de réplicas, guarde manualmente memberConfig para cada nuevo nodo de Kubernetes en el componente relevante antes de aumentar su recuento:
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, la siguiente configuración extiende una implementación fragmentada de un solo clúster. El ejemplo agrega un miembro de Kubernetes al servidor de configuración, uno a cada uno de los dos fragmentos y un enrutador mongos. Configure votes: 0 y priority: "0" mientras los nuevos miembros completan la sincronización inicial y, a continuación, promuévalos con los valores que se muestran:
spec: configServerCount: 1 memberConfig: - votes: 1 priority: "10" shardOverrides: - shardNames: ["myclustershard-0"] members: 1 memberConfig: - votes: 1 priority: "10" - shardNames: ["myclustershard-1"] members: 1 memberConfig: - votes: 1 priority: "10" mongosCount: 1En una implementación de clúster único, el nivel superior spec.memberConfig configura los miembros del servidor de configuración. La misma configuración se aplica a los miembros de cada fragmento sin una entrada spec.shardOverrides coincidente. Los enrutadores mongos no son miembros del conjunto de réplicas y no toman memberConfig.
Certificados TLS por componente
Emita un certificado por componente, utilizando el patrón de nomenclatura para cada uno: <name>-config-* para el servidor de configuración, <name>-<i>-* para cada partición y <name>-mongos-* para los mongos routers.
Extender y podar los componentes uno a uno
No hay un orden obligatorio para ampliar o reducir el servidor de configuración, las particiones o los enrutadores mongos. Extienda o recorte exactamente un componente a la vez, y espere a que se alcance el estado objetivo antes de pasar al siguiente componente o a la siguiente entrada.
Condiciones del estado y verificación
Las condiciones y motivos de estado funcionan igual que para un set de réplicas, calculados a partir de un total de nodos que tienen en cuenta las anulaciones en todos los componentes. kubectl wait --for=condition=Migrating=False es válido para una migración de clúster particionado.
Verifique la migración a través de un Pod mongos, no un nodo de partición.