Kubernetes Operator can migrate a deployment that Ops Manager or Cloud Manager manages on virtual machines or bare metal into Kubernetes. The migration is live and incremental. Your deployment keeps serving reads and writes throughout the process. You move members from the virtual machines to Kubernetes one at a time, using normal MongoDB replication.
Como funciona a migração
A migração depende da replicação padrão do MongoDB em vez de uma ferramenta de cópia de dados. Ele ocorre em três fases:
Estender. Você adiciona membros do Kubernetes ao conjunto de réplica existente. O Kubernetes Operator cria os novos membros como não votantes e executa uma sincronização inicial dos membros existentes.
Promover. Você transfere votos e prioridade dos membros da máquina virtual para os membros do Kubernetes. Os membros externos mantêm quaisquer votos e prioridade que já tenham na configuração de automação de origem até que você os remova.
Prune. Você remove os membros da máquina virtual um de cada vez, aguardando que o conjunto de réplicas atinja o estado da meta entre cada remoção.
A migração é concluída quando o Kubernetes Operator gerencia 100% dos membros, spec.externalMembers está vazio e todos os dados estão nas declarações de volume persistente do Kubernetes. Nesse ponto, nenhum membro permanece nas máquinas virtuais.
Por que a migração não usa restauração de snapshot ou Cluster-to-Cluster Sync
The migration workflow does not restore a snapshot and does not use mongosync or another cluster-to-cluster sync tool. Cluster-to-cluster sync tools impose downtime at cutover, lack support for time-series collections, and generally require field help to run safely. Replication-based migration avoids these limitations. Your deployment stays available, the migration supports the same collection types as the rest of your deployment, and you drive the process yourself with the kubectl mongodb plugin.
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.
A operação híbrida é transitória
Enquanto a migração está em andamento, seu sistema é executado em um estado híbrido com membros divisão entre máquinas virtuais e Kubernetes. O Kubernetes Operator suporta este estado híbrido apenas como uma condição transitória durante uma migração ativa. A migração requer conectividade de rede bidirecional permanente entre os dois ambientes durante o período. O Kubernetes Operator não suporta executar uma implementação de ambiente dividido indefinidamente.
O que a migração não faz
O Operador do Kubernetes não:
Desative as máquinas virtuais. Você mesmo os aposentou após a conclusão da migração.
Reverter uma migração. Não existe nenhuma maneira automatizada para reverter uma migração depois que ela começa.
Seed ou pré-copy data. Toda movimentação de dados acontece por meio da replicação do MongoDB .
Migrate Ops Manager or Cloud Manager itself. Only the MongoDB deployment moves into Kubernetes.