Solucione problemas de uma migração para o Kubernetes

Em que ponto estou na migração?

Leia o campo reason da condição status.conditions[type=Migrating] primeiro.

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.

• Se o motivo permanecer Extending, os nós do Kubernetes que o operador do Kubernetes está adicionando ainda estão em provisionamento. Aguarde até que eles atinjam o estado desejado.

• Se o motivo permanecer InProgress e a contagem de nós externos não for alterada, sua última edição no recurso foi uma operação nula: o Kubernetes operador não detectou uma alteração que exija ação.

Falhas na importação de plugins

O plugin kubectl mongodb migrate-to-mck valida a configuração de automação de origem antes de gerar qualquer recurso. Ele sai com um erro, em vez de gerar um recurso incompleto ou incorreto, em cada um dos seguintes casos:

• O projeto MongoDB Ops Manager ou Cloud Manager tem mais de uma implantação.

• O projeto tem mais de um cluster sharded.

• O projeto tem conjuntos de réplicas que não fazem parte do cluster fragmentado.

• O projeto não tem conjuntos de réplicas ou clusters sharded. O plugin pode migrar apenas implantações de conjunto de réplicas e cluster sharded.

• A configuração de automação não tem processos.

• Um shard no cluster tem suporte do mesmo conjunto de réplicas que o servidor de configuração. Esta topologia de servidor de configuração incorporado não é suportada para migração.

• O plugin não consegue encontrar um nó votante elegível para prioridade em um conjunto de réplicas, portanto, não consegue determinar o processo de origem para esse conjunto de réplicas.

• Um processo tem um processType diferente de mongod ou mongos.

Incompatibilidades de Caminho e Configuração Não Configuráveis

O plugin sinaliza as seguintes configurações de automação quando não correspondem ao que o operador do Kubernetes espera:

• auth.keyFile difere do caminho que o operador do Kubernetes deriva de spec.downloadBase.

• auth.keyFileWindows está definido.

• monitoringAgentConfig.logPath ou backupAgentConfig.logPath está definido como um caminho não padrão.

• Um processo tem um authSchemaVersion que difere do padrão do operador Kubernetes.

Erros de autenticação

• auth.autoUser está vazio enquanto a autenticação está habilitada.

• auth.autoUser não tem uma entrada correspondente em auth.usersWanted para seu banco de dados. Sem uma entrada correspondente, a autenticação do agente falha após a migração.

• MONGODB-X509 A autenticação do agente requer que tls.autoPEMKeyFilePath seja definido na configuração de automação. Consulte spec.security.authentication.agents.autoPEMKeyFilePath.

• Um LDAP bindMethod diferente de simple não é suportado para migração.

Heterogeneidade de nós

O Kubernetes operador usa spec.additionalMongodConfig e spec.agent.mongod.systemLog de um único processo de origem. Se os nós do seu conjunto de réplicas tiverem configurações diferentes, revise todos os nós e reconcilie as diferenças antes de migrar — o recurso gerado aplica uma configuração a todos os nós do Kubernetes.

Alertas que merecem ação

As seguintes configurações de automação por processo não são transferidas para novos nós do Kubernetes. Planeje-as antes de migrar:

• secondaryDelaySecs

• membro oculto

• buildIndexes: false

Se sua implantação de origem tiver nós de análise ou nós atrasados, planeje como deseja representá-los no Kubernetes antes de começar.

Itens adicionais para revisar:

• O plugin ignora um processo desativado; ele não aparece como um nó externo.

• Se um processo não tiver TLS configurado, defina net.tls.mode como disabled no MongoDB Ops Manager ou Cloud Manager, na implantação de máquina virtual existente, antes de migrar. Não defina isso no recurso MongoDB gerado. Caso contrário, a configuração de TLS do nó do Kubernetes não corresponderá ao processo de origem e a migração causará uma alteração de implantação não planejada.

• Se a configuração logRotate ou auditLogRotate de um processo diferir da configuração do nível do projeto, o Kubernetes operador usará o valor do nível do projeto.

Incompatibilidade de versão

A anotação mongodb.com/migrate-tool-version registra a versão do plugin kubectl mongodb migrate-to-mck que gerou o recurso. O Kubernetes Operator valida esta anotação contra sua própria versão em cada reconciliação, incluindo durante a execução a seco. Se as versões forem incompatíveis, regenere o recurso com uma versão de plugin compatível.

Problemas na execução de teste

Descompasso TLS CA

Os certificados dos nós do Kubernetes devem ser emitidos pela mesma autoridade de certificação que assinou os certificados dos nós da máquina virtual. Caso contrário, a validação da conectividade e a replicação entre a máquina virtual e os nós do Kubernetes falharão.

memberConfig problemas

• spec.memberConfig tem menos entradas do que spec.members. Adicione uma entrada por nó.

• O Kubernetes operador ignora o campo spec.memberConfig de nível superior para clusters sharded.

Problemas de Nomenclatura

O nome do recurso ou o nome do conjunto de réplicas é muito longo ou não é um nome RFC 1123 válido. Use spec.replicaSetNameOverride ou --resource-name-override para fornecer um nome Kubernetes válido.

Surpresas de validação

• As validações podem ser disparadas enquanto a anotação de dry-run (mongodb.com/migration-dry-run) estiver definida, não apenas depois de iniciar a migração real.

• A validação do limite de nó votante pode aparecer na reconciliação, em vez de no momento da admissão, se uma alteração que excederia o limite for aplicada indiretamente.

• Agrupar muitas alterações em lote em uma única edição pode fazer com que a implantação perca o quórum. Faça apenas um tipo de alteração por vez: adicione nós do Kubernetes, remova nós externos ou altere votos e prioridade.

Diagnósticos a Coletar

Se o problema persistir depois de você ter percorrido as seções acima, colete o seguinte antes de entrar em contato com o suporte:

• O YAML do recurso MongoDB, incluindo status.conditions:

  kubectl get mdb <resource-name> -n <namespace> -o yaml

• Os recursos MongoDBUser para a implantação.

• Logs do Kubernetes operador.

• log do pod da tarefa do validador de conectividade.

• O JSON de configuração de automação do MongoDB Ops Manager ou Cloud Manager.

Em seguida, entre em contato com o Suporte Técnico.

Saiba mais

• Migrar uma implantação autogerenciada para o Kubernetes

• Migrar um conjunto de réplicas para Kubernetes

• Configurações de recursos de migração do MongoDB

• migrate-to-mck Referência de Comando do Plugin