Problemi noti di Config Sync

Questa pagina elenca i problemi noti relativi alle versioni supportate di Config Sync.

Molti dei problemi elencati qui sono stati risolti. La colonna 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.

Se partecipi al programma per sviluppatori Google, salva questa pagina per ricevere notifiche quando viene pubblicata una nota di rilascio relativa a questa pagina. Per approfondire, consulta Pagine salvate.

Per filtrare i problemi noti in base a una versione del 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

Riconciliatore non pianificabile

I riconciliatori di Config Sync richiedono quantità diverse di risorse, a seconda della configurazione di RootSync o RepoSync. Alcune 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, le richieste di risorse del riconciliatore sono impostate su un valore molto basso. Questa impostazione è stata scelta nel tentativo di consentire la pianificazione, anche se ciò potrebbe comportare un 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 di riconciliazione sono impostate su un valore più elevato per rappresentare in modo più realistico l'utilizzo durante la sincronizzazione.

Soluzione:

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 configuri manualmente le dimensioni dei nodi o delle istanze dei nodi, potresti dover modificare queste impostazioni per soddisfare i requisiti delle risorse del pod di riconciliazione.
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 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 in Cloud Monarch, ma questo filtro è stato configurato in modo errato, causando errori di trasformazione nei log otel-collector.
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:

otel-collector registra errori se non hai configurato Cloud Monitoring o disattivato Cloud Monitoring e Cloud Monarch.
Metriche 1.15.0

Arresto anomalo di otel-collector con configurazione personalizzata

Se provi a modificare o eliminare uno dei ConfigMap predefiniti, otel-collector o otel-collector-google-cloud, otel-collector potrebbe generare un errore o arrestarsi in modo anomalo a causa della mancata carica del ConfigMap richiesto.

Soluzione:

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

Correzione: 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 della configurazione specificando la variabile di ambiente KUBECONFIG.
Azioni

Conflitto tra Config Sync

Config Sync potrebbe sembrare in una situazione di lotta 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.apiGroup 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 risorsaspec.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 attendibile 1.17.3 1.18.3

Correzione: errore di autenticazione SSH di Git con GitHub

git-sync v4.2.1 ha un bug che rimuove il nome utente dall'URL del repository quando si utilizza SSH, causando l'errore di autenticazione quando si connette a GitHub, il che richiede all'utente di essere 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.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 dall'aggiornamento del token che attende la 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 evitato l'errore relativo alle credenziali di autenticazione non valide, a meno che le credenziali non siano effettivamente non valide.
Fonte attendibile 1.15.0 1.17.0

Correzione: errore durante la sincronizzazione del repository: scadenza del contesto superata

Nelle versioni precedenti alla 1.17.0, Config Sync eseguiva il check out dell'intera cronologia del repository Git per impostazione predefinita. 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. In questo modo, viene accelerato il recupero del codice sorgente, vengono evitati la maggior parte dei timeout e viene ridotto 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.
Fonte attendibile 1.13.0 1.20.1

Correzione: impossibile generare il token di accesso per l'origine OCI

Quando Config Sync è configurato per utilizzare OCI come fonte attendibile e per eseguire l'autenticazione con Workload Identity Federation per GKE, Config Sync potrebbe occasionalmente riscontrare errori KNV2004 temporanei quando tenta di autenticarsi con il registry dei container.

Questo problema è causato dal fatto che la libreria oauth2 aggiorna il token di autenticazione solo dopo che è già scaduto.

Il messaggio di errore potrebbe includere il seguente testo: "oauth2/google: unable to generate access token" o "ID Token issued at (xxx) is stale to sign-in."

Soluzione:

L'errore dovrebbe risolversi alla successiva sincronizzazione della configurazione quando tenterà di recuperare i dati dalla fonte attendibile.

Quando Config Sync genera errori più volte, le ripetizioni diventano meno frequenti. Per forzare Config Sync a riprovare prima, elimina il pod MediaSync. Questa azione fa sì che Config Sync ricrei il pod di riconciliazione e esegua immediatamente il recupero dalla fonte attendibile:

    kubectl delete pod -n config-management-system RECONCILER_NAME
Sostituisci RECONCILER_NAME con il nome del riconciliatore dell'oggetto RootSync o RepoSync.
Fonte attendibile 1.19.0 1.20.0

Risolto: file di blocco Git inutilizzato

Se nel contenitore git-sync viene visualizzato un errore simile al seguente, è possibile che un'esecuzione precedente di git sia andata a buon fine e abbia lasciato un file di blocco pendente nel contenitore:

    KNV2004: error in the git-sync container: ... fatal: Unable to create '/repo/source/.git/shallow.lock': File exists. ...

Soluzione:

Per risolvere il problema, riavvia il pod di riconciliazione interessato per assegnare un nuovo volume temporaneo:

    kubectl delete pod -n config-management-system RECONCILER_NAME
Sostituisci RECONCILER_NAME con il nome del riconciliatore dell'oggetto RootSync o RepoSync.
Sincronizzazione 1.7.0

Ignora annotazione di mutazione non rispettata

Un bug nell'applicatore di Config Sync causa l'applicazione delle modifiche dalle configurazioni dichiarate anche quando è presente l'annotazione client.lifecycle.config.k8s.io/mutation. Ciò potrebbe causare la sovrascrittura dello stato dell'oggetto nel cluster.

Soluzione:

Puoi interrompere la gestione dell'oggetto gestito aggiungendo l'annotazione configmanagement.gke.io/managed: disabled. Tuttavia, la disattivazione della gestione impedisce a Config Sync di ricreare l'oggetto se viene eliminato dal cluster. Inoltre, impedisce l'applicazione di ulteriori aggiornamenti nella fonte attendibile.
Sincronizzazione 1.5.0 1.20.1

Correzione: gli errori di rilevamento dell'API possono causare il contrassegno errato degli oggetti gestiti come Not Found

Se il backend di un servizio API non è in stato operativo, la scoperta dell'API può generare un errore. Se ciò si verifica durante l'avvio del controller ResourceGroup, dopo l'aggiornamento o la riprogrammazione, la cache delle risorse non verrà inizializzata, causando la segnalazione di tutti gli oggetti gestiti come Not Found nello stato del gruppo di risorse.

Questo problema si verifica spesso quando metrics-server non è in stato di salute.

Soluzione:

Riavvia il pod resource-group-controller dopo che metrics-server è tornato in stato normale:

    kubectl delete pod -n resource-group-system RESOURCE_GROUP_CONTROLLER_NAME
Sostituisci RESOURCE_GROUP_CONTROLLER_NAME con il nome del controller ResourceGroup, che corrisponde al nome di RootSync o RepoSync per quel pacchetto.
Sincronizzazione 1.15.0

Numero elevato di richieste PATCH non efficaci nei log di controllo

Lo strumento di correzione di Config Sync utilizza prove non attive per rilevare la deriva. 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é il log di controllo non è in grado di distinguere tra richieste di prova simulata e non, 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

Nelle versioni 1.17.0, 1.17.1 e 1.17.2 di Config Sync potresti riscontrare un problema per cui Config Sync non riesce a recuperare l'ultimo commit dal commit HEAD di un ramo specifico quando lo stesso ramo è richiamato in più origini remote e non sono sincronizzati. Ad esempio, il ramo main di un repository remoto origin potrebbe essere avanti rispetto allo stesso ramo nel repository remoto upstream, ma Config Sync recupera solo l'SHA del commit dalla riga finale, che potrebbe non essere l'ultimo commit.

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 riesci a eseguire l'upgrade, puoi impostare la revisione Git (spec.git.revision) sull'SHA del commit più recente, indipendentemente dal valore impostato per il branch 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 registry privato per i deployment del riconciliatore

Config Sync deve sostituire le immagini per tutti i deployment quando è stato 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

Corretto: il riconciliatore di Config Sync è in crashloop

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 essere questo problema nei log del riconciliatore:

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
Sincronizzazione 1.7.0

Impossibile scrivere l'inventario aggiornato nel cluster

Se Config Sync non riesce ad aggiornare lo stato di un oggetto ResourceGroup, potresti riscontrare un errore intermittente nei log del riconciliatore simile al seguente:

    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

Questo errore è dovuto a una condizione di gara tra il riconciliatore e il controller ResourceGroup. Il controller ResourceGroup potrebbe aggiornare lo stato del gruppo di risorse prima che il riconciliatore possa aggiornare la specifica del gruppo di risorse, causando l'errore KNV2009.

Soluzione:

Per questo problema non è disponibile una soluzione alternativa. L'errore dovrebbe risolversi da solo.
Terraform Versione Terraform 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, le installazioni di Config Sync non riescono 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.

Console Google Cloud

Errori relativi alla mancanza di dati nella dashboard di Config Sync nella console Google Cloud

Potresti visualizzare errori come "Dati mancanti" o "Credenziali del cluster non valide" per i cluster Config Sync nelle dashboard della console Google Cloud. Questo problema può verificarsi quando non hai eseguito l'accesso ai tuoi cluster GDC (VMware) o GDC (bare metal).

Soluzione:

Se visualizzi questi tipi di errori nella console Google Cloud sui tuoi cluster GDC (VMware) o GDC (bare metal), assicurati di aver eseguito l'accesso ai cluster con GKE Identity Service o Connect Gateway.

Torna all'inizio

Passaggi successivi