Migrar uma implantação gerenciada pelo Ops Manager ou pelo Cloud Manager em máquinas virtuais para o Kubernetes sob o Kubernetes operador requer conectividade de rede bidirecional entre os hospedar de máquinas virtuais e os Pods do Kubernetes. Você, e não o Kubernetes operador, faz o provisionamento dessa conectividade.
Esta conectividade depende totalmente de sua própria configurar de rede, incluindo sua topologia de rede, regras de firewall, configuração de DNS e provedor de nuvem. Por causa disso, não é possível uma orientação universal concreta. O restante desta página descreve o que o Kubernetes operador verifica automaticamente, o que ele não verifica e a configuração que você usa para expor Kubernetes Pods às suas máquinas virtuais.
O que o Dry Run valida
A tarefa de validação de conectividade de simulação de executar verifica se os nós da máquina virtual estão acessíveis a partir do ambiente Kubernetes. Isso não verifica a direção inversa, das máquinas virtuais para o Kubernetes. Você deve verificar essa direção você mesmo, usando a lista de verificação de configurar mais adiante nesta página.
Configurar Acesso Externo
Para permitir que os nós da máquina virtual alcancem os Pods do Kubernetes, use spec.externalAccess. Este é o mesmo mecanismo de acesso externo que o operador Kubernetes usa fora da migração: ele cria um LoadBalancer ou NodePort para cada Pod, expondo os Pods fora do cluster Kubernetes.
Opcionalmente, defina spec.externalAccess.externalDomain como um nome de host que os nós da máquina virtual possam resolver. Você é responsável por configurar DNS para este nome de host; o Kubernetes operador não cria nem gerencia registros de DNS para você.
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. Em vez disso, use spec.externalAccess por conta própria. Para aprender mais, consulte Interação do MongoDB Search com a migração.
Aviso
Você não pode remover externalDomain depois de criar o cluster. Confirme seu hostname e estratégia de DNS antes de definir este campo.
Os nomes de host dos nós do Kubernetes seguem o padrão <metadata.name>-0.<spec.externalAccess.externalDomain>, onde o índice numérico aumenta em um para cada nó adicional.
Lista de verificação de verificação
Nenhum comando único pode oferecer garantias de que a conectividade esteja configurada corretamente em ambas as direções. Use esta lista de verificação para revisar configurar e adapte cada item à sua própria rede:
Confirme que os nomes de host dos seus nós do Kubernetes são resolúveis a partir dos nós da máquina virtual.
Confirme que os endereços IP do nó do Kubernetes ou do LoadBalancer são acessíveis a partir das máquinas virtuais.
Clusters fragmentados
Para um cluster sharded, você configura o acesso externo por componente:
spec.externalAccessconfigura apenasmongos.spec.mongos.externalAccesssubstitui o campo de nível-raiz paramongos.spec.shard.externalAccessespec.configSrv.externalAccessdevem ser configurados para expor cada Pod dos shards e do conjunto de réplicas do servidor de configuração.
Segredo da string de conexão
O Kubernetes operador gera automaticamente uma string de conexão Secret chamada <metadata.name>-cluster-connection-string. Este Secret não contém credenciais, e o Kubernetes operador o mantém em sincronização com os nós ativos à medida que a associação muda durante a migração.
Aponte seus aplicativos para este Secret em vez de uma string de conexão codificada. Fazer isso significa que as alterações de associação durante a migração não exigem uma transição abrupta para seus aplicativos.
Encomenda
Configure o acesso externo e externalDomain antes de estender a implantação para o Kubernetes. O operador Kubernetes não oferece suporte para adicionar essas configurações depois que a migração já está em andamento.