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, eseguire l'upgrade alla versione elencata 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à componente 1.15.0 1.17.0

Risolto: OOM del container riconciliatore chiuso su AutoPilot

Nei cluster Autopilot, i container dei componenti 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 puoi eseguire l'upgrade alla versione 1.17.0 o successiva, specifica un limite di memoria più elevato utilizzando override delle risorse.

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

Riconciliatore non pianificabile

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

Se un riconciliatore non è pianificabile, potrebbe essere dovuto alla richiesta di maggiori rispetto a 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 comporterebbe limitazioni e rallentamenti in modo che Config Sync funzioni su cluster di piccole dimensioni 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 GKE Standard con provisioning automatico dei nodi dovrebbe poter vedere quante risorse sono richieste e creare di nodi di dimensioni adeguate 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 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 di TCP.

Errori KNV 1.15.0 1.16.0, Kubernetes versione 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

Risoluzione: 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, con conseguente aumento del 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 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 type e commit etichette a molte metriche. Queste etichette hanno aumentato la cardinalità delle metriche, con conseguente aumento del 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 otel-collector.

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

Esportazione non riuscita. Autorizzazione negata

Per impostazione predefinita, quando il gestore del riconciliazione rileva 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 di nomos versione 1.17.2, nomos bugreport e nomos status ha potuto connettersi al cluster locale solo quando all'interno di un pod Kubernetes. In nomos versione 1.17.2, l'autorizzazione è stato modificato per funzionare più come kubectl. Per questo motivo modifica, il cluster locale viene scelto come target per impostazione predefinita. Puoi eseguire l'override specificando la variabile di ambiente KUBECONFIG.
Azioni

Config Sync combatte con se stesso

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

Soluzione:

Rimuovi il campo dalla dichiarazione della risorsa.
Azioni

Config Sync combatte con le risorse di Config Connector

Può sembrare che Config Sync combattimento 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 nella fonte attendibile.

Soluzione:

Puoi evitare questo problema aggiungendo il campo withState=ANY sulla dichiarazione della risorsa. In alternativa, puoi abbandonare e quindi riacquisire la risorsa Annotazione cnrm.cloud.google.com/state-into-spec: absent.

Fonte di dati 1.17.3

Errore di autenticazione Git SSH 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:

Esegui il downgrade alla versione 1.17.2 o utilizza un metodo di autenticazione diverso.
Fonte di dati 1.16.1 1.16.2

Risolto: periodicamente non è stato possibile valutare il link di 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 codice sorgente.

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

Risolto il problema: periodicamente credenziali di autenticazione non valide per Cloud Source Repositories

Config Sync può inviare periodicamente errori 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 viene delle credenziali di autenticazione, a meno che le credenziali non siano effettivamente non valido.
Fonte di dati 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. Questo potrebbe determinare i tempi della richiesta di recupero su repository di grandi dimensioni con molti commit.

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 la fonte attendibile contiene molti file, il server Git risponde lentamente, o c'è qualche 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 di PATCH richieste in nell'audit log, anche se PATCH non è persistente, perché l'audit log non fa distinzione tra dry run 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

Risolto: Config Sync non riesce a eseguire il pull del 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 impostato per il ramo Git (spec.git.branch). Per maggiori informazioni sulle configurazioni Git, consulta Configurazione per il repository Git.
Registro privato

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 registry privato. Tuttavia, Config Sync non sostituisce del registro delle immagini nei deployment del riconciliatore.

Soluzione:

Una soluzione alternativa a questo problema è configurare il specchio del registro di sistema di immagini in containerd.

Torna all'inizio

Passaggi successivi