Resolver problemas de batalhas de controles

Esta página mostra como resolver problemas relacionados às lutas de controles. Esses conflitos consomem uma grande quantidade de recursos e podem prejudicar seu desempenho. As lutas entre controladores também são conhecidas como contenção de recursos.

O Config Sync monitora os objetos aplicados no cluster e reverte as alterações feitas nos valores declarados na fonte da verdade. Se essas alterações forem feitas por outro controlador, o recurso poderá alternar entre os estados desejados pelos controladores concorrentes. Um sintoma desse comportamento é que os campos metadata.generation e metadata.resourceVersion aumentam rapidamente. Por isso, se um objeto gerenciado for atualizado mais de cinco vezes por minuto, o Config Sync detectará o conflito, registrará o deslocamento e informará o erro no status do objeto RootSync ou RepoSync.

O Config Sync tem uma lógica especial para detectar conflitos entre vários objetos RootSync e RepoSync. Para objetos RepoSync, se o reconciliador perceber que o objeto já é gerenciado por outro reconciliador, outras atualizações serão ignoradas. Para objetos RootSync, o reconciliador tenta adotar qualquer objeto configurado para gerenciar, a menos que ele seja gerenciado por outro objeto RootSync. Isso impede que os reconciliadores do Config Sync entrem em conflito entre si e informa erros no status de todos os objetos RootSync e RepoSync envolvidos.

Identificar lutas entre controles

Se você estiver usando o Config Sync versão 1.15.0 ou mais recente, poderá analisar os erros usando o comando nomos status ou verificando o campo de status no objeto RootSync ou RepoSync.

Se a ferramenta de linha de comando nomos não estiver instalada, é possível analisar os registros 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 por 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 namespace em que você criou sua fonte de verdade com escopo de namespace.

Se KNV2005 aparecer nos resultados, há uma luta entre os controles.

A mensagem a seguir é um exemplo do tipo de erro que pode aparecer nos registros:

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

Investigar lutas entre controles

Para encontrar mais informações sobre qualquer luta de controlador, veja as atualizações do arquivo YAML do recurso executando o seguinte comando:

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

Substitua:

  • RESOURCE: o tipo de recurso que está sendo disputado.
  • OBJECT_NAME: o nome do objeto que está sendo disputado.
  • NAMESPACE: o namespace em que o recurso está em disputa.

Os resultados do registro especificam o recurso, o nome do objeto e o namespace que você precisa adicionar.

Esse comando retorna um fluxo do estado do recurso depois que as atualizações são aplicadas ao servidor da API. Use uma ferramenta de comparação de arquivos para comparar a saída.

Resolver conflitos de controles

Há várias maneiras de resolver lutas de controles. Escolha a opção que funciona melhor para sua configuração do Config Sync:

  • Atualize o manifesto do recurso na origem para corresponder ao valor que o outro controlador quer.
  • Remova o campo em questão da origem para permitir que o outro controlador o gerencie.
  • Desative ou desinstale o outro controlador.
  • Remover o recurso da origem e gerenciá-lo manualmente ou com um controlador personalizado que tolere mudanças específicas ou cogerenciamento.
  • Se você for o proprietário do controlador que está causando a contenção de recursos e o campo que está sendo alterado não estiver na fonte de verdade, atualize seu controlador para realizar a aplicação de patches em vez de atualizar. Dessa forma, a alteração será permitida pelo Config Sync e não revertida.

Há também alguns recursos que precisam pertencer a outros controladores (por exemplo, alguns operadores instalam ou mantêm CRDs). Esses outros controladores removem automaticamente todos os metadados específicos do Config Sync. Se outro componente do cluster do Kubernetes remover os metadados do Config Sync, pare de gerenciar o recurso com essa ferramenta. Para informações sobre como fazer isso, consulte Como parar de gerenciar um objeto gerenciado.

Como alternativa, se você não quiser que o Config Sync reverta alterações em objetos gerenciados no cluster, adicione a anotação client.lifecycle.config.k8s.io/mutation: ignore ao objeto em que você quer que o Config Sync ignore as mutações. Para informações sobre como fazer isso, consulte Ignorar mutações de objetos.

A seguir

  • Se ainda estiver com problemas, verifique se o problema é um conhecido.