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.