Este procedimento migra um cluster que o Ops Manager ou o Cloud Manager gerencia para o Kubernetes sob o Kubernetes operador, usando o mesmo fluxo de trabalho ativo e incremental de estender-promover-podar que Migrar um conjunto de réplicas para o Kubernetes. Siga esse procedimento, aplicando as diferenças descritas nesta página. Onde esta página não menciona uma etapa, ela funciona da mesma forma que o procedimento de conjunto de réplicas.
Importante
Clusters com um servidor de configuração incorporado não são suportadas. O operador Kubernetes detecta esta topologia e rejeita a importação.
Os nós externos cobrem todos os componentes
Para um cluster, spec.externalMembers é uma lista única e plana que cobre todos os processos: mongods do servidor de configuração, mongods de cada shard e os roteadores mongos. Cada entrada define spec.externalMembers[].type, e cada entrada mongod também define spec.externalMembers[].replicaSetName para identificar se o processo pertence ao conjunto de réplicas do servidor de configuração ou ao conjunto de réplicas de um shard específico. Para a referência completa do campo, consulte Configurações de recurso de migração do MongoDB.
As substituições de nomes preservam os nomes da configuração de automação
O plugin kubectl mongodb migrate-to-mck define spec.configServerNameOverride e spec.shardNameOverrides para que o operador Kubernetes estenda o servidor de configuração existente e os conjuntos de réplicas de shard em vez de criar novos. O plugin também define as contagens de nós no Kubernetes para 0.
Estender uniformemente ou por shard
Você pode estender um cluster sharded para o Kubernetes de duas maneiras:
Uniformemente, aumentando as contagens por componente
spec.mongodsPerShardCount,spec.configServerCountespec.mongosCount. Use isso quando cada shard receber o mesmo número de nós do Kubernetes.Por shard, usando entradas
spec.shardOverridesque nomeiam o shard e definem sua contagem de membros. Use isso quando os shards tiverem tamanhos diferentes, quando você migrar shard por shard ou quando um shard precisar de seu próprio layout de membro.Observação
Não confunda
spec.shardOverrides(configuração por shard) comspec.shardNameOverrides(nomenclatura do conjunto de réplicas de configuração de automação). As duas configurações não estão relacionadas.
Assim como no procedimento de conjunto de réplicas, gravar manualmente memberConfig para cada novo nó do Kubernetes no componente relevante antes de aumentar sua contagem:
Aviso
Defina spec.memberConfig antes de aumentar o número de nós
Por padrão, novos nós do Kubernetes entram como nós votantes. O padrão do CRD é votes: 1 e priority: "1", que permite que um nó ainda em sincronização participe de uma eleição antes de concluir sua sincronização inicial.
O MongoDB recomenda que você grave uma entrada spec.memberConfig por novo nó do Kubernetes com votes: 0 e priority: "0" antes de aumentar a contagem de nós, para que um nó ainda em sincronização não possa vencer uma eleição. votes é um número inteiro. priority é uma string.
Por exemplo, a configuração a seguir estende uma implantação fragmentada de cluster único. O exemplo adiciona um nó do Kubernetes ao servidor de configuração, um a cada um de dois shards e um roteador mongos. Defina votes: 0 e priority: "0" enquanto os novos membros concluem a sincronização inicial e, em seguida, promova-os com os valores mostrados:
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: 1Em um sistema de cluster único, o spec.memberConfig de nível superior configura os membros do servidor de configuração . A mesma configuração se aplica aos membros de cada shard sem uma entrada spec.shardOverrides correspondente. Os roteadores mongos não são membros do conjunto de réplicas e não aceitam memberConfig.
Certificados TLS por componente
Emita um certificado por componente, usando o padrão de nomenclatura para cada um: <name>-config-* para o servidor de configuração, <name>-<i>-* para cada shard e <name>-mongos-* para os mongos roteadores.
Estender e podar um componente por vez
Não há uma ordem obrigatória para expandir ou reduzir o servidor de configuração, os shards ou os mongos routers. Estenda ou reduza exatamente um componente por vez e aguarde o estado desejado antes de passar para o próximo componente ou para a próxima entrada.
Condições de status e verificação
As condições de status e os motivos funcionam da mesma forma que para um conjunto de réplicas, calculados a partir de um total de nós com reconhecimento de sobreposições em todos os componentes. kubectl wait --for=condition=Migrating=False é válido para uma migração de cluster sharded.
Verifique a migração através de um Pod mongos, não um nó de shard.