Resolva problemas de conflitos de comandos

Esta página mostra como resolver problemas com conflitos de comandos. Estes conflitos consomem uma grande quantidade de recursos e podem degradar o seu desempenho. As lutas de controladores também são conhecidas como contentor de recursos.

A sincronização de configuração monitoriza os objetos que aplica no cluster e reverte as alterações feitas aos valores declarados na fonte de verdade. Se estas alterações forem feitas por outro responsável pelo tratamento, o recurso pode alternar entre os estados pretendidos pelos responsáveis pelo tratamento concorrentes. Um sintoma deste comportamento é que os campos metadata.generation e metadata.resourceVersion aumentam rapidamente. Por este motivo, se um objeto gerido for atualizado mais de cinco vezes por minuto, o Config Sync deteta o conflito, regista o desvio e comunica o erro no estado do objeto RootSync ou RepoSync.

O Config Sync tem uma lógica especial para detetar conflitos entre vários objetos RootSync e RepoSync. Para objetos RepoSync, se o reconciliador vir que o objeto já é gerido por outro reconciliador, as atualizações adicionais são ignoradas. Para objetos RootSync, o reconciliador tenta adotar qualquer objeto que esteja configurado para gerir, a menos que seja gerido por outro objeto RootSync. Isto impede que os reconciliadores do Config Sync entrem em conflito e comunica erros no estado de todos os objetos RootSync e RepoSync envolvidos.

Identifique lutas com comandos

Pode rever os erros de luta através do comando nomos status ou verificando o campo de estado no objeto RootSync ou RepoSync.

Se não tiver a ferramenta de linha de comandos nomos instalada, pode rever os registos do reconciliador RootSync executando o seguinte comando:

kubectl logs -n config-management-system \
    --selector "app=reconciler,configsync.gke.io/sync-name=root-sync" \
    --container reconciler

Para filtrar reconciliadores RepoSync específicos, execute o seguinte comando:

kubectl logs -n config-management-system \
    --selector "app=reconciler,configsync.gke.io/sync-namespace=NAMESPACE" \
    --container reconciler

Substitua NAMESPACE pelo espaço de nomes no qual criou a sua fonte de dados única com âmbito do espaço de nomes.

Se vir KNV2005 nos resultados, significa que existe um conflito de comandos.

A seguinte mensagem de erro é um exemplo do tipo de erro que pode ver nos registos:

KNV2005: detected excessive object updates, approximately 6 times per
minute. This may indicate Config Sync is fighting with another controller over
the object.

Investigue lutas com comandos

Para encontrar mais informações sobre qualquer conflito de controlador, monitorize as atualizações do ficheiro YAML do recurso executando o seguinte comando:

 kubectl get RESOURCE OBJECT_NAME \
     --namespace NAMESPACE \
     --watch -o yaml

Substitua o seguinte:

  • RESOURCE: o tipo de recurso que está a ser disputado.
  • OBJECT_NAME: o nome do objeto que está a ser disputado.
  • NAMESPACE: o espaço de nomes em que o recurso em disputa se encontra.

Os resultados do registo especificam o recurso, o nome do objeto e o espaço de nomes que tem de adicionar.

Este comando devolve um fluxo do estado do recurso depois de as atualizações serem aplicadas ao servidor da API. Use uma ferramenta de comparação de ficheiros para comparar o resultado.

Resolva conflitos de comandos

Existem várias formas de resolver conflitos de comandos. Escolha a opção que funciona melhor para a sua configuração do Config Sync:

  • Atualize o manifesto de recursos na origem para corresponder ao valor pretendido pelo outro controlador.
  • Remova o campo em questão da origem para permitir que o outro controlador o faça.
  • Desative ou desinstale o outro comando.
  • Remova o recurso da origem e faça a gestão manualmente ou com um controlador personalizado que tolere alterações específicas ou a cogestão.
  • Se for proprietário do controlador que está a causar a contenção de recursos e o campo que está a ser alterado não estiver na fonte de verdade, atualize o controlador para fazer a aplicação de patches em vez da atualização. Desta forma, a alteração é permitida pela sincronização de configuração e não é revertida.

Também existem alguns recursos que devem pertencer a outros controladores (por exemplo, alguns operadores instalam ou mantêm CRDs). Estes outros controladores removem automaticamente todos os metadados específicos da sincronização de configuração. Se outro componente no seu cluster do Kubernetes remover os metadados do Config Sync, pare de gerir o recurso com o Config Sync. Para informações sobre como o fazer, consulte o artigo Pare de gerir um objeto gerido.

Em alternativa, se não quiser que o Config Sync reverta as alterações aos objetos geridos no cluster, pode adicionar a anotação client.lifecycle.config.k8s.io/mutation: ignore ao objeto no qual quer que o Config Sync ignore as mutações. Para obter informações sobre como o fazer, consulte o artigo Ignore as mutações de objetos.

Resolução de conflitos de controladores para espaços de nomes implícitos

Por predefinição, o Config Sync cria um espaço de nomes implícito quando um RootSync gere um objeto com espaço de nomes, mas o próprio espaço de nomes ainda não existe. Se um controlador diferente tentar assumir a propriedade do espaço de nomes, pode ocorrer um conflito de controladores com o Config Sync. Pode confirmar que um espaço de nomes foi criado implicitamente se nunca tiver sido declarado no repositório raiz e o espaço de nomes ativo tiver a anotação prevent deletion.

Existem várias formas de resolver conflitos sobre um espaço de nomes implícito. Escolha a opção que funciona melhor para a sua configuração do Config Sync:

O que se segue?

  • Se continuar a ter problemas, verifique se o seu problema é um problema conhecido.

  • Se não conseguir encontrar uma solução para o seu problema na documentação, consulte a secção Obter apoio técnico para obter mais ajuda, incluindo aconselhamento sobre os seguintes tópicos: