Problemi noti di Config Sync

Correzione: metriche registrate per i pacchetti eliminati

Se elimini un oggetto RootSync o RepoSync, ma non elimini l'oggetto ResourceGroup con lo stesso nome, Config Sync continua a registrare le seguenti metriche per quell'oggetto 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

Soluzione:

Elimina l'oggetto ResourceGroup:

kubectl delete resourcegroup RESOURCE_GROUP_NAME -n config-management-system

Sostituisci RESOURCE_GROUP_NAME con il nome dell'oggetto ResourceGroup da eliminare. Per scoprire di più sulla ResourceGroup denominazione, consulta Oggetti ResourceGroup Controller e ResourceGroup.

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 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 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 sono 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.

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.

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.

Config Sync in conflitto con se stesso

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 una stringa vuota è il valore predefinito.apiGroup I valori predefiniti dei campi di stringa, booleani e interi sono "", false e 0 (rispettivamente).

Soluzione:

Rimuovi il campo dalla dichiarazione della risorsa.

Conflitto tra Config Sync e 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.

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.

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.

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 Config Sync 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
    

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
    

Correzione: l'annotazione di ignoramento della mutazione non viene rispettata

Un bug nel riconciliatore 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.

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 attivo, 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
    

Numero elevato di richieste PATCH non efficaci nei log di controllo

Lo strumento di correzione di Config Sync utilizza prove senza esecuzione 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:

Config Sync non utilizza il registry privato per i deployment del riconciliatore

Config Sync dovrebbe sostituire le immagini per 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.

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

Correzione: 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 race condition 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.

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

La versione 5.41.0 di Terraform ha introdotto un nuovo campo nella risorsa google_gke_hub_feature_membership: config_sync.enabled. Poiché il valore predefinito di questo campo è false, se non viene impostato esplicitamente su true, gli upgrade o le installazioni di Config Sync non riescono quando utilizzi Terraform 5.41.0 o versioni successive. In caso di questo problema, potresti anche visualizzare un messaggio di errore che indica git spec not included in configmanagement spec.

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.

Errori relativi ai dati mancanti nella dashboard di Config Sync nella Google Cloud console

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

Soluzione:

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

Correzione: Config Sync impedisce gli aggiornamenti delle risorse abbandonate

Prima della versione 1.21.0, un oggetto RootSync o RepoSync eliminato può lasciare diverse etichette e annotazioni che Config Sync utilizza per monitorare questi oggetti di risorse.

Queste etichette e annotazioni possono causare i seguenti effetti collaterali dopo l'eliminazione di un oggetto RootSync o RepoSync:

• Altri oggetti RepoSync non possono acquisire la proprietà di oggetti gestiti in precedenza.
• Se la prevenzione di deviazioni è attivata, Config Sync potrebbe rifiutare le modifiche alle risorse abbandonate.