Problemi noti di Config Sync

In questa pagina sono elencati i problemi noti relativi alle versioni supportate di Config Sync.

Molti dei problemi elencati qui sono stati risolti. La versione corretta indica la versione in cui è stata introdotta la correzione. Per ricevere questa correzione, esegui l'upgrade alla versione indicata o a una successiva.

Per filtrare i problemi noti in base a una versione di prodotto o a una categoria di problemi, seleziona i filtri dai seguenti menu a discesa.

Seleziona la versione di Config Sync:

Seleziona la categoria del problema:

In alternativa, filtra i problemi noti:

Categoria Versione identificata Versione corretta Problema e soluzione alternativa
Integrità dei componenti 1.15.0 1.17.0

Risolto: OOM del container riconciliatore chiuso su AutoPilot

Nei cluster Autopilot, i container dei componenti di Config Sync hanno limiti di risorse impostati per CPU e memoria. Sotto carico, questi container può essere interrotto dal kubelet o dal kernel per utilizzare troppa memoria.

Soluzione:

Se non riesci a eseguire l'upgrade alla versione 1.17.0 o successive, specifica un limite di memoria più elevato utilizzando sostituzione delle risorse.

Nella versione 1.17.0, i limiti di CPU e memoria predefiniti sono stati modificati per contribuire a evitare errori di esaurimento della memoria per la maggior parte dei casi d'uso.
Integrità componente 1.15.0

Riconciliatore non pianificabile

I riconciliatori di Config Sync richiedono quantità diverse di risorse, a seconda della configurazione di RootSync o RepoSync. Determinati configurazioni richiedono più risorse di altre.

Se un riconciliatore non è pianificabile, la causa potrebbe essere la richiesta di più risorse di quelle disponibili sui nodi.

Se utilizzi cluster GKE in modalità standard, la risorsa del riconciliatore è impostato su un valore molto basso. Questa impostazione è stata scelta nel tentativo di consentire la pianificazione, anche se ciò potrebbe comportare il throttling e un rallentamento del rendimento, in modo che Config Sync funzioni su piccoli cluster e piccoli nodi. Tuttavia, nei cluster GKE Autopilot, le richieste del riconciliatore sono impostate più in alto per rappresentare in modo più realistico durante la sincronizzazione.

Soluzione:

GKE Autopilot o GKE Standard con il provisioning automatico dei nodi abilitato dovrebbe essere in grado di vedere quante risorse sono richieste e creare nodi di dimensioni appropriate per consentire la pianificazione. Tuttavia, se devi manualmente dei nodi o delle dimensioni delle istanze dei nodi, potresti dover regolare per soddisfare i requisiti delle risorse dei pod del riconciliatore.
Errori KNV 1.15.0 Kubernetes versione 1.27

Risolto: errore KNV1067 anche se la configurazione è stata applicata correttamente

A causa di un problema con OpenAPI v2, potresti visualizzare un errore KNV1067 anche se la configurazione è stata applicata correttamente.

Soluzione:

Se il cluster esegue una versione di Kubernetes precedente alla 1.27, assicurati che il campo protocol sia impostato esplicitamente in spec: containers: ports: anche se utilizzi il valore predefinito TCP.

Errori KNV 1.15.0 1.16.0, versione Kubernetes 1.28

Risolto il problema di riconciliazione di Config Sync con errore KNV2002

Se Config Sync non riesce a effettuare la riconciliazione con un KNV2002 error, potrebbe essere dovuto a un problema noto causato da un problema con client-go. Questo problema causa la visualizzazione di un elenco vuoto di risorse nel external.metrics.k8s.io/v1beta1 gruppo di API con un messaggio di errore dall'oggetto RootSync o RepoSync o dai log del riconciliatore:

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
Metriche 1.15.0 1.17.2

Correzione: Esportazione non riuscita: etichette delle metriche non riconosciute

Nella versione 1.15.0, Config Sync ha aggiunto type e commit etichette a molte metriche. Queste etichette hanno aumentato la cardinalità delle metriche, il che ha aumentato il numero di metriche esportate. È stata aggiunta anche l'elaborazione degli attributi per filtrare queste etichette durante l'esportazione a Cloud Monarch, ma questo filtro non era configurato correttamente e causava errori di trasformazione nei log di otel-collector.
Metriche 1.15.0 1.16.1

Risolto: errori di cardinalità e trasformazione delle metriche elevate

Nella versione 1.15.0, Config Sync ha aggiunto le etichette type e commit a molte metriche. Queste etichette hanno aumentato la cardinalità delle metriche, il che ha aumentato il numero di metriche esportate. È stata aggiunta anche l'elaborazione degli attributi per filtrare queste etichette durante l'esportazione a Cloud Monarch, ma questo filtro non era configurato correttamente e causava errori di trasformazione nei log di otel-collector.

Nella versione 1.16.1, il campo tipo è stato rimosso, il filtro è stato corretto e il campo commit è stato filtrato ulteriormente da Cloud Monitoring. In questo modo sono stati corretti gli errori e ridotto la cardinalità delle metriche.
Metriche 1.15.0

Esportazione non riuscita. Autorizzazione negata

Per impostazione predefinita, quando il servizio di gestione del riconciliatore rileva le credenziali predefinite dell'applicazione, otel-collector è configurato per esportare le metriche in Prometheus, Cloud Monitoring e Monarch.

Soluzione:

Se non lo hai fatto, otel-collector registra gli errori Cloud Monitoring configurato o Cloud Monitoring disabilitato e Cloud Monarch.
Metriche 1.15.0

otel-collector con arresto anomalo con configurazione personalizzata

Se provi a modificare o eliminare uno dei ConfigMap predefiniti, otel-collector o otel-collector-google-cloud, otel-collector potrebbe avere un errore o un arresto anomalo perché non riesce a caricare richiesto per l'oggetto ConfigMap.

Soluzione:

Per personalizzare la configurazione dell'esportazione delle metriche, crea un ConfigMap denominato otel-collector-custom in config-management-monitoring.
interfaccia a riga di comando nomos 1.15.0 1.17.2

Risolto: nomos status e nomos bugreport non funzionano in un pod

Prima della versione 1.17.2 di nomos, nomos bugreport e nomos status potevano connettersi al cluster locale solo se eseguiti all'interno di un pod Kubernetes. Nella versione 1.17.2 di Nomos, il metodo di autorizzazione è stato modificato in modo da funzionare in modo più simile a kubectl. A causa di questa modifica, il cluster locale è scelto come target per impostazione predefinita. Puoi eseguire l'override specificando la variabile di ambiente KUBECONFIG.
Azioni

Conflitto tra Config Sync

Config Sync potrebbe essere rissa tra controller. con se stessa. Questo problema si verifica se imposti il valore predefinito per un campo facoltativo di una risorsa nel repository Git. Ad esempio, l'impostazione di apiGroup: "" per il soggetto di un RoleBinding attiva questo problema perché il campo apiGroup: "" è facoltativo e il valore predefinito è una stringa vuota. I valori predefiniti dei campi di stringa, booleani e interi sono "", false e 0 (rispettivamente).

Soluzione:

Rimuovi il campo dalla dichiarazione della risorsa.
Azioni

Config Sync in conflitto con le risorse di Config Connector

Potrebbe sembrare che Config Sync stia combattendo con Config Connector per una risorsa, ad esempio un StorageBucket. Questo problema si verifica se non imposti il valore di un campo facoltativo di una risorsa spec.lifecycleRule.condition.withState nella fonte attendibile.

Soluzione:

Puoi evitare questo problema aggiungendo il campo withState=ANY nella dichiarazione della risorsa. In alternativa, puoi abbandonarla e poi riacquistarla con l'annotazione cnrm.cloud.google.com/state-into-spec: absent.

Fonte di dati 1.17.3 1.18.3

Correzione: errore di autenticazione SSH di Git con GitHub

git-sync nella versione 4.2.1 presenta un bug che rimuove il nome utente dall'URL del repository quando si utilizza SSH, con conseguente esito negativo dell'autenticazione connessione a GitHub, il che richiede che l'utente sia git.

Il messaggio di errore di Git è: git-sync@github.com: Permission denied (publickey).\r\nfatal: Could not read from remote repository.

Soluzione:

Utilizza un altro metodo di autenticazione.
Fonte attendibile 1.16.1 1.16.2

Correzione: periodicamente non è possibile valutare il link all'origine

Config Sync può riscontrare problemi all'avvio del riconciliatore dal punto in cui si trova periodicamente non è in grado di valutare il link di origine. Questo problema si verifica perché git-sync non ha ancora clonato il repository di origine.

Nelle versioni 1.16.2 e successive, questo è un errore temporaneo, quindi registrato ma non segnalato come errore.
Fonte di dati 1.15.0 1.18.0

Correzione: credenziali di autenticazione periodicamente non valide per Cloud Source Repositories

Config Sync può generare errori periodicamente quando il token di autenticazione scade per Cloud Source Repositories. Questo problema è causato dal token refresh in attesa fino alla scadenza prima di aggiornare il token.

Nella versione 1.18.0 e successive, il token viene aggiornato alla prima richiesta entro cinque minuti dalla scadenza del token. In questo modo si evita che delle credenziali di autenticazione, a meno che le credenziali non siano effettivamente non valido.
Fonte attendibile 1.15.0 1.17.0

Risolto: errore di sincronizzazione del repository: scadenza del contesto superata

Nelle versioni precedenti alla 1.17.0, Config Sync ha controllato per impostazione predefinita del repository. Ciò potrebbe comportare il superamento del tempo di attesa della richiesta di recupero in repository di grandi dimensioni con molti commit.

Nella versione 1.17.0 e successive, il recupero di Git viene eseguito con --depth=1, che recupera solo l'ultimo commit. Questo accelera il recupero del codice sorgente, evita la maggior parte dei timeout e riduce il carico del server Git.

Se il problema persiste dopo l'upgrade, è probabile che la tua origine attendibile contenga molti file, che il server Git risponda lentamente o che si verifichi un altro problema di rete.
Sincronizzazione 1.15.0

Numero elevato di richieste PATCH inefficaci negli audit log

Config Sync Remediator utilizza Prova per rilevare la deviazione. Ciò può causare la visualizzazione delle richieste PATCH nel log di controllo, anche quando PATCH non è persistente, perché il log di controllo non distingue tra prove e richieste normali.

Soluzione:

Poiché l'audit log non può distinguere tra dry run e non dry run puoi ignorare le richieste PATCH.
Sincronizzazione 1.17.0 1.17.3

Correzione: Config Sync non riesce a recuperare il commit più recente da un ramo

In Config Sync versioni 1.17.0, 1.17.1 e 1.17.2, potresti si è verificato un problema per cui Config Sync non riesce a eseguire il pull del commit più recente dall'HEAD di un ramo specifico quando si fa riferimento allo stesso ramo più telecomandi e non sono sincronizzati. Ad esempio, Ramo main di un repository remoto che origin potrebbe essere prima dello stesso ramo nel repository remoto upstream, ma Config Sync recupera solo l'SHA di commit dall'ultima riga, che potrebbe non essere il commit più recente.

L'esempio seguente mostra come potrebbe presentarsi questo problema:

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

Nella versione 1.17.3 e successive, la dipendenza git-sync è stata aggiornata con un meccanismo di recupero diverso.

Se non puoi eseguire l'upgrade, puoi impostare la revisione Git (spec.git.revision) all'ultima SHA di commit a prescindere dal per il ramo Git (spec.git.branch). Per maggiori informazioni sulle configurazioni Git, consulta Configurazione per il repository Git.
Registry privato 1.19.0

Config Sync non utilizza il registro privato per i deployment dei riconciliatori

Config Sync deve sostituire le immagini di tutti i deployment quando è configurato un registro privato. Tuttavia, Config Sync non sostituisce il registry delle immagini per le immagini nei deployment del riconciliatore.

Soluzione:

Una soluzione alternativa a questo problema consiste nel configurare il mirror del registry delle immagini in containerd.

Sincronizzazione 1.17.0 1.18.3

Risolto il problema di arresto anomalo in loop dello strumento di riconciliazione di Config Sync

Nelle versioni 1.17.0 o successive di Config Sync, potresti riscontrare un problema per cui il riconciliatore non riesce a creare una configurazione rest in alcuni provider Kubernetes.

L'esempio seguente mostra come potrebbe presentarsi questo problema nei log dei riconciliatori:

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 Terraform versione 5.41.0

Non è possibile installare o eseguire l'upgrade di Config Sync utilizzando Terraform

La versione 5.41.0 di Terraform ha introdotto un nuovo campo in google_gke_hub_feature_membership: config_sync.enabled. Poiché il valore predefinito di questo campo è false, causa Le installazioni di Config Sync non riusciranno quando viene eseguito l'upgrade di Terraform alla versione 5.41.0.

Soluzione:

  • Se utilizzi la risorsa google_gke_hub_feature_membership, imposta manualmente config_sync.enabled su true.
  • Se utilizzi il sottomodulo acm, ti consigliamo di passare a un modo alternativo per installare Config Sync. Se non riesci a eseguire il passaggio, esegui l'upgrade alla v33.0.0.

Torna all'inizio

Passaggi successivi