Problemi noti di Config Sync

Contenitore di riconciliazione OOM interrotto su AutoPilot

Nei cluster Autopilot, i container dei componenti Config Sync hanno limiti delle risorse impostati per CPU e memoria. Sotto carico, questi container possono essere terminati da kubelet o kernel per utilizzare troppa memoria.

Soluzione alternativa:

Esegui l'upgrade alla versione 1.17.0 o successive. In Config Sync versione 1.17.0, i limiti predefiniti di CPU e memoria sono stati modificati per evitare errori di memoria insufficiente nella maggior parte dei casi d'uso.

Se non puoi eseguire l'upgrade, specifica un limite di memoria più elevato utilizzando gli override delle risorse.

Riconciliatore non pianificabile

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

Se un riconciliazione non è pianificabile, potrebbe essere dovuto alla richiesta di più risorse di quelle disponibili sui tuoi nodi.

Se utilizzi cluster GKE in modalità standard, il numero di richieste di risorse del riconciliatore è impostato su un valore molto basso. Questa impostazione è stata scelta nel tentativo di consentire la pianificazione, anche se avrebbe limitato e rallentare le prestazioni, in modo che Config Sync funzioni su cluster di piccole dimensioni e nodi piccoli. Tuttavia, sui cluster GKE Autopilot, le richieste del riconciliazione sono impostate su un livello superiore, per rappresentare in modo più realistico l'utilizzo durante la sincronizzazione.

Soluzione alternativa:

GKE Autopilot o GKE Standard con il provisioning automatico dei nodi abilitato dovrebbe essere in grado di vedere quante risorse vengono richieste e creare nodi di dimensioni appropriate per consentire la pianificazione. Tuttavia, se stai configurando manualmente i nodi o le dimensioni delle istanze dei nodi, potresti dover regolare queste impostazioni per soddisfare i requisiti delle risorse dei pod del riconciliazione.

Errore KNV1067 anche se la configurazione è stata applicata

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

Soluzione alternativa:

Se il tuo 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 di TCP.

Impossibile riconciliare Config Sync con errore KNV2002

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

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

Soluzione alternativa:

Per risolvere il problema, esegui l'upgrade del cluster GKE alla versione 1.28 o successiva di GKE oppure esegui l'upgrade di Config Sync alla versione 1.16.0 o successive. Entrambe queste versioni contengono correzioni al problema del client go.

Esportazione non riuscita: etichette delle metriche non riconosciute

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, con un conseguente aumento del numero di metriche da esportare. È stata aggiunta anche l'elaborazione degli attributi per filtrare queste etichette durante l'esportazione in Cloud Monarch. Tuttavia, questo filtro non era configurato correttamente, causando errori di trasformazione nei log otel-collector.

Soluzione alternativa:

Esegui l'upgrade alla versione 1.17.2 o successive.

Cardinalità ed errori di 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, con un conseguente aumento del numero di metriche da esportare. È stata aggiunta anche l'elaborazione degli attributi per filtrare queste etichette durante l'esportazione in Cloud Monarch. Tuttavia, questo filtro non era configurato correttamente, causando errori di trasformazione nei log otel-collector.

Soluzione alternativa:

Esegui l'upgrade alla versione 1.16.1 o successive. Nella versione 1.16.1, il campo del tipo è stato rimosso, il filtro è stato corretto e il campo di commit è stato inoltre filtrato da Cloud Monitoring. In questo modo sono stati corretti gli errori e ridotto la cardinalità delle metriche.

Esportazione non riuscita. Autorizzazione negata

Per impostazione predefinita, quando riconciliar-manager rileva le Credenziali predefinite dell'applicazione, otel-collector è configurato per esportare le metriche in Prometheus, Cloud Monitoring e Monarch.

Soluzione alternativa:

otel-collector registra gli errori se non hai configurato Cloud Monitoring o Cloud Monitoring disabilitato e Cloud Monarch.

arresto anomalo di otel-collector con una configurazione personalizzata

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

Soluzione alternativa:

Per personalizzare la configurazione dell'esportazione delle metriche, crea un ConfigMap denominato otel-collector-custom nello spazio dei nomi config-management-monitoring.

nomos status e nomos bugreport non funzionano in un pod

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

Soluzione alternativa:

Esegui l'upgrade a nomos versione 1.17.2.

Config Sync è in conflitto con se stesso

Config Sync potrebbe sembrare che si sia verificato un ritardo tra controller. con se stesso. 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 l'oggetto di un RoleBinding attiva questa operazione perché il campo apiGroup è facoltativo e una stringa vuota è il valore predefinito. I valori predefiniti dei campi stringa, booleani e interi sono "", false e 0 (rispettivamente).

Soluzione alternativa:

Rimuovi il campo dalla dichiarazione della risorsa.

Combattimento di Config Sync con le risorse di Config Connector

Potrebbe sembrare che Config Sync stia concorrendo con Config Connector su 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 nell'origine attendibile.

Soluzione alternativa:

Per evitare questo problema, aggiungi il campo withState=ANY alla dichiarazione della risorsa. In alternativa, puoi abbandonare e poi riacquisire la risorsa con l'annotazione cnrm.cloud.google.com/state-into-spec: absent.

Impossibilità periodica di valutare il link della fonte

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

Soluzione alternativa:

Aggiorna Config Sync alla versione 1.16.2 o successive. In queste versioni si tratta di un errore temporaneo, quindi viene registrato ma non segnalato come errore.

Credenziali di autenticazione periodicamente non valide per Cloud Source Repositories

Config Sync può restituire errori periodici alla scadenza del token di autenticazione per Cloud Source Repositories. Questo problema è causato dall'aggiornamento del token che attende fino alla scadenza prima di aggiornare il token.

Soluzione alternativa:

Aggiorna Config Sync alla versione 1.18.0 o successive. In queste versioni, il token viene aggiornato alla prima richiesta entro cinque minuti dalla scadenza del token. In questo modo, si evita l'errore di credenziali di autenticazione non valide, a meno che le credenziali non siano effettivamente valide.

Errore durante la sincronizzazione del repository: scadenza del contesto superata

Nelle versioni precedenti alla 1.17.0, Config Sync ha controllato per impostazione predefinita la cronologia completa dei repository Git. Ciò potrebbe causare il timeout della richiesta di recupero su repository di grandi dimensioni con molti commit.

Soluzione alternativa:

Esegui l'upgrade alla versione 1.17.0 o successive. Nella versione 1.17.0 e successive, il recupero Git viene eseguito con --depth=1, che recupera solo il commit più recente. 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 l'origine attendibile contenga molti file, che il tuo server Git risponda lentamente o che ci sia qualche altro problema di rete.

Numero elevato di richieste PATCH inefficaci negli audit log

Il Remediator di Config Sync utilizza la modalità di prova per rilevare le deviazioni. Di conseguenza, le richieste PATCH possono essere visualizzate nell'audit log, anche quando PATCH non è persistente, perché l'audit log non fa distinzione tra le esecuzioni di prova e le richieste normali.

Soluzione alternativa:

Config Sync non riesce a eseguire il pull dell'ultimo commit da un ramo

In Config Sync 1.17.0 e versioni successive, potresti riscontrare un problema per cui Config Sync non riesce a eseguire il pull dell'ultimo commit dall'HEAD di un ramo specifico quando viene fatto riferimento allo stesso ramo in più telecomandi e questi non sono sincronizzati. Ad esempio, il ramo main di un repository remoto origin potrebbe essere davanti allo stesso ramo nel repository remoto upstream, ma Config Sync recupera solo la SHA del commit dall'ultima riga, che potrebbe non essere l'ultimo commit.

L'esempio seguente mostra il possibile aspetto di 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

Soluzione alternativa:

Per limitare il problema, puoi impostare la revisione Git (spec.git.revision) sull'ultima SHA del commit, indipendentemente dal valore impostato per il ramo Git (spec.git.branch). Per maggiori informazioni sulle configurazioni Git, consulta Configurazione per il repository Git.