/ /

Solucionar problemas de migração para o Kubernetes

Esta página ajuda a diagnosticar problemas que podem ocorrer enquanto você migra um conjunto de réplicas autogerenciado ou cluster fragmentado de máquinas virtuais para o Kubernetes no Kubernetes Operator, incluindo falhas de importação de plugin , problemas de execução seca e conectividade, incompatibilidades de autenticação e erros de validação. Para obter informações básicas sobre o fluxo de trabalho de migração, consulte Migrar uma implantação autogerenciada para Kubernetes.

Onde estou na migração?

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

Razão	Status	Significado
`Validating`	`True`	A anotação de execução seca está definida.
`Extending`	`True`	A contagem de membros do Kubernetes desejado excede a última contagem reconciliada.
`Pruning`	`True`	The `externalMembers` count dropped below `status.migrationObservedExternalMembersCount`.
`InProgress`	`True`	Existem membros externos, mas nada está mudando. Esta também é a razão da primeira reconciliação.
`MigrationComplete`	`False`	Todos os membros externos foram removidos.

Precedence is Validating > Extending > Pruning > InProgress. A prune that also grows the Kubernetes side reports Extending, which is another reason to make one change at a time.

Poda e extensão não são permitidos ao mesmo tempo.

To script against migration completion, use kubectl wait --for=condition=Migrating=False rather than polling status.phase.

Se o motivo permanecer Extending, os membros do Kubernetes que o Kubernetes Operator está adicionando ainda estarão provisionando. Espere que eles atinjam o estado da meta.
Se o motivo permanecer InProgress e a contagem de membros externos não for alterada, sua última edição no recurso foi um no-op: o Kubernetes Operator não detectou uma alteração que exija uma ação.

Falhas na importação de plug-ins

O plugin-in kubectl mongodb migrate-to-mck valida a configuração da 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 do Ops Manager ou do Cloud Manager tem mais de um sistema.
O projeto tem mais de um cluster fragmentado.
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 fragmentados. O plugin-in pode migrar apenas conjuntos de réplicas e implantações de cluster fragmentado .
A configuração de automação não tem processos.
Um shard no cluster fragmentado é apoiado pelo mesmo conjunto de réplicas que o servidor de configuração. Essa topologia embedded-config-server não é suportada para migração.
O plugin não consegue encontrar um membro votante elegível por prioridade em um conjunto de réplicas, portanto, não pode determinar o processo de origem desse conjunto de réplicas.
Um processo tem um processType diferente de mongod ou mongos.

Caminho não configurável e incompatibilidades de configuração

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

auth.keyFile difere do caminho que o Operador Kubernetes deriva do spec.downloadBase.
auth.keyFileWindows está definido.
monitoringAgentConfig.logPath ou backupAgentConfig.logPath estiver 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 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 dos membros

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

Avisos que valem a pena agir

As seguintes configurações de automação por processo não são transportadas para novos membros do Kubernetes. Planeje-se para eles antes de migrar:

secondaryDelaySecs
Membros ocultos
buildIndexes: false

Se o sistema de origem tiver nós analíticos ou nós atrasados, planeje como deseja representá-los no Kubernetes antes de iniciar.

Itens adicionais para revisar:

O plugin ignora um processo desabilitado; ele não aparece como um membro externo.
Se um processo não tiver TLS configurado, defina net.tls.mode como disabled no Ops Manager ou no Cloud Manager, no sistema 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 membro do Kubernetes não corresponde ao processo de origem, e a migração causa uma alteração não planejada no sistema.
Se a configuração logRotate ou auditLogRotate de um processo for diferente da configuração no nível do projeto, o Kubernetes Operator usará o valor no 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 essa anotação em relação à sua própria versão em cada reconciliação, inclusive durante a execução seca. Se as versões forem incompatíveis, regenere o recurso com uma versão de plugin compatível.

Problemas de execução seca

A execução seca parece travada

Exclua o trabalho <resourceName>-connectivity-check. A próxima reconciliação a recria.

Se o trabalho nunca for criado, verifique se suas permissões do Kubernetes RBAC incluem batch/jobs. As permissões batch/jobs ausentes impedem o Kubernetes Operator de criar o trabalho do validador de conectividade.

Falhas de conectividade

Código de saída do trabalho do validador	Status da condição	Razão	Significado
A tarefa ainda está em execução	`Unknown`	`Running`	The `status.phase` is `ConnectivityCheckRunning`.
`0`	`True`	`NetworkValidationPassed`	Todos os membros externos são acessíveis e autenticados.
`2`	`False`	`AuthenticationFailed`	Credentials, the authentication mechanism, or a missing `__system@local` role.
`3`	`False`	`NetworkFailed`	DNS, TLS, tempos limite ou membros inacessíveis. Verifique os registros do pod de trabalho.
`1` ou outro	`False`	`UnknownError`	Falha não classificada. Verifique os registros do pod de trabalho.

Failures that occur before the Job starts use the reasons OperatorImageUnknown, BuildStatefulSetOptions, AgentCertSecretFailed, and AgentCertSubject.

Kubernetes Operator removes the NetworkConnectivityVerified condition from status.conditions entirely once no external members remain.

Falhas pré-tarefa

O operador do Kubernetes pode falhar antes do início do trabalho do validador de conectividade, por um destes motivos:

OperatorImageUnknown
BuildStatefulSetOptions
AgentCertSecretFailed
AgentCertSubject

Incompatibilidade de CA de TLS

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

`memberConfig` Problemas

spec.memberConfig tem menos entradas do que spec.members. Adicione uma entrada por membro.
O Kubernetes Operator ignora o campo spec.memberConfig de nível superior para clusters fragmentados.

Aviso

Definir spec.memberConfig antes de aumentar a contagem de membros

By default, new Kubernetes members join as voting members. The CRD defaults are votes: 1 and priority: "1", which let a still-syncing member participate in an election before it has finished its initial sync.

MongoDB recommends that you write one spec.memberConfig entry per new Kubernetes member with votes: 0 and priority: "0" before you raise the member count, so that a still-syncing member cannot win an election. votes is an integer. priority is a string.

Problemas de nomeação

O nome do recurso ou do 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 válido do Kubernetes.

Novidades na validação

As validações podem ser disparadas enquanto a anotação de execução seca (mongodb.com/migration-dry-run) está definida, não apenas depois de iniciar a migração real.
A validação do limite de membros votantes pode vir à tona na reconciliação, em vez de no momento da internação, se uma alteração que exceda o limite seja aplicada indiretamente.
Agrupar muitas alterações em um único lote pode fazer com que o sistema perder quorum. Faça apenas um tipo de alteração por vez: adicionar membros do Kubernetes, remover membros externos ou alterar votos e prioridade.

Diagnósticos a serem coletados

Se o problema persistir depois de trabalhar nas seções acima, recolha o seguinte antes de entrar em contato com o suporte:

O recurso MongoDB YAML, incluindo status.conditions:
kubectl get mdb <resource-name> -n <namespace> -o yaml
Os recursos do MongoDBUser para a implementação.
Registros do Operador Kubernetes.
Os registros do pod do trabalho do validador de conectividade.
A configuração de automação JSON do Ops Manager ou Cloud Manager.

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

Saiba mais

Voltar

Migrar para o comando Plugin

Perguntas frequentes