Problemas conhecidos do Config Sync

Nesta página, listamos os problemas conhecidos das versões compatíveis do Config Sync. Para filtrar os problemas conhecidos por uma versão do produto ou categoria de problema, selecione seus filtros nos menus suspensos a seguir.

Selecione a versão do Config Sync:

Selecione a categoria do problema:

Você também pode filtrar os problemas conhecidos:

Categoria Versão identificada Versão corrigida Problema e solução alternativa
Integridade do componente 1.15.0 1.17.0

Reconciliador OOMKilled de contêiner no AutoPilot

Nos clusters do Autopilot, os contêineres de componentes do Config Sync têm limites de recursos definidos para CPU e memória. Sob carga, esses contêineres podem ser encerrados pelo kubelet ou pelo kernel pelo uso de memória em excesso.

Alternativa:

Faça upgrade para a versão 1.17.0 ou mais recente. Na versão 1.17.0 do Config Sync, os limites padrão de CPU e memória foram ajustados para evitar erros de falta de memória na maioria dos casos de uso.

Se não for possível fazer upgrade, especifique um limite de memória maior usando substituições de recursos.

Integridade do componente 1.15.0

Reconciliador não programável

Os reconciliadores do Config Sync exigem quantidades variadas de recursos, dependendo da configuração do RootSync ou do RepoSync. Algumas configurações exigem mais recursos que outras.

Se um reconciliador não for programável, talvez o motivo seja a solicitação de mais recursos do que os disponíveis nos nós.

Se você estiver usando clusters do GKE no modo padrão, as solicitações de recurso do reconciliador serão definidas como muito baixas. Essa configuração foi escolhida para permitir a programação, mesmo que ela resulte em limitação e desempenho lento, para que o Config Sync funcione em pequenos clusters e nós pequenos. No entanto, nos clusters do Autopilot do GKE, as solicitações do reconciliador são definidas com um valor mais alto para representar de maneira mais realista o uso durante a sincronização.

Alternativa:

O Autopilot do GKE ou o GKE Standard com o provisionamento automático de nós ativado precisa ver quantos recursos são solicitados e criar nós de tamanho adequado para permitir a programação. No entanto, se você estiver configurando manualmente os nós ou tamanhos de instância de nós, talvez seja necessário ajustar essas configurações para acomodar os requisitos de recursos de pod do reconciliador.
Erros do KNV 1.15.0 Kubernetes versão 1.27

Erro KNV1067 mesmo que a configuração tenha sido aplicada com sucesso

Devido a um problema com a OpenAPI v2, é possível que você receba um erro KNV1067 mesmo que sua configuração tenha sido aplicada.

Alternativa:

Se o cluster estiver executando uma versão do Kubernetes anterior à 1.27, verifique se o campo protocol está definido explicitamente em spec: containers: ports:, mesmo que você esteja usando o TCP padrão.

Erros do KNV 1.15.0 1.16.0

O Config Sync não consegue fazer a reconciliação com o erro KNV2002

Se o Config Sync não conseguir reconciliar com um KNV2002 error, talvez seja devido a um problema conhecido causado por um problema client-go. O problema gera uma lista vazia de recursos no grupo de APIs external.metrics.k8s.io/v1beta1 com uma mensagem de erro do objeto RootSync ou RepoSync ou os registros do reconciliador:

KNV2002: API discovery failed: APIServer error: unable to retrieve the complete list of server APIs: external.metrics.k8s.io/v1beta1: received empty response for:
external.metrics.k8s.io/v1beta1

Alternativa:

Para resolver o problema, faça upgrade do cluster do GKE para a versão 1.28 ou mais recente do GKE ou faça upgrade do Config Sync para a versão 1.16.0 ou mais recente. Ambas as versões contêm correções para o problema do client-go.
Métrica 1.15.0 1.17.2

Falha na exportação: marcadores de métrica não reconhecidos

Na versão 1.15.0, o Config Sync adicionou os rótulos type e commit a muitas métricas. Esses rótulos aumentaram a cardinalidade das métricas, o que aumentou o número de métricas exportadas. O processamento de atributos também foi adicionado para filtrar esses rótulos ao exportar para o Cloud Monarch, mas essa filtragem foi configurada incorretamente, causando erros de transformação nos registros otel-collector.

Alternativa:

Faça upgrade para a versão 1.17.2 ou mais recente.
Métrica 1.15.0 1.16.1

Erros de transformação e cardinalidade de alta métricas

Na versão 1.15.0, o Config Sync adicionou os rótulos type e commit a muitas métricas. Esses rótulos aumentaram a cardinalidade das métricas, o que aumentou o número de métricas exportadas. O processamento de atributos também foi adicionado para filtrar esses rótulos ao exportar para o Cloud Monarch, mas essa filtragem foi configurada incorretamente, causando erros de transformação nos registros otel-collector.

Alternativa:

Faça upgrade para a versão 1.16.1 ou mais recente. Na versão 1.16.1, o campo de tipo foi removido, a filtragem foi corrigida e o campo de confirmação foi filtrado do Cloud Monitoring. Isso corrigiu os erros e reduziu a cardinalidade das métricas.
Métrica 1.15.0

Falha na exportação. Permissão negada

Por padrão, quando o gerenciador de reconciliação detecta Application Default Credentials, o otel-collector é configurado para exportar métricas para o Prometheus, o Cloud Monitoring e o Monarch.

Alternativa:

otel-collector registra erros se você não tiver configurado o Cloud Monitoring ou Desativado o Cloud Monitoring e o Cloud Monarch.
Métrica 1.15.0

Falha no otel-collector com a configuração personalizada

Se você tentar modificar ou excluir um dos ConfigMaps padrão, otel-collector ou otel-collector-google-cloud, o otel-collector poderá apresentar um erro ou falhar por não conseguir carregar o ConfigMap necessário.

Alternativa:

Para personalizar a configuração de exportação de métricas, crie um ConfigMap chamado otel-collector-custom no namespace config-management-monitoring.
Métrica 1.14.0

Totais de métricas ausentes

Na versão 1.14.0 do Config Sync, as seguintes métricas foram removidas: resource_count_total, ready_resource_count_total e kcc_resource_count_total.

Alternativa:

Para rastrear valores totais, use o tipo de agregação Soma no Cloud Monitoring.
Métrica 1.14.1

Métricas de pod ausentes

Na versão 1.14.1 do Config Sync, a maioria das métricas do Config Sync foi alterada para usar o tipo k8s_container, em vez do tipo k8s_pod. Isso permitiu identificar de qual contêiner veio a métrica, o que é especialmente útil para os pods reconciliadores, que têm muitos contêineres. Devido a essa mudança, os painéis e alertas que estavam rastreando essas métricas podem ter parado de funcionar.

Alternativa:

Atualize as métricas para rastrear o tipo de métrica k8s_container.

nomos cli 1.15.0 1.17.2

nomos status e nomos bugreport não funcionam em um pod

Antes da versão 1.17.2 do nomos, nomos bugreport e nomos status só podiam se conectar ao cluster local quando executados dentro de um pod do Kubernetes. Na versão 1.17.2 do nomos, o método de autorização foi modificado para funcionar mais como kubectl. Devido a essa mudança, o cluster local é segmentado por padrão. É possível modificar a configuração especificando a variável de ambiente KUBECONFIG.

Alternativa:

Faça upgrade para a versão 1.17.2 do nomos.

Ações

O Config Sync está lutando contra si mesmo

O Config Sync pode parecer que está em uma combate de controlador. consigo mesmo. Esse problema ocorre quando você define o valor padrão para um campo opcional de um recurso no repositório Git. Por exemplo, definir apiGroup: "" como o assunto de um RoleBinding aciona isso porque o campo apiGroup é opcional e uma string vazia é o valor padrão. Os valores padrão dos campos de string, booleano e inteiro são "", false e 0, respectivamente.

Alternativa:

Remova o campo da declaração do recurso.
Ações

Disputa do Config Sync com os recursos do Config Connector

O Config Sync pode parecer combater o Config Connector por um recurso, por exemplo, um StorageBucket. Esse problema ocorre se você não definir o valor de um campo opcional de um recurso spec.lifecycleRule.condition.withState na fonte da verdade.

Alternativa:

É possível evitar esse problema adicionando o campo withState=ANY na declaração do recurso. Como alternativa, é possível abandonar e adquirir novamente o recurso com a anotação cnrm.cloud.google.com/state-into-spec: absent.

Fonte de verdade 1.16.1 1.16.2

Não é possível avaliar periodicamente o link de origem

O Config Sync pode apresentar problemas quando o reconciliador é iniciado quando periodicamente não consegue avaliar o link de origem. Esse problema acontece porque git-sync ainda não clonou o repositório de origem.

Alternativa:

Atualize o Config Sync para a versão 1.16.2 ou mais recente. Nessas versões, esse é um erro temporário. Portanto, ele é registrado, mas não relatado como um erro.
Fonte de verdade 1.15.0 1.17.0

Erro ao sincronizar o repositório: prazo de contexto excedido

Nas versões anteriores à 1.17.0, o Config Sync verificava o histórico completo do repositório Git por padrão. Isso pode fazer com que a solicitação de busca atinja o tempo limite em grandes repositórios com muitas confirmações.

Alternativa:

Faça upgrade para a versão 1.17.0 ou mais recente. Na versão 1.17.0 e mais recentes, a busca do Git é realizada com --depth=1, que busca apenas a confirmação mais recente. Isso acelera a busca da origem, evita a maioria dos tempos limite e reduz a carga do servidor Git.

Se o problema persistir depois do upgrade, é provável que sua Fonte da verdade tenha muitos arquivos, que o servidor Git esteja respondendo lentamente ou que haja algum outro problema de rede.
Sincronização 1.15.0

Alto número de solicitações PATCH ineficazes nos registros de auditoria

O remediador do Config Sync usa a simulação para detectar desvios. Isso pode fazer com que solicitações PATCH apareçam no registro de auditoria, mesmo quando o PATCH não é mantido, porque o registro de auditoria não distingue entre simulações e solicitações normais.

Alternativa:

Como o registro de auditoria não pode distinguir entre solicitações de teste e de não simulação, é possível ignorar as solicitações PATCH.
Sincronização 1.17.0

O Config Sync falha ao extrair a confirmação mais recente de uma ramificação

Nas versões 1.17.0 e mais recentes do Config Sync, pode haver um problema em que o Config Sync falha ao extrair a confirmação mais recente do HEAD de um branch específico quando o mesmo branch é referenciado em vários controles remotos e eles estão dessincronizados. Por exemplo, a ramificação main de um repositório remoto origin pode estar à frente da mesma ramificação no repositório remoto upstream, mas o Config Sync só busca o SHA de confirmação na última linha, que pode não ser a confirmação mais recente.

O exemplo a seguir mostra como esse problema pode acontecer:

git ls-remote -q [GIT_REPOSITORY_URL] main  main^{}
244999b795d4a7890f237ef3c8035d68ad56515d    refs/heads/main               # the latest commit
be2c0aec052e300028d9c6d919787624290505b6    refs/remotes/upstream/main    # the commit Config Sync pulls from

Alternativa:

Para atenuar esse problema, defina sua revisão do Git (spec.git.revision) para o SHA de confirmação mais recente, independentemente do valor definido para a ramificação do Git (spec.git.branch). Para mais informações sobre as configurações do Git, consulte Configuração do repositório do Git.

Voltar ao início

A seguir