Problemas conhecidos do Config Sync

Os pods do Config Sync ficam paralisados durante o upgrade para a versão 1.24.0 em clusters migrados do Hub

Após o upgrade para o Config Sync 1.24.0, os campos removidos (como o readinessProbe e as verificações de integridade do sidecar otel-agent) podem persistir em clusters migrados para o gerenciamento do Hub. Como o componente de verificação de integridade por trás do readinessProbe é removido, o contêiner otel-agent não é iniciado, fazendo com que os pods do Config Sync fiquem paralisados.

Esse problema afeta apenas clusters em que o Config Sync foi instalado manualmente usando o kubectl e, posteriormente, mudou para o gerenciamento do Hub. Essa falha ocorre porque o processo de migração processa o gerenciamento de campos de maneira diferente de uma nova instalação. Para clusters instalados manualmente ou clusters instalados inicialmente pelo Hub, os campos são removidos conforme o esperado.

Alternativa :

para resolver esse problema, siga as instruções para desinstalar o Config Sync e reinstale-o pelo Hub.

Correção: métricas informadas para pacotes excluídos

Se você excluir um objeto RootSync ou RepoSync, mas não excluir o objeto ResourceGroup com o mesmo nome, o Config Sync continuará informando as seguintes métricas para esse objeto ResourceGroup:

• rg_reconcile_duration_seconds
• resource_group_total
• resource_count
• ready_resource_count
• resource_ns_count
• cluster_scoped_resource_count
• crd_count
• kcc_resource_count
• pipeline_error_observed

Alternativa :

exclua o objeto ResourceGroup:

kubectl delete resourcegroup RESOURCE_GROUP_NAME -n config-management-system

substitua RESOURCE_GROUP_NAME pelo nome do ResourceGroup objeto que precisa ser excluído. Para saber mais sobre a nomenclatura ResourceGroup, consulte Controlador e objetos do ResourceGroup.

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 do que outras.

Se um reconciliador não puder ser programado, isso poderá ocorrer devido à 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 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 GKE Autopilot, as solicitações do reconciliador são definidas como mais altas para representar o uso de maneira mais realista durante a sincronização.

Alternativa :

o GKE Autopilot ou 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 nós ou os tamanhos das instâncias de nó, talvez seja necessário ajustar essas configurações para acomodar os requisitos de recursos do pod do reconciliador.

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 personalizado filtros de métricas e o Cloud Monarch.

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 named otel-collector-custom no config-management-monitoring namespace.

O Config Sync está em conflito consigo mesmo

O Config Sync pode parecer estar em um conflito de controladores consigo 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.

O Config Sync está em conflito com os recursos do Config Connector

O Config Sync pode parecer estar em conflito com o Config Connector em relação a 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 de verdade.

Alternativa:

para evitar esse problema, adicione o campo withState=ANY à declaração de recurso. Como alternativa, você pode abandonar e readquirir o recurso com a cnrm.cloud.google.com/state-into-spec: absent anotação.

O contêiner git-sync falha em loops após um arquivo de bloqueio do Git ser órfão

Se você encontrar o contêiner git-sync em loop de falha com erros semelhantes aos seguintes no registro do contêiner git-sync, uma invocação git anterior pode ter falhado e deixado um arquivo de bloqueio órfão no contêiner:

    {"logger":""..."msg":"repo contains lock file","error":null,"path":"/repo/source/.git/shallow.lock"}
    ...runtime error: invalid memory address or nil pointer dereference
    

Alternativa :

para contornar esse problema, reinicie o pod de reconciliação afetado para atribuir um novo volume temporário:

    kubectl delete pod -n config-management-system RECONCILER_NAME
    

Correção: a anotação de mutação de ignorar não foi respeitada

Um bug no reconciliador do Config Sync faz com que ele aplique mudanças nas configurações declaradas, mesmo quando a anotação client.lifecycle.config.k8s.io/mutation está presente. Isso pode fazer com que o estado do objeto no cluster seja substituído.

Alternativa :

é possível parar de gerenciar o objeto gerenciado adicionando a anotação configmanagement.gke.io/managed: disabled. No entanto, a desativação do gerenciamento impede que o Config Sync recrie o objeto se ele for excluído do cluster. Ele também impede que outras atualizações na fonte de verdade sejam aplicadas.

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 é mantido, porque o registro de auditoria não distingue entre simulações e solicitações normais.

Alternativa:

Correção: falha ao gravar o inventário atualizado no cluster

Se o Config Sync não conseguir atualizar o status de um objeto ResourceGroup, você poderá encontrar um erro intermitente nos registros do reconciliador semelhante ao seguinte:

    KNV2009: task failed (action: "Inventory", name: "inventory-set-0"): failed to write updated inventory to cluster: Operation cannot be fulfilled on resourcegroups.kpt.dev "root-sync": the object has been modified; please apply your changes to the latest version and try again
    

Esse erro ocorre devido a uma disputa entre o reconciliador e o controlador ResourceGroup. O controlador ResourceGroup pode atualizar o status do ResourceGroup antes que o reconciliador possa atualizar a especificação do ResourceGroup, causando o erro KNV2009.

Alternativa :

esse problema não tem uma solução alternativa. O erro será resolvido automaticamente.

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 no recurso google_gke_hub_feature_membership: config_sync.enabled. Como o valor padrão desse campo é false, se ele não for definido explicitamente como true, as instalações ou upgrades do Config Sync vão falhar ao usar a versão 5.41.0 ou mais recente do Terraform. Você também poderá encontrar uma mensagem de erro que declara git spec not included in configmanagement spec se esse problema ocorrer.

Alternativa :

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

Erros de dados ausentes no painel do Config Sync no Cloud de Confiance console

Você pode encontrar erros como "dados ausentes" ou "credenciais de cluster inválidas" para clusters do Config Sync em painéis no Cloud de Confiance console. Esse problema pode ocorrer quando você não está conectado aos clusters do GDC (VMware) ou GDC (bare metal).

Alternativa :

se você encontrar esses tipos de erros no Cloud de Confiance console nos clusters do GDC (VMware) ou GDC (bare metal), verifique se você está conectado aos clusters com o serviço de identidade do GKE ou o gateway de conexão.

Correção: o Config Sync impede atualizações de recursos abandonados

Antes da versão 1.21.0, um objeto RootSync ou RepoSync excluído pode deixar vários rótulos e anotações que o Config Sync usa para rastrear esses objetos de recursos.

Esses rótulos e anotações podem causar os seguintes efeitos colaterais após a exclusão de um objeto RootSync ou RepoSync:

• Outros objetos RepoSync não podem assumir a propriedade de objetos gerenciados anteriormente.
• Se a prevenção de desvio estiver ativada, isso poderá fazer com que o Config Sync rejeite mudanças em recursos abandonados.

A CLI nomos não oferece suporte ao plug-in de autenticação oidc

Você pode encontrar erros como no Auth Provider found for name "oidc" ao usar a ferramenta de linha de comando nomos. Esse problema pode ocorrer quando você está usando o plug-in de autenticação oidc.

Alternativa :

não há solução alternativa. O plug-in de autenticação oidc será adicionado novamente em uma versão subsequente.