Problemi noti di Config Sync

Correzione: metriche segnalate 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 segnalare 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 temporanea:

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 saperne di più sulla denominazione di ResourceGroup, consulta Controller ResourceGroup e oggetti ResourceGroup.

Reconciler non pianificabile

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

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

Se utilizzi cluster GKE in modalità standard, le richieste di risorse del reconciler sono impostate su un valore molto basso. Questa impostazione è stata scelta nel tentativo di consentire la pianificazione, anche se ciò comporterebbe la limitazione e un rallentamento delle prestazioni, in modo che Config Sync funzioni su cluster e nodi di piccole dimensioni. Tuttavia, nei cluster GKE Autopilot, le richieste del riconciliatore sono impostate su un valore più alto, per rappresentare in modo più realistico l'utilizzo durante la sincronizzazione.

Soluzione temporanea:

GKE Autopilot o Standard con 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 reconciler.

Esportazione non riuscita. Autorizzazione negata

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

Soluzione temporanea:

otel-collector registra gli errori se non hai configurato Cloud Monitoring o personalizzato i filtri delle metriche e Cloud Monarch.

otel-collector si arresta in modo anomalo 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 perché non è in grado di caricare il ConfigMap richiesto.

Soluzione temporanea:

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

Config Sync in conflitto con se stesso

Config Sync potrebbe sembrare in una lotta 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, booleano e intero sono "", false e 0 (rispettivamente).

Soluzione temporanea:

Rimuovi il campo dalla dichiarazione della risorsa.

Config Sync in conflitto con le risorse di Config Connector

Config Sync potrebbe sembrare in conflitto 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 temporanea:

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

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

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

Questo problema è causato dal fatto che la libreria oauth2 aggiorna il token di autenticazione solo dopo la scadenza del token.

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 temporanea:

L'errore dovrebbe risolversi al successivo tentativo di Config Sync di recuperare i dati dalla fonte attendibile.

Quando Config Sync ha generato errori più volte, i tentativi diventano meno frequenti. Per forzare Config Sync a riprovare prima, elimina il pod del riconciliatore. Questa azione fa sì che Config Sync ricrei il pod di riconciliazione e recuperi immediatamente i dati dalla fonte attendibile:

    kubectl delete pod -n config-management-system RECONCILER_NAME
    

git-sync cicli di arresto anomalo del container dopo l'isolamento di un file di blocco Git

Se vedi il container git-sync in un ciclo di arresti anomali con errori simili ai seguenti nel log del container git-sync, una precedente chiamata git potrebbe non essere riuscita e aver lasciato un file di blocco orfano nel container:

    {"logger":""..."msg":"repo contains lock file","error":null,"path":"/repo/source/.git/shallow.lock"}
    ...runtime error: invalid memory address or nil pointer dereference
    

Soluzione temporanea:

Per risolvere il problema, riavvia il pod del riconciliatore interessato per assegnargli un nuovo volume temporaneo:

    kubectl delete pod -n config-management-system RECONCILER_NAME
    

Corretto: file di blocco Git persistente

Se visualizzi un errore simile al seguente dal container git-sync, significa che una precedente chiamata git potrebbe non essere riuscita e aver lasciato un file di blocco persistente nel container:

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

Soluzione temporanea:

Per risolvere il problema, riavvia il pod del riconciliatore interessato per assegnargli un nuovo volume temporaneo:

    kubectl delete pod -n config-management-system RECONCILER_NAME
    

Corretto: l'annotazione di mutazione Ignora non viene rispettata

Un bug nel riconciliatore di Config Sync fa sì che applichi le 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 temporanea:

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.

Corretto: gli errori di rilevamento dell'API possono causare l'erronea classificazione degli oggetti gestiti come Not Found

Se il backend di un servizio API non è integro, può causare un errore di rilevamento dell'API. Se ciò si verifica durante l'avvio del controller ResourceGroup, dopo l'aggiornamento o la riprogrammazione, l'inizializzazione della cache delle risorse non riesce, causando la segnalazione di tutti gli oggetti gestiti come Not Found nello stato di ResourceGroup.

Questo problema si verifica spesso quando metrics-server non è integro.

Soluzione temporanea:

Riavvia il pod resource-group-controller dopo che metrics-server torna in stato integro:

    kubectl delete pod -n resource-group-system RESOURCE_GROUP_CONTROLLER_NAME
    

Numero elevato di richieste PATCH inefficaci nei log di controllo

Il correttore di Config Sync utilizza Dry-run per rilevare la deriva. Ciò può comportare la visualizzazione delle richieste PATCH nel log di controllo, anche quando PATCH non viene reso persistente, perché il log di controllo non distingue tra simulazioni e richieste normali.

Soluzione temporanea:

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 di ResourceGroup prima che il riconciliatore possa aggiornare la specifica ResourceGroup, causando l'errore KNV2009.

Soluzione temporanea:

Non esiste una soluzione alternativa per questo problema. L'errore dovrebbe risolversi da solo.

Config Sync non può essere installato o aggiornato 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 questo campo non è impostato esplicitamente su true, le installazioni o gli upgrade di Config Sync non vanno a buon fine quando si utilizza Terraform versione 5.41.0 o successive. Se si verifica questo problema, potresti anche visualizzare un messaggio di errore che indica git spec not included in configmanagement spec.

Soluzione temporanea:

• 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 cambiare versione, esegui l'upgrade alla versione v33.0.0.

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

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

Soluzione temporanea:

Se visualizzi questi tipi di errori nella console Cloud de Confiance sui 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 risorsa.

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 l'opzione Prevenzione di deviazioni è attivata, Config Sync potrebbe rifiutare le modifiche alle risorse abbandonate.

nomos CLI non supporta il plug-in di autenticazione oidc

Quando utilizzi lo strumento a riga di comando nomos, potresti visualizzare errori come no Auth Provider found for name "oidc". Questo problema può verificarsi quando utilizzi il plug-in di autenticazione oidc.

Soluzione temporanea:

Non è disponibile alcuna soluzione alternativa. Il plug-in di autenticazione oidc verrà aggiunto nuovamente in una release successiva.