Este procedimento migra qualquer conjunto de réplicas que o Ops Manager ou o Cloud Manager gerencia para o Kubernetes sob o operador Kubernetes, usando a replicação normal do MongoDB. Isso inclui implantações executadas em máquinas virtuais ou bare metal, e implantações já gerenciadas por uma instância diferente do operador do Kubernetes. A migração é ao vivo e incremental: você estende o conjunto de réplicas para o Kubernetes, promove os nós do Kubernetes e, em seguida, remove os nós externos. Não há restaurar de snapshot e nenhum mongosync envolvido.
Antes de começar
Confirme o seguinte antes de migrar um conjunto de réplicas:
Uma MongoDB Ops Manager ou conexão do Cloud Manager
ConfigMapcom as chavesbaseUrl,orgIdeprojectName.Uma chave de API
Secretcom as chavespublicKeyeprivateKey.O operador Kubernetes
ServiceAccounttembatch/jobspermissões (create,get,list,watchedelete) para a tarefa de conectividade de executar.O projeto contém exatamente uma implantação.
Você também precisa de:
Um conjunto de réplicas existente que o MongoDB Ops Manager ou o Cloud Manager gerencia.
Exatamente uma implantação no projeto MongoDB Ops Manager ou Cloud Manager.
Um cluster Kubernetes com o operador Kubernetes instalado.
O plugin
kubectl mongodbem uma versão que corresponda ao operador Kubernetes. O Operador Kubernetes força essa correspondência em cada reconciliação, incluindo executar a seco.Conectividade de rede bidirecional e resolução de nome de host entre os hosts de máquina virtual e os Pods do Kubernetes.
Certificados TLS pré-configurados que cobrem todos os SANs, se a implantação usar TLS.
As senhas de usuário SCRAM em mãos. Você não pode recuperá-las da configuração de automação.
Um backup feito antes de começar.
Uma implantação que está saudável e no estado desejado.
Mantenha pelo menos 3 nós votantes sempre. O Operador Kubernetes rejeita mais de 7 membros votantes. Se você exceder 7, adicione nós Kubernetes não votantes ou remova nós externos votantes.
Faça apenas um tipo de alteração por vez: adicione nós do Kubernetes, remova nós externos ou altere os votos e a prioridade de apenas um nó por vez. A validação de admissão rejeita alterações mistas assim que a migração é iniciada e também rejeita remover nós do Kubernetes ou a adição de nós externos durante a migração.
Aja apenas quando a implantação estiver no estado final.
Migre o primário por último. Transferir votos e prioridade para um nó pode trigger uma eleição, e as gravações podem falhar brevemente enquanto o conjunto de réplicas elege um novo primário. Migrar o primário por último evita acionar essa eleição e o tempo de inatividade de gravar que ela causa, até a etapa final.
Observação
Você também pode trigger uma reeleição aumentando a prioridade de um nó no Kubernetes.
Enquanto
spec.externalMembersnão estiver vazio, o operador Kubernetes força o dimensionamento de um nó por vez. Por isso, cada alteração precisa de sua própria espera para o estado final.
Procedimento
Gerar o recurso personalizado do MongoDB.
Execute o 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.yamlInspecione o arquivo gerado. Ele contém:
spec.externalMembers, listando os processos de origem.spec.membersdefinido como0.A anotação
mongodb.com/migration-dry-run: true, que o plugin sempre adiciona.
O comando também oferece suporte a estes sinalizadores opcionais:
--certs-secret-prefix: obrigatório quando o TLS está habilitado. Definespec.security.certsSecretPrefix.--prometheus-secret-name: use quando o Prometheus estiver habilitado. OSecretjá deve existir e ter uma chavepassword.--resource-name-override: configurametadata.nameno recurso gerado. O plugin normaliza automaticamente o nome do conjunto de réplicas quando não é um nome válido do Kubernetes e definespec.replicaSetNameOverridepara você.
Gere os recursos personalizados MongoDBUser.
Conclua esta etapa apenas se você quiser migrar seus usuários de banco de dados. A migração não exige isso.
Pré-crie um Secret por usuário SCRAM, cada um com uma chave password. Executar:
kubectl mongodb migrate-to-mck users \ --config-map-name <configmap> \ --secret-name <secret> \ --namespace <namespace> \ --users-secrets-file users.csv \ -o users-cr.yamlO arquivo CSV mapeia usuários para Segredos, um por linha, no formato username:database,secret-name. Omita --users-secrets-file para ser solicitado para cada usuário.
O plugin gera usuários X.509 e LDAP no banco de dados $external. Ele ignora o usuário do agente de automação.
Se a implantação usar TLS, emita os certificados de nó do Kubernetes.
Emita os certificados de nó do Kubernetes da mesma autoridade de certificação que assinou os certificados da máquina virtual.
O Operador Kubernetes espera um kubernetes.io/tls Secret chamado <certsSecretPrefix>-<resourceName>-cert e um CA ConfigMap chamado <resourceName>-ca que contém tanto uma chave ca-pem quanto uma chave mms-ca.crt. Os certificados precisam de SANs que cubram os nomes DNS por Pod e por Serviço, e os usos de autenticação de servidor e cliente.
Se a implantação de origem não usar TLS, defina net.tls.mode como disabled no MongoDB Ops Manager ou Cloud Manager, na implantação de máquina virtual existente, antes de migrar. Você não precisa definir nada no recurso personalizado do MongoDB para este caso.
Observação
Uma incompatibilidade de CA é detectada pelo executar a seco na próxima etapa, por design.
Configure o acesso externo.
Antes de executar o teste, configure spec.externalAccess para que os nós da máquina virtual possam acessar os Pods do Kubernetes. Para permitir que esses nós resolvam os Pods por nome de host, você também pode definir spec.externalAccess.externalDomain. Para aprender mais sobre os campos envolvidos e os requisitos de DNS, consulte Requisitos de rede para migração.
Esta configuração é de propriedade do usuário: você configura os LoadBalancers ou NodePorts e os registros DNS para o seu ambiente.
Importante
Não defina externalDomain se você usar o MongoDB Search ou a pesquisa vetorial com esta implantação. MongoDBSearch não oferece suporte a um recurso MongoDB que define externalDomain, e você não pode remover o campo depois de criar o cluster. Para aprender mais, consulte Interação do MongoDB Search com a migração.
Execute a simulação e verifique a conectividade.
Aplique o recurso gerado com a anotação mongodb.com/migration-dry-run ainda presente. Enquanto a anotação estiver definida, o Kubernetes operador não faz alterações na configuração de automação e apenas valida a conectividade.
O Kubernetes operador cria uma tarefa chamada <resourceName>-connectivity-check, que conecta cada nó externo e autentica. A tarefa se exclui usando ttlSecondsAfterFinished, e a próxima reconciliação a recria, portanto, a revalidação é automática. Você pode corrigir problemas no Kubernetes ou na IU do MongoDB Ops Manager e executar novamente livremente.
A simulação verifica a acessibilidade de Kubernetes para máquina virtual (DNS, TLS, firewall e endereços de nós) e credenciais, incluindo a função __system no banco de dados local e a CA quando o TLS está habilitado. Ele não verifica a conectividade de entrada de máquina virtual para Kubernetes.
Como essa direção depende inteiramente do seu configurar de rede, nenhum comando único pode oferecer garantias. Em vez disso, siga esta lista de verificação:
Confirme se os nomes de host que os nós do Kubernetes terão, seguindo o padrão
<metadata.name>-0.<spec.externalAccess.externalDomain>, são resolúveis a partir dos nós da máquina virtual.Confirme se os IPs do nó do Kubernetes ou do LoadBalancer podem ser acessados a partir das máquinas virtuais.
Ler o resultado de status.conditions[type=NetworkConnectivityVerified]:
Código de saída da tarefa do validador | Status da Condição | Razão | Significado |
|---|---|---|---|
Tarefa ainda em execução |
|
| O |
|
|
| Todos os nós externos são acessíveis e autenticados. |
|
|
| Credenciais, o mecanismo de autenticação ou uma função |
|
|
| DNS, TLS, timeouts ou nós inacessíveis. Verifique os log do Pod da tarefa. |
|
|
| Falha não classificada. Verifique o log do Pod de tarefa. |
Falhas que ocorrem antes do início da tarefa usam os motivos OperatorImageUnknown, BuildStatefulSetOptions, AgentCertSecretFailed e AgentCertSubject.
O Kubernetes operador remove a condição NetworkConnectivityVerified de status.conditions inteiramente assim que não restarem mais nós externos.
Estenda o conjunto de réplicas para o Kubernetes.
Remova a anotação dry-run:
kubectl annotate mdb <resourceName> \ mongodb.com/migration-dry-run-Este é o ponto em que o Kubernetes operador assume a propriedade do projeto MongoDB Ops Manager.
Aumente spec.members e gravar manualmente spec.memberConfig juntos.
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, para adicionar três nós do Kubernetes como não votantes:
spec: memberConfig: - votes: 0 priority: "0" - votes: 0 priority: "0" - votes: 0 priority: "0"Aguarde a sincronização inicial completa e o estado desejado. Se você gerou recursos MongoDBUser na etapa opcional acima, aplique-os agora e confirme se cada um atinge um status.phase de Updated.
Promova os nós do Kubernetes.
Transfira os votos e a prioridade para os nós do Kubernetes editando spec.memberConfig. votes é um número inteiro. priority é uma string que contém um float.
Os nós externos mantêm os votos e a prioridade que possuem na configuração de automação de origem. spec.externalMembers não tem nenhum campo votes ou priority.
Aguarde o estado desejado.
Podar os nós externos.
Importante
Remova apenas uma entrada de spec.externalMembers por vez. Aguarde o estado final após cada remoção antes de remover a próxima entrada.
Por exemplo:
kubectl patch mdb <resourceName> --type=json \ -p='[{"op":"remove","path":"/spec/externalMembers/0"}]'Você pode remover entradas, mas nunca adicioná-las depois que a migração começar.
Assista status.conditions[type=Migrating].reason passar por Extending, InProgress e Pruning:
Razão | Status | Significado |
|---|---|---|
|
| A anotação para executar o teste está definida. |
|
| A contagem de nós do Kubernetes desejada excede a última contagem reconciliada. |
|
| A contagem de |
|
| Nós externos existem, mas nada está mudando. Esta é também a razão na primeira reconciliação. |
|
| Todos os nós externos foram removidos. |
A precedência é Validating > Extending > Pruning > InProgress. Uma operação de limpeza que também afeta o lado do Kubernetes relata Extending, o que é outro motivo para fazer uma alteração por vez.
Não é permitido realizar poda e extensão ao mesmo tempo.
Para criar um script para a conclusão da migração, use kubectl wait --for=condition=Migrating=False em vez de fazer polling em status.phase.
Verifique e conclua.
A migração será concluída quando spec.externalMembers estiver vazia, a condição Migrating for False com o motivo MigrationComplete e todos os dados residirem em declarações de volume persistente:
kubectl wait --for=condition=Migrating=False mdb/<resourceName>Atualize as strings de conexão do seu aplicativo e desative as máquinas virtuais. O operador do Kubernetes não desativa as máquinas virtuais para você.
Segredo da string de conexão
O operador Kubernetes gera automaticamente uma string de conexão Secret que não contém credenciais, chamada <metadata.name>-cluster-connection-string, e a mantém em sincronização com os nós ativos. Direcione seus aplicativos para este Secret em vez de codificar diretamente uma string de conexão.
Disponibilidade durante a migração
As leituras continuam disponíveis ao longo da migração. As gravações podem falhar brevemente durante as eleições; portanto, seus drivers devem usar gravações repetíveis. A latência de leitura pode aumentar se um destino de leitura se mover, portanto, execute o cluster Kubernetes na mesma região que as máquinas virtuais. Cursores de longa duração em um secundário migrado quebram porque não há modo de hibernação.