Problemas conhecidos do Config Sync

Esta página lista problemas conhecidos para versões com suporte do Config Sync.

Muitos dos problemas listados aqui foram corrigidos. A coluna Versão corrigida indica a versão em que a correção foi introduzida. Para receber essa correção, faça upgrade para a versão listada ou mais recente.

Para filtrar os problemas conhecidos por uma versão ou categoria do produto, selecione os filtros nos menus suspensos a seguir.

Selecione a versão do Config Sync:

Selecione a categoria do seu problema:

Ou filtre os problemas conhecidos:

Categoria Versão identificada Versão corrigida Problema e solução alternativa
Integridade dos componentes 1.15.0 1.17.0

Correção: o contêiner de reconciliação OOMKilled no Autopilot

Em 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 kernel por usar muita memória.

Alternativa:

Se não for possível fazer upgrade para a versão 1.17.0 ou mais recente, especifique um limite de memória maior usando substituições de recursos.

Na versão 1.17.0, os limites padrão de CPU e memória foram ajustados para ajudar a evitar erros de falta de memória na maioria dos casos de uso.
Integridade dos componentes 1.15.0

Não é possível programar o reconciliador

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

Se um reconciliador não puder ser programado, talvez seja devido a uma solicitação de mais recursos do que estão disponíveis nos nós.

Se você estiver usando clusters do GKE no modo padrão, as solicitações de recursos do reconciliador serão definidas como muito baixas. Essa configuração foi escolhida para permitir a programação, mesmo que isso levasse a um limite e a um desempenho lento, para que o Config Sync funcionasse em pequenos clusters e nós. No entanto, nos clusters do Autopilot do GKE, as solicitações do reconciliador são definidas em um nível mais alto para representar de forma mais realista o uso durante a sincronização.

Alternativa:

O GKE Autopilot ou o GKE Standard com o provisionamento automático de nós ativado precisam mostrar 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 tamanhos de instâncias ou nós, talvez seja necessário ajustar essas configurações para acomodar os requisitos de recursos do pod de reconciliação.
Erros de KNV 1.15.0 Versão do Kubernetes 1.27

Correção: erro KNV1067, mesmo que a configuração tenha sido aplicada com sucesso

Devido a um problema com a OpenAPI v2, talvez você encontre um erro KNV1067, mesmo que a 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 de KNV 1.15.0 1.16.0, versão do Kubernetes 1.28

Correção: o Config Sync não consegue reconciliar com o erro KNV2002

Se o Config Sync não conseguir fazer a reconciliação com um KNV2002 error, isso pode ser devido a um problema conhecido causado por um problema do Client go. O problema causa uma lista vazia de recursos no grupo de API external.metrics.k8s.io/v1beta1 com uma mensagem de erro do objeto RootSync ou RepoSync ou dos 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
Métricas 1.15.0 1.17.2

Correção: falha na exportação: rótulos de métricas não reconhecidos

Na versão 1.15.0, o Config Sync adicionou rótulos type e commit a muitas métricas. Esses rótulos aumentaram a cardinalidade da métrica, 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.
Métricas 1.15.0 1.16.1

Correção: erros de transformação e cardinalidade de métricas altas

Na versão 1.15.0, o Config Sync adicionou rótulos type e commit a muitas métricas. Esses rótulos aumentaram a cardinalidade da métrica, 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.

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étricas 1.15.0

Falha na exportação. Permissão recusada

Por padrão, quando o gerente de reconciliação detecta o Application Default Credentials, o coletor de Otel é 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étricas 1.15.0

O coletor de Otel falha com a configuração personalizada.

Se você tentar modificar ou excluir um dos ConfigMaps padrão, otel-collector ou otel-collector-google-cloud, o coletor de Otel pode apresentar um erro ou falhar ao 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.
nomos cli 1.15.0 1.17.2

Correção: nomos status e nomos bugreport não funcionam em um pod

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

O Config Sync está em conflito consigo mesmo

O Config Sync pode parecer estar em um conflito de controladores com ele mesmo. Isso ocorre ao definir o valor padrão para um campo opcional de um recurso no repositório do 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 string, booleano e inteiro são "", false e 0, respectivamente.

Alternativa:

Remova o campo da declaração de recurso.
Remediação

O Config Sync está competindo com os recursos do Config Connector.

Pode parecer que o Config Sync está lutando contra o Config Connector em um recurso, por exemplo, um StorageBucket. Isso ocorre se você não definir o valor de um campo opcional de um recurso spec.lifecycleRule.condition.withState na fonte da verdade.

Alternativa:

Para evitar esse problema, adicione o campo withState=ANY à declaração de recurso. Como alternativa, é possível abandonar e, em seguida, adquirir novamente o recurso com a anotação cnrm.cloud.google.com/state-into-spec: absent.

Fonte de verdade 1.17.3 1.18.3

Correção: falha na autenticação SSH do Git com o GitHub

O git-sync v4.2.1 tem um bug que remove o nome de usuário do URL do repositório ao usar SSH, fazendo com que a autenticação falhe ao se conectar ao GitHub, o que exige que o usuário seja git.

A mensagem de erro do git é: git-sync@github.com: Permission denied (publickey).\r\nfatal: Could not read from remote repository.

Alternativa:

use outro método de autenticação.
Fonte de verdade 1.16.1 1.16.2

Correção: não é possível avaliar o link de origem periodicamente

O Config Sync pode apresentar problemas quando o reconciliador começa a não conseguir avaliar periodicamente o link da fonte. Esse problema ocorre porque git-sync ainda não clonou o repositório de origem.

Nas versões 1.16.2 e mais recentes, esse é um erro temporário, por isso é registrado, mas não é informado como um erro.
Fonte de verdade 1.15.0 1.18.0

Correção: credenciais de autenticação periodicamente inválidas para o Cloud Source Repositories

O Config Sync pode apresentar erros periodicamente quando o token de autenticação expira para os Cloud Source Repositories. Esse problema é causado pela atualização do token que aguarda a expiração antes de atualizar o token.

Na versão 1.18.0 e mais recentes, o token é atualizado na primeira solicitação em até cinco minutos após a expiração. Isso evita o erro de credenciais de autenticação inválidas, a menos que as credenciais sejam inválidas.
Fonte de verdade 1.15.0 1.17.0

Correção: erro ao sincronizar o repositório: o prazo de contexto foi excedido

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

Na versão 1.17.0 e mais recentes, o fetch do Git é realizado com --depth=1, que busca apenas o commit mais recente. Isso acelera a busca de origem, evita a maioria dos timeouts e reduz a carga do servidor do Git.

Se você ainda estiver com esse problema após a atualização, provavelmente sua fonte de verdade tem muitos arquivos, seu servidor Git está respondendo lentamente ou há algum outro problema de rede.
Sincronizando 1.15.0

Grande 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 as solicitações PATCH apareçam no registro de auditoria, mesmo quando o PATCH não for mantido, porque o registro de auditoria não distingue simulações e solicitações normais.

Alternativa:

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

Correção: o Config Sync não consegue extrair a confirmação mais recente de uma ramificação

Nas versões 1.17.0, 1.17.1 e 1.17.2 do Config Sync, talvez você encontre um problema em que o Config Sync não consegue extrair o commit mais recente do HEAD de uma ramificação específica quando a mesma ramificação é referenciada em vários remotos e eles estão fora de sincronia. 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 commit da última linha, que pode não ser o commit mais recente.

O exemplo a seguir mostra como isso pode ser feito:

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

Na versão 1.17.3 e mais recentes, a dependência do git-sync foi atualizada com um mecanismo de busca diferente.

Se não for possível fazer upgrade, defina a revisão do Git (spec.git.revision) para o SHA de commit 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.
Registro particular 1.19.0

O Config Sync não usa o registro particular para implantações de reconciliador

O Config Sync precisa substituir as imagens de todas as implantações quando um registro particular é configurado. No entanto, o Config Sync não substitui o registro de imagens para imagens nas implantações do reconciliador.

Alternativa:

Uma solução alternativa para esse problema é configurar o espelho do registro de imagens no containerd.

Sincronizando 1.17.0 1.18.3

Correção: o reconciliador do Config Sync está em loop de falha

Nas versões 1.17.0 e mais recentes do Config Sync, você pode encontrar um problema em que o reconciliador não consegue criar uma configuração de descanso em alguns provedores do Kubernetes.

O exemplo a seguir mostra como esse problema pode aparecer nos registros do reconciliador:

Error creating rest config: failed to build rest config: reading local kubeconfig: loading REST config from "/.kube/config": stat /.kube/config: no such file or directory
Terraform Versão 5.41.0 do Terraform

O Config Sync não pode ser instalado nem atualizado usando o Terraform.

A versão 5.41.0 do Terraform introduziu um novo campo ao google_gke_hub_feature_membership: config_sync.enabled. Como o valor padrão desse campo é false, as instalações do Config Sync falham quando o Terraform é atualizado para a versão 5.41.0.

Alternativa:

  • Se você usar o recurso google_gke_hub_feature_membership, defina manualmente o config_sync.enabled como true.
  • Se você usar o submódulo acm, é recomendável mudar para uma maneira alternativa de instalar o Config Sync. Se não for possível fazer a troca, faça upgrade para a v33.0.0.

Voltar ao início

A seguir