Risolvi i problemi di Config Connector

Questa pagina descrive le tecniche di risoluzione dei problemi che puoi utilizzare per risolvere i problemi di Config Connector e i problemi comuni che potresti riscontrare durante l'utilizzo del prodotto.

Controllare lo stato e le condizioni di Config Connector

Controlla la versione di Config Connector

Esegui questo comando per ottenere la versione di Config Connector installata e fai riferimento alle note di rilascio per verificare che la versione in esecuzione supporti le funzionalità e le risorse che vuoi utilizzare:

kubectl get ns cnrm-system -o jsonpath='{.metadata.annotations.cnrm\.cloud\.google\.com/version}'

Controllare lo stato e gli eventi della risorsa

In genere, puoi determinare il problema con le risorse Config Connector controllando lo stato delle risorse in Kubernetes. Controllare lo stato e gli eventi di una risorsa è particolarmente utile per determinare se Config Connector non è riuscito a riconciliare la risorsa e il motivo per cui la riconciliazione non è riuscita.

Verifica che Config Connector sia in esecuzione

Per verificare che Config Connector sia in esecuzione, controlla che tutti i relativi pod siano READY:

kubectl get pod -n cnrm-system

Output di esempio:

NAME                                            READY   STATUS    RESTARTS   AGE
cnrm-controller-manager-0                       1/1     Running   0          1h
cnrm-deletiondefender-0                         1/1     Running   0          1h
cnrm-resource-stats-recorder-77dc8cc4b6-mgpgp   1/1     Running   0          1h
cnrm-webhook-manager-58496b66f9-pqwhz           1/1     Running   0          1h
cnrm-webhook-manager-58496b66f9-wdcn4           1/1     Running   0          1h

Se hai installato Config Connector in modalità con spazio dei nomi, avrai un pod controller (cnrm-controller-manager) per ogni spazio dei nomi responsabile della gestione delle risorse Config Connector in questo spazio dei nomi.

Puoi controllare lo stato del pod controller responsabile di uno spazio dei nomi specifico eseguendo:

kubectl get pod -n cnrm-system \
    -l cnrm.cloud.google.com/scoped-namespace=NAMESPACE \
    -l cnrm.cloud.google.com/component=cnrm-controller-manager

Sostituisci NAMESPACE con il nome dello spazio dei nomi.

Controllare i log del controller

Il pod controller registra informazioni ed errori relativi alla riconciliazione delle risorse Config Connector.

Puoi controllare i log del pod del controller eseguendo:

kubectl logs -n cnrm-system \
    -l cnrm.cloud.google.com/component=cnrm-controller-manager \
    -c manager

Se hai installato Config Connector in namespaced-mode, il comando precedente mostra i log di tutti i pod controller combinati. Puoi controllare i log del pod controller per uno spazio dei nomi specifico eseguendo:

kubectl logs -n cnrm-system \
    -l cnrm.cloud.google.com/scoped-namespace=NAMESPACE \
    -l cnrm.cloud.google.com/component=cnrm-controller-manager \
    -c manager

Sostituisci NAMESPACE con il nome dello spazio dei nomi.

Scopri di più su come esaminare ed eseguire query sui log di Config Connector.

Abbandona e acquisisci la risorsa

In alcuni casi, potrebbe essere necessario aggiornare un campo immutabile in una risorsa. Poiché non puoi modificare i campi immutabili, devi abbandonare e poi acquisire la risorsa:

1. Aggiorna la configurazione YAML della risorsa Config Connector e imposta l'annotazione cnrm.cloud.google.com/deletion-policy su abandon.
2. Applica la configurazione YAML aggiornata per aggiornare la policy di eliminazione della risorsa Config Connector.
3. Abbandona la risorsa Config Connector.
4. Aggiorna i campi immutabili che devono essere modificati nella configurazione YAML.
5. Applica la configurazione YAML aggiornata per acquisire la risorsa abbandonata.

Risolvi i problemi in base al tipo

Utilizza la tabella seguente per risolvere il problema in base al tipo di sintomo.

Tipo di problema	Problemi comuni
Riconciliazione	La risorsa continua ad aggiornarsi ogni 5-15 minuti La risorsa non ha uno stato KNV2005: syncer aggiorna eccessivamente la risorsa Risorsa eliminata da Config Connector Controller Pod OOMKilled
Eliminazione	Eliminazioni di spazi dei nomi bloccate al Terminating Eliminazioni di risorse bloccate al DeleteFailed dopo l'eliminazione del progetto
Autorizzazioni	Metadati di Compute Engine non definiti Errore 403: Request had insufficient authentication scopes 403 Vietato: il chiamante non dispone dell'autorizzazione Errore 403: al chiamante manca l'autorizzazione IAM Errore di aggiornamento con IAMPolicy, IAMPartialPolicy e IAMPolicyMember
Installazione e upgrade	Versione non supportata nelle installazioni del componente aggiuntivo Config Connector failed calling webhook PodSecurityPolicy impedisce gli upgrade
Configurazione	Impossibile apportare modifiche ai campi immutabili Nessuna corrispondenza per il tipo "Foo" Le etichette non vengono propagate alla risorsa Google Cloud Errore dovuto a caratteri speciali nel nome della risorsa Impossibile rimuovere i campi dalla specifica della risorsa

Riconciliazione

La sezione seguente elenca i problemi comuni relativi alla riconciliazione delle risorse da parte di Config Connector.

La risorsa continua ad aggiornarsi ogni 5-15 minuti

Sintomo

La risorsa Config Connector passa continuamente dallo stato UpToDate allo stato Updating ogni 5-10 minuti.

Causa

È probabile che Config Connector rilevi differenze involontarie tra lo stato desiderato e lo stato effettivo della risorsa, causando l'aggiornamento costante della risorsa da parte di Config Connector.

Risoluzione

Innanzitutto, verifica di non avere sistemi esterni che modificano costantemente Config Connector o la risorsa (ad esempio pipeline CI/CD, controller personalizzati, cron job e così via). Google Cloud

Se il comportamento non è dovuto a un sistema esterno, verifica se Google Cloud sta modificando uno dei valori specificati nella risorsa Config Connector. Ad esempio, in alcuni casi, Google Cloud modifica la formattazione (ad esempio, la capitalizzazione) dei valori dei campi, il che comporta una differenza tra lo stato desiderato e lo stato effettivo della risorsa.

Ottieni lo stato della risorsa Google Cloud utilizzando l'API REST (ad esempio, per ContainerCluster) o Google Cloud CLI. Quindi, confronta questo stato con la risorsa Config Connector. Cerca i campi i cui valori non corrispondono, poi aggiorna la risorsa Config Connector in modo che corrispondano. In particolare, cerca i valori riformattati da Google Cloud. Ad esempio, vedi i problemi di GitHub #578 e #294.

Tieni presente che questo non è un metodo perfetto, poiché i modelli di risorse Config Connector eGoogle Cloud sono diversi, ma dovrebbe consentirti di rilevare la maggior parte dei casi di differenze non intenzionali.

Se non riesci a risolvere il problema, consulta la sezione Ulteriore assistenza.

La risorsa non ha uno stato

Sintomo

Le tue risorse non hanno un campo status.

Causa

È probabile che Config Connector non sia in esecuzione correttamente.

Risoluzione

Verifica che Config Connector sia in esecuzione.

KNV2005: syncer excessively updating resource

Sintomo

Utilizzi Config Sync e visualizzi errori KNV2005 per le risorse Config Connector, simili ai seguenti:

KNV2005: detected excessive object updates, approximately 6 times per
minute. This may indicate Config Sync is fighting with another controller over
the object.

Causa

È probabile che Config Sync e Config Connector stiano litigando per la risorsa.

Si dice che Config Sync e Config Connector "si contendono" una risorsa se continuano ad aggiornare gli stessi campi con valori diversi. L'aggiornamento di uno attiva l'altro per agire e aggiornare la risorsa, il che fa sì che l'altro agisca e aggiorni la risorsa, e questo si ripete senza fine.

I combattimenti non sono un problema per la maggior parte dei campi. I campi specificati in Config Sync non vengono modificati da Config Connector. Allo stesso modo, i campi non specificati in Config Sync e impostati come predefiniti da Config Connector vengono ignorati da Config Sync. Pertanto, per la maggior parte dei campi, Config Sync e Config Connector non dovrebbero dover aggiornare lo stesso campo.

Un'eccezione sono i campi elenco. Analogamente a come Config Connector può impostare i campi secondari predefiniti nei campi oggetto, può anche impostare i campi secondari predefiniti negli oggetti all'interno degli elenchi. Tuttavia, poiché i campi elenco nelle risorse Config Connector sono atomici, l'impostazione predefinita dei campi secondari viene considerata come una modifica dell'intero valore dell'elenco.

Pertanto, Config Sync e Config Connector "si contendono" una risorsa se Config Sync imposta un campo elenco e Config Connector imposta come predefinito qualsiasi sottocampo all'interno di questo elenco.

Risoluzione

Per risolvere il problema, hai a disposizione le seguenti opzioni:

1. Aggiorna il manifest della risorsa nel repository Config Sync in modo che corrisponda a ciò che Config Connector sta tentando di impostare per la risorsa.

   Un modo per farlo è interrompere temporaneamente la sincronizzazione delle configurazioni, attendere che Config Connector termini la riconciliazione della risorsa e poi aggiornare il manifest della risorsa in modo che corrisponda alla risorsa sul server API Kubernetes.

2. Impedisci a Config Sync di reagire agli aggiornamenti della risorsa sul server API Kubernetes impostando l'annotazione client.lifecycle.config.k8s.io/mutation su ignore. Scopri di più su come fare in modo che Config Sync ignori le modifiche agli oggetti.

3. Impedisci a Config Connector di aggiornare completamente la specifica della risorsa impostando l'annotazione cnrm.cloud.google.com/state-into-spec su absent nella risorsa. Questa annotazione non è supportata per tutte le risorse. Per verificare se la tua risorsa supporta l'annotazione, consulta la pagina di riferimento della risorsa corrispondente. Scopri di più sull'annotazione.

Risorsa eliminata da Config Connector

Sintomo

Una risorsa è stata eliminata dal cluster e sospetti che sia stata eliminata da Config Connector.

Causa

Config Connector non elimina mai le risorse senza una causa esterna. Ad esempio, l'esecuzione di kubectl delete, l'utilizzo di strumenti di gestione della configurazione come Argo CD o l'utilizzo di un client API personalizzato possono causare l'eliminazione delle risorse.

Un malinteso comune è che Config Connector abbia avviato ed eliminato alcune delle risorse nel tuo cluster. Ad esempio, se utilizzi Config Connector, potresti notare richieste di eliminazione da Config Connector controller manager per determinate risorse dai messaggi di log dei container o dai log di controllo del cluster Kubernetes. Queste richieste di eliminazione sono il risultato di trigger esterni e Config Connector sta tentando di riconciliarle.

Risoluzione

Per determinare il motivo per cui una risorsa è stata eliminata, devi esaminare la prima richiesta di eliminazione inviata alla risorsa corrispondente. Il modo migliore per esaminare questo problema è esaminare i log di controllo del cluster Kubernetes.

Ad esempio, se utilizzi GKE, puoi utilizzare Cloud Logging per eseguire query per gli audit log del cluster GKE. Ad esempio, se vuoi cercare le richieste di eliminazione iniziali per una risorsa BigQueryDataset denominata foo nello spazio dei nomi bar, esegui una query come la seguente:

resource.type="k8s_cluster"
resource.labels.project_id="my-project-id"
resource.labels.cluster_name="my-cluster-name"
protoPayload.methodName="com.google.cloud.cnrm.bigquery.v1beta1.bigquerydatasets.delete"
protoPayload.resourceName="bigquery.cnrm.cloud.google.com/v1beta1/namespaces/bar/bigquerydatasets/foo"

Utilizzando questa query, cercherai la prima richiesta di eliminazione e poi controllerai authenticationInfo.principalEmail di questo messaggio del log di eliminazione per determinare la causa dell'eliminazione.

Controller Pod OOMKilled

Sintomo

Viene visualizzato un errore OOMKilled in un pod controller Config Connector. Lo stato del pod potrebbe essere OOMKilled o Terminating.

Causa

Un container o l'intero pod è stato terminato perché ha utilizzato più memoria del consentito. Puoi verificarlo eseguendo il comando kubectl describe:

kubectl describe pod POD_NAME -n cnrm-system

Sostituisci POD_NAME con il pod per cui stai risolvendo i problemi.

Inoltre, l'analisi approfondita dei log degli eventi del pod può rivelare eventuali occorrenze di eventi correlati a OOM.

Risoluzione

Per risolvere questo problema, puoi utilizzare la risorsa personalizzata ControllerResource per aumentare la richiesta di memoria e il limite di memoria per il pod.

Eliminazione

La sezione seguente elenca i problemi comuni relativi alle operazioni di eliminazione avviate dall'utente che possono causare conflitti con Config Connector.

Eliminazione dello spazio dei nomi bloccata su "Terminating"

Sintomo

L'eliminazione di uno spazio dei nomi è bloccata nella fase Terminating.

Causa

Questo problema può verificarsi se hai installato Config Connector in modalità con spazio dei nomi e se ConfigConnectorContext dello spazio dei nomi è stato eliminato prima che tutte le risorse Config Connector in quello spazio dei nomi vengano eliminate. Quando viene eliminato il ConfigConnectorContext di uno spazio dei nomi, Config Connector viene disattivato per quello spazio dei nomi, il che impedisce l'eliminazione delle risorse Config Connector rimanenti.

Risoluzione

Per risolvere il problema, devi eseguire una pulizia forzata e poi eliminare manualmente le risorse Google Cloud sottostanti.

Per risolvere questo problema in futuro, elimina solo ConfigConnectorContext dopo che tutte le risorse Config Connector nel relativo spazio dei nomi sono state eliminate da Kubernetes. Evita di eliminare interi spazi dei nomi prima che tutte le risorse Config Connector in quello spazio dei nomi siano state eliminate, poiché ConfigConnectorContext potrebbe essere eliminato per primo.

L'eliminazione delle risorse è bloccata su "DeleteFailed" dopo l'eliminazione del progetto

Sintomo

L'eliminazione di una risorsa Config Connector non riesce con lo stato DeleteFailed.

Causa

Questo problema può verificarsi se un Google Cloud progetto viene eliminato prima della risorsa.

Risoluzione

Per risolvere il problema, ripristina il progetto su Google Cloud per consentire a Config Connector di eliminare le risorse secondarie rimanenti da Kubernetes. In alternativa, puoi eseguire una pulizia forzata.

Per risolvere questo problema in futuro, elimina i progetti solo dopo che tutte le risorse Config Connector secondarie sono state eliminate da Kubernetes. Google Cloud Evita di eliminare interi spazi dei nomi che potrebbero contenere sia una risorsa Project sia le relative risorse Config Connector figlio, poiché la risorsa Project potrebbe essere eliminata per prima.

Autorizzazioni e autenticazione

La sezione seguente elenca i problemi comuni relativi alle autorizzazioni e all'autenticazione.

Metadati di Compute Engine non definiti

Sintomo

La risorsa Config Connector ha lo stato UpdateFailed con un messaggio che indica che i metadati di Compute Engine non sono definiti, simile al seguente errore:

Update call failed: error fetching live state: error reading underlying
resource: summary: Error when reading or editing SpannerInstance
"my-project/my-spanner- instance": Get
"https://spanner.googleapis.com/v1/projects/my-project/instances/my-spanner-instance?alt=json":
metadata: Compute Engine metadata "instance/service-accounts/default/token?
scopes=https%!A(MISSING)%!F(MISSING)%!F(MISSING)www.googleapis.com%!F(MISSING)auth%!F(MISSING)compute%!C(MISSING)https%!A(MISSING)%!F(MISSING)%!F(MISSING)www.googleapis.com%!F(MISSIN
G)auth%!F(MISSING)cloud-platform%!C(MISSING)https%!A(MISSING)%!F(MISSING)%!F(MISSING)www.googleapis.com%!F(MISSING)auth%!F(MISSING)cloud-identity%!C(MISSING)https%!A(MISSING)%!F(MISS
ING)%!F(MISSING)www.googleapis.com%!F(MISSING)auth%!F(MISSING)ndev.clouddns.readwrite%!C(MISSING)https%!A(MISSING)%!F(MISSING)%!F(MISSING)www.googleapis.com%!F(MISSING)auth%!F(MISSIN
G)devstorage.full_control%!C(MISSING)https%!A(MISSING)%!F(MISSING)%!F(MISSING)www.googleapis.com%!F(MISSING)auth%!F(MISSING)userinfo.email%!C(MISSING)https%!A(MISSING)%!F(MISSING)%!F
(MISSING)www.googleapis.com%!F(MISSING)auth%!F(MISSING)drive.readonly" not
defined, detail:

Causa

È probabile che il account di servizio IAM utilizzato da Config Connector non esista.

Risoluzione

Per risolvere il problema, assicurati che il account di servizio IAM utilizzato da Config Connector esista.

Per risolvere il problema in futuro, assicurati di seguire le istruzioni di installazione di Config Connector.

Errore 403: Request had insufficient authentication scopes

Sintomo

La risorsa Config Connector ha lo stato UpdateFailed con un messaggio che indica un errore 403 dovuto a ambiti di autenticazione insufficienti, simile al seguente errore:

Update call failed: error fetching live state: error reading underlying
resource: summary: Error when reading or editing SpannerInstance
"my-project/my-spanner-instance": googleapi: Error 403: Request had
insufficient authentication scopes.

Causa

Probabilmente Workload Identity Federation for GKE non è abilitata sul tuo cluster GKE.

Per verificare che la federazione delle identità per i carichi di lavoro per GKE non sia abilitata, completa i seguenti passaggi:

1. Salva la seguente configurazione del pod come wi-test.yaml:

   apiVersion: v1
   kind: Pod
   metadata:
     name: workload-identity-test
     namespace: cnrm-system
   spec:
     containers:
     - image: google/cloud-sdk:slim
       name: workload-identity-test
       command: ["sleep","infinity"]
     serviceAccountName: cnrm-controller-manager
   

   Se hai installato Config Connector utilizzando la modalità con spazio dei nomi, serviceAccountName deve essere cnrm-controller-manager-NAMESPACE. Sostituisci NAMESPACE con lo spazio dei nomi che hai utilizzato durante l'installazione.

2. Crea il pod nel cluster GKE:

   kubectl apply -f wi-test.yaml
   

3. Apri una sessione interattiva nel pod:

   kubectl exec -it workload-identity-test \
       --namespace cnrm-system \
       -- /bin/bash
   

4. Elenca la tua identità:

   gcloud auth list
   

5. Verifica che l'identità elencata corrisponda all'account di servizio Google associato alle tue risorse.

   Se visualizzi l'account di servizio predefinito di Compute Engine, significa che Workload Identity Federation for GKE non è abilitato sul tuo cluster GKE e/o sul tuo pool di nodi.

6. Esci dalla sessione interattiva, quindi elimina il pod dal cluster GKE:

   kubectl delete pod workload-identity-test \
       --namespace cnrm-system
   

Risoluzione

Per risolvere il problema, assicurati che la federazione delle identità per i carichi di lavoro per GKE sia abilitata sul tuo cluster.

Se continui a visualizzare lo stesso errore, assicurati di aver anche attivato Workload Identity Federation for GKE sui pool di nodi del cluster.

403: accesso negato. Il chiamante non dispone dell'autorizzazione.

Sintomo

La risorsa Config Connector ha uno stato UpdateFailed con un messaggio che indica un errore 403 dovuto alla federazione delle identità per i carichi di lavoro per GKE, simile al seguente errore:

Update call failed: error fetching live state: error reading underlying
resource: summary: Error when reading or editing SpannerInstance
"my-project/my-spanner- instance": Get
"https://spanner.googleapis.com/v1/projects/my-project/instances/my-spanner-instance?alt=json":
compute: Received 403 `Unable to generate access token; IAM returned 403
Forbidden: The caller does not have permission
This error could be caused by a missing IAM policy binding on the target IAM
service account.
For more information, refer to the Workload Identity documentation:
  https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#creating_a_relationship_between_ksas_and_gsas

Causa

Al account di servizio Kubernetes di Config Connector mancano le autorizzazioni IAM appropriate per impersonare il tuo service account IAM come utente di Workload Identity Federation for GKE.

Risoluzione

Per risolvere e mitigare il problema in futuro, consulta le istruzioni di installazione di Config Connector.

Errore 403: al chiamante manca l'autorizzazione IAM

Sintomo

La risorsa Config Connector ha lo stato UpdateFailed con un messaggio che indica che al chiamante manca un'autorizzazione IAM, simile al seguente errore:

Update call failed: error fetching live state: error reading underlying
resource: summary: Error when reading or editing SpannerInstance
"my-project/my-spanner- instance": googleapi: Error 403: Caller is missing IAM
permission spanner.instances.get on resource
projects/my-project/instances/my-spanner-instance., detail:

Causa

Al account di servizio IAM utilizzato da Config Connector manca l'autorizzazione IAM indicata nel messaggio necessaria per gestire la risorsa Google Cloud .

Risoluzione

Se continui a visualizzare lo stesso errore dopo aver concesso all'account di servizio IAM le autorizzazioni IAM appropriate, verifica che la risorsa venga creata nel progetto corretto. Controlla il campo spec.projectRef della risorsa Config Connector (o l'annotazione cnrm.cloud.google.com/project-id se la risorsa non supporta un campo spec.projectRef) e verifica che la risorsa faccia riferimento al progetto corretto. Tieni presente che Config Connector utilizza il nome dello spazio dei nomi come ID progetto se né la risorsa né lo spazio dei nomi specificano un progetto di destinazione. Scopri di più su come configurare il progetto di destinazione per le risorse con ambito progetto.

Se continui a visualizzare lo stesso errore, controlla se Workload Identity Federation for GKE è abilitata sul tuo cluster GKE.

Per risolvere il problema in futuro, assicurati di seguire le istruzioni di installazione di Config Connector.

Errore di aggiornamento con IAMPolicy, IAMPartialPolicy e IAMPolicyMember

Sintomo

Viene visualizzato lo stato UpdateFailed con un messaggio di errore che indica un errore 400 perché il account di servizio non esiste:

Update call failed: error setting policy member: error applying changes: summary: Request `Create IAM Members roles/[MYROLE] serviceAccount:[NAME]@[PROJECT_ID].iam.gserviceaccount.com for project \"projects/[PROJECT_ID]\"` returned error: Error applying IAM policy for project \"projects/[PROJECT_ID]\": Error setting IAM policy for project \"projects/[PROJECT_ID]\": googleapi: Error 400: Service account [NAME]@[PROJECT_ID].iam.gserviceaccount.com does not exist., badRequest

Causa

Se elimini una risorsa IAMServiceAccount Config Connector prima di eseguire la pulizia delle risorse IAMPolicy,IAMPartialPolicy e IAMPolicyMember che dipendono da quel account di servizio, Config Connector non riesce a trovare il account di servizio a cui viene fatto riferimento in queste risorse IAM durante la riconciliazione.

Risoluzione

Per risolvere il problema, controlla i service account e verifica se il account di servizio richiesto per queste risorse IAM è stato eliminato. Se l'account di servizio viene eliminato, pulisci anche le risorse IAM Config Connector correlate. Per IAMPolicyMember, elimina l'intera risorsa. Per IAMPolicy e IAMParitialPolicy, rimuovi solo le associazioni che coinvolgono ilaccount di serviziot eliminato. Tuttavia, questa pulizia non rimuove immediatamente i binding dei ruoliGoogle Cloud . I binding del ruolo Google Cloud vengono conservati per 60 giorni a causa della conservazione dell'account di servizio eliminato. Per saperne di più, consulta la Google Cloud documentazione di IAM su Eliminare un service account.

Nota :se riscontri problemi durante l'eliminazione, potresti dover eseguire una pulizia forzata. Se vuoi eliminare immediatamente le associazioni IAM Google Cloud, devi eliminare manualmente le risorse Google Cloud sottostanti utilizzando gcloud.

Per evitare questo problema, devi sempre pulire le risorse IAMPolicy, IAMPartialPolicy e IAMPolicyMember Config Connector prima di eliminare IAMServiceAccount.

La risorsa ServiceIdentity non va a buon fine con IAM_SERVICE_NOT_CONFIGURED_FOR_IDENTITIES

Sintomo

La risorsa ServiceIdentity ha lo stato UpdateFailed, con un messaggio di errore simile al seguente:

Update call failed: error applying desired state: summary: Error creating Service Identity: googleapi: Error 400: com.google.api.tenant.error.TenantManagerException: IAM_SERVICE_NOT_CONFIGURED_FOR_IDENTITIES: ...

Causa

Questo errore indica che la risorsa specificata non supporta la creazione di identità di servizio on demand.

Risoluzione

La risorsa ServiceIdentity può generare identità del servizio solo per i servizi supportati. Per verificare se un servizio supporta la creazione di identità di servizio on demand prima di applicare la configurazione, esegui il comando seguente:

gcloud beta services identity create --service SERVICE_NAME.googleapis.com

Sostituisci SERVICE_NAME con il nome del servizio, ad esempio spanner.

Se il comando ha esito positivo, Config Connector può creare un'identità per il servizio. Se il comando non va a buon fine, significa che Config Connector non può creare un'identità per quel servizio.

Installazione e upgrade

La sezione seguente elenca i problemi comuni relativi all'installazione o all'upgrade della versione di Config Connector.

Versione non supportata nelle installazioni del componente aggiuntivo Config Connector

Sintomo

Se non riesci ad attivare il componente aggiuntivo Config Connector, viene visualizzato il seguente messaggio di errore: Node version 1.15.x-gke.x s unsupported.

Il messaggio di errore viene visualizzato anche se Workload Identity Federation for GKE o GKE Monitoring sono disabilitati.

Causa

La versione del cluster GKE non soddisfa i requisiti o le funzionalità richieste sono disattivate.

Risoluzione

Per risolvere questo errore, verifica che la versione del cluster GKE soddisfi i requisiti di versione e funzionalità. Assicurati che Workload Identity Federation for GKE e GKE Monitoring siano abilitati.

Per ottenere tutte le versioni valide per i tuoi cluster, esegui questo comando:

gcloud container get-server-config --format "yaml(validMasterVersions)" \
    --zone ZONE

Sostituisci ZONE con la zona di Compute Engine.

Scegli dall'elenco una versione che soddisfi i requisiti.

failed calling webhook

Sintomo

Non puoi disinstallare Config Connector e ricevi un errore simile al seguente:

error during reconciliation: error building deployment objects: error finalizing the deletion of Config Connector system components deployed by ConfigConnector controller: error waiting for CRDs to be deleted: error deleting CRD accesscontextmanageraccesslevels.accesscontextmanager.cnrm.cloud.google.com: Internal error occurred: failed calling webhook "abandon-on-uninstall.cnrm.cloud.google.com": failed to call webhook: Post "https://abandon-on-uninstall.cnrm-system.svc:443/abandon-on-uninstall?timeout=3s": service "abandon-on-uninstall" not found

Causa

Questo problema può verificarsi quando utilizzi il componente aggiuntivo Config Connector e disattivi Config Connector prima di rimuovere i CRD di Config Connector.

Risoluzione

Per risolvere questo errore, devi prima eliminare manualmente i webhook:

kubectl delete validatingwebhookconfiguration abandon-on-uninstall.cnrm.cloud.google.com --ignore-not-found --wait=true
kubectl delete validatingwebhookconfiguration validating-webhook.cnrm.cloud.google.com --ignore-not-found --wait=true
kubectl delete mutatingwebhookconfiguration mutating-webhook.cnrm.cloud.google.com --ignore-not-found --wait=true

A questo punto puoi procedere alla disinstallazione di Config Connector.

PodSecurityPolicy impedisce gli upgrade

Sintomo

Dopo il passaggio dal componente aggiuntivo Config Connector a un'installazione manuale e l'upgrade di Config Connector a una nuova versione, cnrm i pod non vengono aggiornati.

Causa

L'utilizzo di PodSecurityPolicy può impedire l'aggiornamento dei pod cnrm.

Per verificare che le PodSecurityPolicies impediscano l'upgrade, controlla gli eventi di config-connector-operator e cerca un errore simile al seguente:

create Pod configconnector-operator-0 in StatefulSet configconnector-operator failed error: pods "configconnector-operator-0" is forbidden: PodSecurityPolicy: unable to admit pod: [pod.metadata.annotations[seccomp.security.alpha.kubernetes.io/pod]: Forbidden: seccomp may not be set pod.metadata.annotations[container.seccomp.security.alpha.kubernetes.io/manager]: Forbidden: seccomp may not be set]

Risoluzione

Per risolvere il problema, devi specificare l'annotazione in PodSecurityPolicy che corrisponde a quella menzionata nell'errore. Nell'esempio precedente, l'annotazione è seccomp.security.alpha.kubernetes.io.

Configurazione

La sezione seguente elenca i problemi comuni relativi alla configurazione delle risorse.

Impossibile apportare modifiche ai campi immutabili

Config Connector rifiuta gli aggiornamenti ai campi immutabili al momento dell'ammissione.

Ad esempio, l'aggiornamento di un campo immutabile con kubectl apply causa l'immediato errore del comando.

Ciò significa che gli strumenti che riapplicano continuamente le risorse (ad esempio, GitOps) potrebbero bloccarsi durante l'aggiornamento di una risorsa se non gestiscono gli errori di ammissione.

Poiché Config Connector non consente gli aggiornamenti ai campi non modificabili, l'unico modo per eseguire un aggiornamento di questo tipo è eliminare e ricreare la risorsa.

Errore durante l'aggiornamento dei campi immutabili quando non è presente alcun aggiornamento

Potresti visualizzare i seguenti errori nello stato della risorsa Config Connector poco dopo aver creato o acquisito una risorsa utilizzando Config Connector: Google Cloud

• Update call failed: error applying desired state: infeasible update: ({true \<nil\>}) would require recreation (esempio)

• Update call failed: cannot make changes to immutable field(s) (esempio)

Questo potrebbe non significare che hai effettivamente aggiornato la risorsa, ma il motivo potrebbe essere che l' Google Cloud API ha apportato una modifica a un campo immutabile gestito da te nella risorsa Config Connector. Ciò ha causato la mancata corrispondenza tra lo stato desiderato e lo stato attivo dei campi immutabili.

Puoi risolvere il problema aggiornando i valori di questi campi immutabili nella risorsa Config Connector in modo che corrispondano allo stato live. Per farlo, devi completare i seguenti passaggi:

1. Aggiorna la configurazione YAML della risorsa Config Connector e imposta l'annotazione cnrm.cloud.google.com/deletion-policy su abandon.
2. Applica la configurazione YAML aggiornata per aggiornare la policy di eliminazione della risorsa Config Connector.
3. Abbandona la risorsa Config Connector.
4. Stampa lo stato attivo della risorsa Google Cloud corrispondente utilizzando gcloud CLI.
5. Trova la mancata corrispondenza tra l'output della gcloud CLI e la configurazione YAML della risorsa Config Connector e aggiorna questi campi nella configurazione YAML.
6. Applica la configurazione YAML aggiornata per acquisire la risorsa abbandonata.

Nessuna corrispondenza per il tipo "Foo"

Sintomo

Visualizzi l'errore No matches for kind "Foo".

Causa

Il cluster Kubernetes non ha installato il CRD per il tipo di risorsa Foo.

Risoluzione

Verifica che il tipo sia un tipo di risorsa supportato da Config Connector.

Se il tipo è supportato, significa che l'installazione di Config Connector è obsoleta o non valida.

Se hai installato Config Connector utilizzando il componente aggiuntivo GKE, l'installazione dovrebbe essere aggiornata automaticamente. Se hai installato manualmente Config Connector, devi eseguire un upgrade manuale.

Controlla il repository GitHub per determinare quali tipi di risorse sono supportati da quali versioni di Config Connector (ad esempio, qui sono riportati i tipi supportati da Config Connector v1.44.0).

Le etichette non vengono propagate alla risorsa Google Cloud

Sintomo

Le etichette nel file YAML non vengono visualizzate nella risorsa Google Cloud .

Causa

Non tutte le risorse Google Cloud supportano le etichette.

Risoluzione

Config Connector propaga le etichette trovate in metadata.labels alla risorsaGoogle Cloud sottostante. Consulta la documentazione dell'API REST della risorsa (ad esempio, qui trovi la documentazione dell'API per PubSubTopic) per verificare se supporta le etichette.

Errore dovuto a caratteri speciali nel nome della risorsa

Sintomo

Viene visualizzato un errore relativo a caratteri non validi in metadata.name:

a lowercase RFC 1123 subdomain must consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*')

Causa

I caratteri speciali non sono validi nel campo metadata.name di Kubernetes.

Risoluzione

Se vuoi assegnare alla risorsa un nome che non è un nome Kubernetes valido, ma è un nome di risorsa Google Cloud valido, puoi utilizzare il campo resourceID, come mostrato nell'esempio seguente:

apiVersion: sql.cnrm.cloud.google.com/v1beta1
kind: SQLUser
metadata:
  name: 'test'
spec:
  instanceRef:
    name: sqlinstance-sample-postgresql
  host: "%"
  type: CLOUD_IAM_USER
  resourceID: [e-mail]

Questa configurazione fa sì che Config Connector utilizzi resourceID anziché metadata.name come nome della risorsa.

Impossibile rimuovere i campi dalla specifica della risorsa

Sintomo

La rimozione di un campo dalla specifica di una risorsa Config Connector non lo rimuove dalla risorsa.

Causa

La rimozione di un campo dalla specifica di una risorsa gestita da Config Connector non comporta l'eliminazione del campo o il ripristino di un valore predefinito. Al contrario, fa sì che il campo diventi gestito esternamente.

Nota :esiste un'eccezione: i campi all'interno degli elenchi. Gli elenchi sono atomici, il che significa che Config Connector tenterà di impostare l'elenco nel Google Cloud sottostante in modo che sia equivalente a quello specificato nella specifica.

Risoluzione

Se vuoi modificare il valore di un campo in modo che sia vuoto o predefinito nella risorsaGoogle Cloud sottostante, devi impostare il campo su zero nella specifica della risorsa Config Connector:

• Per il campo di tipo elenco, imposta il campo su un elenco vuoto utilizzando [].

  L'esempio seguente mostra il campo targetServiceAccounts che vogliamo rimuovere:

  spec:
    targetServiceAccounts:
      - external: "[e-mail]"
      - external: "[e-mail]"
  

  Per rimuovere questo campo, imposta il valore su vuoto:

  spec:
    targetServiceAccounts: []
  

• Per il campo di tipo primitivo, impostalo su vuoto utilizzando uno dei seguenti metodi:

  Tipo	Valore vuoto
  string	""
  bool	"false"
  integer	0

  L'esempio seguente mostra il campo identityNamespace che vogliamo rimuovere:

  spec:
    workloadIdentityConfig:
      identityNamespace: "foo-project.svc.id.goog"
  

  Per rimuovere questo campo, imposta il valore su vuoto:

  spec:
    workloadIdentityConfig:
      identityNamespace: ""
  

• Per i campi di tipo oggetto, puoi provare a impostare i sottocampi del tipo di oggetto come vuoti o predefiniti seguendo le indicazioni della sezione precedente e verificare se funziona. Tuttavia, non è garantito che funzioni.

Config Connector non viene avviato sui nodi basati su Arm

Se il cluster contiene node pool che utilizzano l'architettura Arm (come le serie di macchine C4A, N4A o Tau T2A), i componenti di Config Connector potrebbero non essere eseguiti. Si tratta di una limitazione nota perché Config Connector non supporta i sistemi basati su ARM.

Sintomi

Se la tua istanza di Config Connector è interessata da questo problema, potresti riscontrare i seguenti sintomi:

• I pod nello spazio dei nomi cnrm-system rimangono nello stato Pending.
• I pod potrebbero mostrare un CrashLoopBackOff con un messaggio di errore nei log simile a: exec user process caused "exec format error".
• La descrizione del pod rivela errori di pianificazione o mancata corrispondenza dell'architettura.

Risoluzione

Per risolvere il problema, assicurati che i componenti di Config Connector siano pianificati su nodi con architettura x86:

• Aggiungi un pool di nodi x86: se il cluster contiene solo nodi Arm, aggiungi almeno un pool di nodi utilizzando un tipo di macchina x86 (ad esempio e2-standard-2) per ospitare i pod controller Config Connector.
• Verifica le incompatibilità dei nodi: i nodi GKE Arm sono in genere incompatibili con kubernetes.io/arch=arm64:NoSchedule per impedire la pianificazione dei workload solo x86. Assicurati di non aver aggiunto tolleranze ai deployment di Config Connector che consentano loro di essere eseguiti su questi nodi.

Pulizia forzata

Se le risorse Config Connector sono bloccate durante l'eliminazione e vuoi semplicemente rimuoverle dal cluster Kubernetes, puoi forzarne l'eliminazione eliminando i relativi finalizer.

Avviso :questa operazione deve essere eseguita come ultima risorsa, poiché l'eliminazione dei finalizzatori non rientra nell'ambito del normale utilizzo di Config Connector e potrebbe avere conseguenze indesiderate. In particolare, non ci sono garanzie su cosa succede alle risorse Google Cloud sottostanti.

Puoi eliminare i finalizer di una risorsa modificandola utilizzando kubectl edit, eliminando il campo metadata.finalizers e poi salvando il file per conservare le modifiche apportate al server API Kubernetes.

Poiché l'eliminazione dei finalizer di una risorsa consente di eliminare immediatamente la risorsa dal cluster Kubernetes, Config Connector potrebbe (ma non necessariamente) non avere la possibilità di completare l'eliminazione della risorsaGoogle Cloud sottostante. Ciò significa che potresti voler eliminare manualmente le tue risorse Google Cloud in un secondo momento.

Monitoraggio

Il monitoraggio di Config Connector e l'esplorazione dei relativi log possono aiutarti a determinare l'origine dei problemi e a comprendere meglio il comportamento imprevisto.

Metriche

Puoi utilizzare Prometheus per raccogliere e mostrare le metriche di Config Connector.

Logging

Tutti i pod Config Connector restituiscono log strutturati in formato JSON.

I log dei pod controller sono particolarmente utili per il debug dei problemi di riconciliazione delle risorse.

Puoi eseguire query per i log di risorse specifiche filtrando i seguenti campi nei messaggi di log:

• logger: contiene il tipo di risorsa in minuscolo. Ad esempio, le risorse PubSubTopic hanno un logger di pubsubtopic-controller.
• resource.namespace: contiene lo spazio dei nomi della risorsa.
• resource.name: contiene il nome della risorsa.

Utilizzo di Logging per query avanzate sui log

Se utilizzi GKE, puoi utilizzare Cloud Logging per eseguire query sui log per una risorsa specifica con la seguente query:

Nota: la sintassi di query non supporta i commenti. La seguente query utilizza una convenzione di commento, # commento, per fornire testo esplicativo, ma questi commenti non possono essere inclusi nelle query.

# Filter to include only logs coming from the controller Pods
resource.type="k8s_container"
resource.labels.container_name="manager"
resource.labels.namespace_name="cnrm-system"
labels.k8s-pod/cnrm_cloud_google_com/component="cnrm-controller-manager"

# Filter to include only logs coming from a particular GKE cluster
resource.labels.cluster_name="GKE_CLUSTER_NAME"
resource.labels.location="GKE_CLUSTER_LOCATION"

# Filter to include only logs for a particular Config Connector resource
jsonPayload.logger="RESOURCE_KIND-controller"
jsonPayload.resource.namespace="RESOURCE_NAMESPACE"
jsonPayload.resource.name="RESOURCE_NAME"

Sostituisci quanto segue:

• GKE_CLUSTER_NAME con il nome del cluster GKE che esegue Config Connector
• GKE_CLUSTER_LOCATION con la posizione del cluster GKE che esegue Config Connector. Ad esempio, us-central1.
• RESOURCE_KIND con il tipo di risorsa in minuscolo. Ad esempio: pubsubtopic.
• RESOURCE_NAMESPACE con lo spazio dei nomi della risorsa.
• RESOURCE_NAME con il nome della risorsa.

Ulteriore assistenza

Per ricevere ulteriore supporto, puoi segnalare un problema su GitHub o contattare l'assistenzaGoogle Cloud .