Migrar entre duas instâncias MCK

Este procedimento migrar uma implantação do MongoDB que uma instalação do Kubernetes operador gerencia para uma segunda instalação do Kubernetes operador, no mesmo projeto Ops Manager ou Cloud Manager. Use este procedimento ao mover uma implantação entre namespaces ou entre cluster do Kubernetes, em vez de máquinas virtuais para o Kubernetes pela primeira vez.

Nesta migração, a implantação de origem já é gerenciada pelo Kubernetes operador: a configuração de automação contém nomes de processo e nomes de host no estilo Kubernetes operador. O destino é uma segunda instalação do operador Kubernetes em outro namespace ou cluster.

Antes de começar

Confirme o seguinte antes de migrar uma implantação entre duas instalações do Kubernetes operador:

Uma MongoDB Ops Manager ou conexão do Cloud Manager ConfigMap com as chaves baseUrl, orgId e projectName.
Uma chave de API Secret com as chaves publicKey e privateKey.
O operador Kubernetes ServiceAccount tem batch/jobs permissões (create, get, list, watch e delete) para a tarefa de conectividade de executar.
O projeto contém exatamente uma implantação.

Você também precisa de:

Uma implantação de origem que é gerenciada por uma instalação do operador Kubernetes em execução.
Uma segunda instalação do operador Kubernetes que você deseja que se torne o destino, em um namespace ou cluster Kubernetes diferente da origem.
Ambas as instalações configuradas com o mesmo ConfigMap e credenciais de projeto do Ops Manager ou Cloud Manager.

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.externalMembers nã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.

Como isso difere de migrar de máquinas virtuais

Uma migração MCK para MCK usa o mesmo loop de estender, promover e podar que migrar uma implantação de máquina virtual. Os nós de origem aparecem como spec.externalMembers no recurso de destino, da mesma forma que fazem ao migrar de máquinas virtuais. Para obter os mecanismos detalhados passo a passo desse loop, consulte Migrar um conjunto de réplicas para o Kubernetes.

Esta migração tem requisitos adicionais que não se aplicam a uma migração de máquina virtual:

Pare ou reduza o escopo do operador de origem primeiro. Antes de começar, interrompa a instalação do Kubernetes operador de origem ou garanta que ele pare de reconciliar a implantação. Dois operadores nunca devem reconciliar o mesmo projeto MongoDB Ops Manager ou Cloud Manager ao mesmo tempo.
Ambos os operadores devem compartilhar o mesmo ConfigMap de projeto e credenciais. As instalações de origem e destino do Kubernetes operador se conectam ao mesmo projeto do Ops Manager ou Cloud Manager.
Os nomes dos recursos Helm com escopo de cluster não devem colidir. As duas instalações Helm do operador devem usar nomes distintos para qualquer recurso com escopo de cluster.
Os namespaces devem ser diferentes. Se as instalações de origem e destino compartilhassem um namespace, os nomes dos processos entrariam em conflito.

Migrar a implantação

Importante

Pare ou reduza o escopo do operador de origem antes de continuar. Consulte a seção anterior.

Siga a mesma sequência de estender, promover e podar descrita em Migrar um conjunto de réplicas para o Kubernetes, gerando o recurso personalizado do MongoDB de destino no namespace e cluster da instalação do operador do Kubernetes de destino. Os nós de origem aparecem em spec.externalMembers no recurso de destino até que você os remova.

Razão	Status	Significado
`Validating`	`True`	A anotação para executar o teste está definida.
`Extending`	`True`	A contagem de nós do Kubernetes desejada excede a última contagem reconciliada.
`Pruning`	`True`	A contagem de `externalMembers` caiu abaixo de `status.migrationObservedExternalMembersCount`.
`InProgress`	`True`	Nós externos existem, mas nada está mudando. Esta é também a razão na primeira reconciliação.
`MigrationComplete`	`False`	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.

Limpar a Origem

Após a conclusão da migração, exclua o recurso personalizado do MongoDB de origem. Não exclua o projeto MongoDB Ops Manager ou Cloud Manager e não exclua os dados subjacentes. Excluir o recurso personalizado de origem remove apenas o gerenciamento desse recurso pela instalação do Kubernetes operador de origem.

Saiba mais

Voltar

Cluster fragmentado

Interação com o MongoDB Search