Este procedimento migra qualquer conjunto de réplicas que o Ops Manager ou o Cloud Manager gerenciam para o Kubernetes no Kubernetes Operator, usando a replicação normal do MongoDB . Isso inclui implantações executadas em máquinas virtuais ou peering e implantações já gerenciadas por uma instância diferente do Kubernetes Operator. A migração é ativa e incremental: você estende o conjunto de réplicas para o Kubernetes, promover os membros do Kubernetes e podar os membros externos. Não há restauração de snapshot e nenhum mongosync envolvido.
Antes de começar
Confirme o seguinte antes de migrar um conjunto de réplicas:
Uma conexão do Ops Manager ou 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 o trabalho de conectividade de execução seca.The project contains exactly one deployment.
Você também precisa de:
Um conjunto de réplicas existente que o Ops Manager ou o Cloud Manager gerencia.
Exatamente um sistema no projeto do Ops Manager ou Cloud Manager .
Um cluster Kubernetes com o Kubernetes Operator instalado.
O plugin-in
kubectl mongodbem uma versão que corresponda ao Kubernetes Operator. O Kubernetes Operator impõe essa correspondência em cada reconciliação, incluindo na execução seca.Conectividade de rede bidirecional e resolução de nome de host entre os hosts da máquina virtual e os Pods do Kubernetes.
Certificados TLS pré-configurados que abrangem todos os SANs, se o sistema utilizar TLS.
As senhas de usuário SCRAM em mãos. Você não pode recuperá-los da configuração de automação.
A backup taken before you start.
A deployment that is healthy and at goal state.
Mantenha pelo menos 3 membros votantes o tempo todo. O Kubernetes Operator rejeita mais de 7 membros votantes. Se você exceder 7, adicione membros do Kubernetes sem direito a voto ou remova membros externos com direito a voto.
Faça apenas um tipo de alteração de cada vez: adicionar membros do Kubernetes, remover membros externos ou alterar os votos e a prioridade de apenas um membro de cada vez. A validação de entrada rejeita alterações mistas após o início da migração e também rejeita a remoção de membros do Kubernetes ou a adição de membros externos no meio da migração.
Aja somente quando a implantação estiver no estado da meta.
Migre o primário por último. Transferir votos e prioridade para um membro pode desencadear uma eleição, e as gravações podem falhar brevemente enquanto o conjunto de réplicas elege uma nova primária. A migração do primário evita acionar essa eleição e o tempo de inatividade de gravação que ela causa até a etapa final.
Observação
Você também pode desencadear uma reeleição aumentando a prioridade de um membro no Kubernetes.
Enquanto o
spec.externalMembersnão está vazio, o Kubernetes Operator força o dimensionamento de um membro por vez. É por isso que cada mudança precisa de sua própria espera pelo estado do objetivo.
Procedimento
Gere o recurso personalizado 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.yaml
Inspecione o arquivo gerado. 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 suporta estes sinalizadores opcionais:
--certs-secret-prefix: necessário quando o TLS está habilitado. Definespec.security.certsSecretPrefix.--prometheus-secret-name: use quando Prometeus estiver habilitado. OSecretjá deve existir e ter uma chavepassword.--resource-name-override: definemetadata.nameno recurso gerado. O plugin-in normaliza o nome do conjunto de réplicas automaticamente quando não é um nome válido do Kubernetes e definespec.replicaSetNameOverridepara você.
Gere os recursos personalizados MongoDBUser.
Conclua esta etapa somente se quiser migrar seus usuários do 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.yaml
O arquivo CSV mapeia os usuários para Segredos, um por linha, no formato username:database,secret-name. Omita --users-secrets-file a 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 o sistema utilizar TLS, emita os certificados de membro do Kubernetes.
Emita os certificados de membro do Kubernetes da mesma autoridade de certificação que assinou os certificados da máquina virtual.
O Kubernetes Operator espera um kubernetes.io/tls Secret denominado <certsSecretPrefix>-<resourceName>-cert e um CA ConfigMap denominado <resourceName>-ca que contenha uma chave ca-pem e uma chave mms-ca.crt. Os certificados precisam de SANs que abranjam os nomes DNS por Pod e de Serviço, e os usos de autenticação do servidor e do cliente .
Se o sistema de origem não usar TLS, defina net.tls.mode como disabled no Ops Manager ou no Cloud Manager, no sistema 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 pela execução seca na próxima etapa, por design.
Configurar acesso externo.
Antes de executar a execução seca, configure o spec.externalAccess para que os membros da máquina virtual possam alcançar os Pods do Kubernetes. Para permitir que esses membros resolvam os Pods por nome de host, você também pode definir spec.externalAccess.externalDomain. Para saber 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 seu ambiente.
Importante
Não defina externalDomain se você usar o MongoDB Search ou o Vector Search com esse sistema. MongoDBSearch não suporta um recurso MongoDB que define externalDomain, e você não pode remover o campo depois de criar o cluster. Para saber mais, consulte Interação de pesquisa do MongoDB com migração.
Execute a execução seca 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 Operator não faz alterações na configuração de automação e apenas valida a conectividade.
O Kubernetes Operator cria um trabalho chamado <resourceName>-connectivity-check, que disca para cada membro externo e autentica. O Trabalho se exclui usando ttlSecondsAfterFinished e a próxima reconciliação o recria, portanto a revalidação é automática. Você pode corrigir problemas no Kubernetes ou na interface do usuário do Ops Manager e executar novamente livremente.
A execução seca verifica a acessabilidade do Kubernetes-to-virtual-machine (DNS, TLS, firewalls e endereços de membros) e as credenciais, incluindo a função __system no banco de dadoslocal, e a CA quando o TLS está habilitado. Ele não verifica a conectividade de entrada da máquina virtual para o Kubernetes.
Como essa direção depende inteiramente da sua configuração de rede, nenhum comando único pode garantir isso. Em vez disso, trabalhe com esta lista de verificação:
Confirme que os nomes de host que os membros do Kubernetes terão, seguindo o padrão
<metadata.name>-0.<spec.externalAccess.externalDomain>, podem ser resolvidos a partir dos membros da máquina virtual.Confirme se o nó do Kubernetes ou os IPs do LoadBalancer podem ser acessados a partir das máquinas virtuais.
Leia o resultado de status.conditions[type=NetworkConnectivityVerified]:
Código de saída do trabalho do validador | Status da condição | Razão | Significado |
|---|---|---|---|
A tarefa ainda está em execução |
|
| O |
|
|
| Todos os membros externos são acessíveis e autenticados. |
|
|
| Credenciais, o mecanismo de autenticação ou uma função |
|
|
| DNS, TLS, tempos limite ou membros inacessíveis. Verifique os registros do pod de trabalho. |
|
|
| Falha não classificada. Verifique os registros do pod de trabalho. |
As falhas que ocorrem antes do início do Trabalho usam os motivos OperatorImageUnknown, BuildStatefulSetOptions, AgentCertSecretFailed e AgentCertSubject.
O Kubernetes Operator remove a condição NetworkConnectivityVerified de status.conditions totalmente quando nenhum membro externo permanecer.
Estenda o conjunto de réplicas para Kubernetes.
Remova a anotação de execução seca:
kubectl annotate mdb <resourceName> \ mongodb.com/migration-dry-run-
Este é o ponto em que o Kubernetes Operator assume a propriedade do projeto Ops Manager .
Aumente spec.members e escreva spec.memberConfig manualmente.
Aviso
Definir spec.memberConfig antes de aumentar a contagem de membros
Por padrão, novos membros do Kubernetes ingressam como membros votantes. Os padrões do CRD são votes: 1 e priority: "1", que permitem que um membro ainda em sincronização participam de uma eleição antes de concluir sua sincronização inicial.
O MongoDB recomenda que você escreva uma entrada spec.memberConfig por novo membro do Kubernetes com votes: 0 e priority: "0" antes de aumentar a contagem de membros, para que um membro 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 membros 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 da meta. Se você gerou recursos MongoDBUser na etapa opcional acima, aplique-os agora e confirme se cada um deles atinge um status.phase de Updated.
Promova os membros do Kubernetes.
Desloque votos e prioridade para os membros do Kubernetes editando spec.memberConfig. votes é um número inteiro. priority é uma string contendo um float.
Os membros externos mantêm quaisquer votos e prioridade que carregam na configuração de automação de origem. spec.externalMembers não tem o campovotes ou priority.
Aguarde o estado do objetivo.
Remova os membros externos.
Importante
Remova somente uma entrada de spec.externalMembers de cada vez. Aguarde o estado da meta 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 após o início da migração.
Veja status.conditions[type=Migrating].reason passar por Extending, InProgress e Pruning:
Razão | Status | Significado |
|---|---|---|
|
| A anotação de execução seca está definida. |
|
| A contagem de membros do Kubernetes desejado excede a última contagem reconciliada. |
|
| A contagem de |
|
| Existem membros externos, mas nada está mudando. Esta também é a razão da primeira reconciliação. |
|
| Todos os membros externos foram removidos. |
A precedência é Validating > Extending > Pruning > InProgress. Uma podar que também cresce os relatórios do lado do Kubernetes Extending, que é outro motivo para fazer uma alteração de cada vez.
Poda e extensão não são permitidos ao mesmo tempo.
Para fazer o script contra a conclusão da migração, use kubectl wait --for=condition=Migrating=False em vez de pesquisar status.phase.
Verifique e finalize.
A migração é concluída quando spec.externalMembers está vazio, a condição Migrating é False com a razão MigrationComplete e todos os dados residem em declarações de volume persistentes:
kubectl wait --for=condition=Migrating=False mdb/<resourceName>
Atualize as connection strings do seu aplicação e desative as máquinas virtuais. O Kubernetes Operator não desativa as máquinas virtuais para você.
Segredo da connection string
O Kubernetes Operator gera automaticamente uma string de conexão Secret sem credenciais, chamada <metadata.name>-cluster-connection-string, e a mantém sincronizada com os nós ativos. Aponte seus aplicativos para este Secret em vez de codificar uma string de conexão.
Disponibilidade durante a migração
As leituras permanecem disponíveis durante a 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 relação a uma quebra secundária migrada, pois não há modo quiesce.