Este procedimento migra uma implantação do MongoDB que uma instalação do Kubernetes Operator gerencia para uma segunda instalação do Kubernetes Operator, no mesmo projeto do Ops Manager ou do Cloud Manager . Use esse procedimento ao mover uma implantação entre namespaces ou clusters do Kubernetes, em vez de de máquinas virtuais para o Kubernetes pela primeira vez.
Nesta migração, o sistema de origem já é gerenciado pelo Kubernetes Operator: a configuração de automação contém nomes de processo e nomes de host no estilo do Kubernetes Operator. O alvo é uma segunda instalação do Kubernetes Operator em outro namespace ou cluster.
Antes de começar
Confirme o seguinte antes de migrar uma implantação entre duas instalações do Kubernetes Operator:
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.O projeto contém exatamente uma implantação.
Você também precisa de:
Um sistema de origem que uma instalação do Kubernetes Operator em execução gerencia.
Uma segunda instalação do Kubernetes Operator que você deseja se tornar o destino, em um namespace ou cluster do Kubernetes diferente da origem.
Ambas as instalações configuradas no mesmo ConfigMap e credenciais do projeto do Ops Manager ou Cloud Manager .
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.
Como isso difere da migração de máquinas virtuais
Uma migração de MCK para MCK usa o mesmo loop de extensão, promoção e podação que a migração de um sistema de máquina virtual. Os membros de origem aparecem como spec.externalMembers no recurso de destino, o mesmo que aparecem ao migrar de máquinas virtuais. Para obter a mecânica passo a passo detalhada desse loop, consulte Migrar um conjunto de réplicas para o Kubernetes.
Essa migração tem requisitos adicionais que não se aplicam a uma migração de máquina virtual:
Interrompa ou faça o escopo do operador de origem primeiro. Antes de começar, interrompa a instalação do Kubernetes Operator de origem ou certifique-se de que ele pare de reconciliar a implantação. Dois operadores nunca devem reconciliar o mesmo projeto do Ops Manager ou do Cloud Manager ao mesmo tempo.
Ambos os operadores devem compartilhar o mesmo projeto ConfigMap e credenciais. As instalações de origem e destino do Kubernetes Operator se conectam ao mesmo projeto do Ops Manager ou do Cloud Manager .
Os nomes de recursos Helm com escopo de cluster não devem coincidir. As instalações do Helm de dois operadores devem usar nomes distintos para qualquer recurso com escopo de cluster.
Os namespaces devem ser diferentes. Se as instalações de origem e de destino compartilhassem um namespace, os nomes de processo colidiriam.
Migrar a implantação
Importante
Pare ou faça o escopo do operador de origem antes de continuar. Consulte a seção anterior.
Siga a mesma sequência de extensão, promoção e remoção 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 Kubernetes Operator de destino. Os membros de origem aparecem em spec.externalMembers no recurso de destino até que você os remova.
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.
Limpe a fonte
Após a conclusão da migração, exclua o recurso personalizado de origem do MongoDB . Não exclua o projeto do Ops Manager ou do Cloud Manager e não exclua os dados subjacentes. A exclusão do recurso personalizado de origem remove apenas o gerenciamento da instalação do Kubernetes Operator desse recurso.