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.
Controlla lo stato e le condizioni di Config Connector
Controllare la versione di Config Connector
Esegui questo comando per ottenere la versione di Config Connector installata e fai un controllo incrociato con le 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}'
Controlla lo stato e gli eventi della risorsa
In genere, puoi determinare il problema con le risorse Config Connector esaminando 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 perché la riconciliazione non è riuscita.
Verifica che Config Connector sia in esecuzione
Per controllare che Config Connector sia in esecuzione, verifica 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 Config Connector è installato in
modalità con spazio dei nomi,
avrai un pod del controller (cnrm-controller-manager) per ogni
spazio dei nomi responsabile della gestione delle risorse Config Connector in
quello spazio dei nomi.
Puoi controllare lo stato del pod del 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.
Controlla 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 modalità con spazio dei nomi, il comando precedente mostra i log combinati di tutti i pod controller. Puoi controllare i log del pod del 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 ispezionare ed eseguire query sui log di Config Connector.
Abbandonare e acquisire la risorsa
In alcuni casi, potresti dover aggiornare un campo immutabile in una risorsa. Poiché non puoi modificare i campi immutabili, devi abbandonare e poi acquisire la risorsa:
- Aggiorna la configurazione YAML della risorsa Config Connector e imposta l'annotazione
cnrm.cloud.google.com/deletion-policysuabandon. - Applica la configurazione YAML aggiornata per aggiornare la politica di cancellazione della risorsa Config Connector.
- Abbandona la risorsa Config Connector.
- Aggiorna i campi immutabili che devono essere modificati nella configurazione YAML.
- Applica la configurazione YAML aggiornata per acquisire la risorsa abbandonata.
Risolvere i problemi in base al tipo
Utilizza la tabella seguente per risolvere i problemi in base al tipo di sintomo.
| Tipo di problema | Problemi comuni |
|---|---|
| Riconciliazione | |
| Eliminazione | |
| Autorizzazioni | |
| Installazione e upgrade | |
| Configurazione |
|
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 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 porta a 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. Poi, confronta questo stato con la risorsa Config Connector. Cerca i campi i cui valori non corrispondono, quindi aggiorna la risorsa Config Connector in modo che corrispondano. In particolare, cerca i valori che sono stati 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 e Google 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 Ulteriore assistenza.
La riconciliazione non riesce o si ripete a causa degli aggiornamenti automatici dei campi
Questo problema si verifica quando Google Cloud aggiorna automaticamente un campo su una
risorsa che utilizza l'annotazione cnrm.cloud.google.com/state-into-spec: merge.
Sintomo
La risorsa Config Connector entra in uno stato UpdateFailed o passa ripetutamente allo stato Updating dopo che Google Cloud aggiorna automaticamente un campo che non hai specificato nel manifest YAML.
Ad esempio, dopo che Cloud SQL esegue un aggiornamento di manutenzione automatico su una risorsa SQLInstance, la riconciliazione potrebbe non riuscire con un errore simile al seguente:
Update call failed: error updating: patching SQLInstance ... maintenanceVersion failed: googleapi: Error 400: Invalid request: The requested maintenance version is not an available maintenance version to upgrade. Please refer to the availableMaintenanceVersions on the instance resource to see the available maintenance versions.., invalid
Causa
La risorsa ha l'annotazione cnrm.cloud.google.com/state-into-spec: merge.
Questa annotazione era l'impostazione predefinita per le risorse create prima di Config Connector
versione 1.123.1 per le CustomResourceDefinitions (CRD) aggiunte nella versione 1.113.0
e precedenti. La risorsa potrebbe avere questa annotazione anche se il campo spec.stateIntoSpec è impostato su Merge nella risorsa personalizzata (CR) ConfigConnector o ConfigConnectorContext.
Quando l'annotazione cnrm.cloud.google.com/state-into-spec è impostata su merge,
Config Connector compila i campi non specificati, ad esempio il campo
spec.maintenanceVersion, nel campo spec della risorsa Kubernetes
durante la riconciliazione iniziale. Quando Google Cloud aggiorna automaticamente
questo campo nella risorsa sottostante, Config Connector considera il valore
precedente archiviato nel campo spec come stato di destinazione e tenta di ripristinare la
modifica. Se l'API Google Cloud rifiuta i downgrade (come fa Cloud SQL per il campo spec.maintenanceVersion), la riconciliazione non va a buon fine.
Risoluzione
Per risolvere il problema, esegui la migrazione della risorsa dal comportamento Merge al comportamento Absent in modo che Config Connector smetta di compilare i campi non specificati nel campo spec:
- Nel manifest YAML della risorsa, ometti il campo aggiornato automaticamente (ad esempio il campo
spec.maintenanceVersion) e imposta l'annotazionecnrm.cloud.google.com/state-into-specsuabsent. - Segui i passaggi descritti in Esegui la migrazione delle risorse da
MergeaAbsentper abbandonare la risorsa Kubernetes e acquisirla nuovamente con il manifest YAML aggiornato.
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: il sincronizzatore aggiorna eccessivamente la risorsa
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 siano in conflitto per la risorsa.
Si dice che Config Sync e Config Connector "competono" per 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. Analogamente, 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 aggiornare lo stesso campo.
Un'eccezione sono i campi elenco. Analogamente a come Config Connector può impostare i valori predefiniti per i campi secondari nei campi degli oggetti, Config Connector può anche impostare i valori predefiniti per i campi secondari negli oggetti all'interno degli elenchi. Tuttavia, poiché i campi elenco nelle risorse Config Connector sono atomici, l'impostazione predefinita dei campi secondari è considerata come una modifica completa del 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:
Aggiorna il manifest della risorsa nel repository Config Sync in modo che corrisponda a quello 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.
Impedisci a Config Sync di reagire agli aggiornamenti della risorsa sul server API Kubernetes impostando l'annotazione
client.lifecycle.config.k8s.io/mutationsuignore. Scopri di più su come fare in modo che Config Sync ignori le mutazioni degli oggetti.Impedisci a Config Connector di aggiornare completamente la specifica della risorsa impostando l'annotazione
cnrm.cloud.google.com/state-into-specsuabsentnella risorsa. Questa annotazione non è supportata per tutte le risorse. Per verificare se la tua risorsa supporta l'annotazione, controlla la pagina di riferimento della risorsa corrispondente. Scopri di più sull'annotazione.
Risorsa eliminata da Config Connector
Sintomo
Una risorsa è stata eliminata dal tuo cluster e sospetti che sia stato Config Connector a eliminarla.
Causa
Config Connector non elimina mai le tue 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'idea sbagliata comune è che Config Connector abbia avviato ed eliminato alcune delle risorse nel cluster. Ad esempio, se utilizzi Config Connector, potresti notare richieste di eliminazione da parte del gestore dei controller di Config Connector per determinate risorse dai messaggi di log del 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 è controllare gli audit log del cluster Kubernetes.
Ad esempio, se utilizzi GKE, puoi utilizzare Cloud Logging per eseguire query sugli audit log dei cluster GKE. Ad esempio, se vuoi cercare le richieste di eliminazione iniziali per una risorsa BigQueryDataset denominata my-dataset nello spazio dei nomi my-namespace, 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/my-namespace/bigquerydatasets/my-dataset"
Utilizzando questa query, cercherai la prima richiesta di eliminazione e poi controllerai authenticationInfo.principalEmail del messaggio di log di eliminazione per determinare la causa dell'eliminazione.
Pod del controller terminato per OOM
Sintomo
Viene visualizzato un errore OOMKilled in un pod del controller Config Connector. Lo stato del pod potrebbe essere visualizzato come OOMKilled o Terminating.
Causa
Un container o l'intero pod è stato terminato perché ha utilizzato più memoria di quella consentita. Puoi verificarlo eseguendo il comando kubectl describe:
kubectl describe pod POD_NAME -n cnrm-system
Sostituisci POD_NAME con il pod di cui stai eseguendo la risoluzione dei problemi.
Inoltre, l'analisi approfondita dei log degli eventi del pod può rivelare eventuali occorrenze di eventi correlati a OOM.
Risoluzione
Per risolvere il 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 alla 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 l'oggetto ConfigConnectorContext di uno spazio dei nomi viene eliminato, Config Connector viene disabilitato per quello spazio dei nomi, impedendo l'eliminazione di eventuali risorse Config Connector rimanenti in quello spazio dei nomi.
Risoluzione
Per risolvere il problema, devi eseguire una pulizia forzata e poi eliminare manualmente le risorse Google Cloud sottostanti.
Per mitigare questo problema in futuro, elimina ConfigConnectorContext solo 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 siano state eliminate tutte le risorse Config Connector in quello spazio dei nomi, 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 progetto Google Cloud viene eliminato prima della risorsa.
Risoluzione
Per risolvere il problema, ripristina il progetto suGoogle Cloud per consentire a Config Connector di eliminare le risorse secondarie rimanenti da Kubernetes. In alternativa, puoi eseguire una pulizia forzata.
Per mitigare questo problema in futuro, elimina i progetti Google Cloud solo dopo che tutte le relative risorse Config Connector secondarie sono state eliminate da Kubernetes. Evita di eliminare interi spazi dei nomi che potrebbero contenere sia una risorsa Project sia le relative risorse Config Connector secondarie, 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 uno 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 mitigare questo 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 uno stato UpdateFailed con un messaggio che indica un errore 403 dovuto ad 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 confermare che Workload Identity Federation for GKE non è abilitata, completa i seguenti passaggi:
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-managerSe hai installato Config Connector utilizzando la modalità con spazi dei nomi,
serviceAccountNamedeve esserecnrm-controller-manager-NAMESPACE. SostituisciNAMESPACEcon lo spazio dei nomi utilizzato durante l'installazione.Crea il pod nel cluster GKE:
kubectl apply -f wi-test.yamlApri una sessione interattiva nel pod:
kubectl exec -it workload-identity-test \ --namespace cnrm-system \ -- /bin/bashElenca la tua identità:
gcloud auth listVerifica che l'identità elencata corrisponda al 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.
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 Workload Identity Federation for GKE sia abilitata sul tuo cluster.
Se continui a visualizzare lo stesso errore, assicurati di aver abilitato Workload Identity Federation for GKE sui node pool del cluster.
403 Forbidden: il chiamante non dispone dell'autorizzazione
Sintomo
La risorsa Config Connector ha uno stato UpdateFailed con un messaggio che indica un errore 403 dovuto a Workload Identity Federation for 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
Il account di servizio IAM utilizzato da Config Connector non dispone dell'autorizzazione IAM indicata nel messaggio necessaria per gestire la risorsa Google Cloud .
Risoluzione
Se continui a visualizzare lo stesso errore dopo aver concesso al tuo 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 la relativa 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 l'errore persiste, controlla se Workload Identity Federation for GKE è abilitato sul tuo cluster GKE.
Per mitigare questo 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 tuoi 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 il account di servizio eliminato. Tuttavia, questa pulizia non rimuove immediatamente le associazioni dei ruoliGoogle Cloud . Le associazioni di ruoli Google Cloud vengono conservate per 60 giorni a causa della conservazione del account di servizio eliminato. Per saperne di più, consulta la Google Cloud
documentazione IAM su
Eliminare un service account.
Per evitare questo problema, devi sempre eseguire la pulizia delle risorse IAMPolicy, IAMPartialPolicy e
IAMPolicyMember Config Connector prima di eliminare
IAMServiceAccount.
ServiceIdentity risorsa non riesce con Invalid service producer
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: Invalid service producer: ...
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à di servizio solo per i servizi supportati. Per verificare se un servizio supporta la creazione on demand dell'identità del servizio prima di applicare la configurazione, esegui questo comando:
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 correttamente 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 disabilitate.
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 una versione dall'elenco 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 con la 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, i pod cnrm non vengono aggiornati.
Causa
L'utilizzo di PodSecurityPolicies può impedire l'aggiornamento dei pod cnrm.
Per verificare che i criteri PodSecurityPolicy 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 su PodSecurityPolicy che corrisponde all'annotazione 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 in fase di ammissione.
Ad esempio, l'aggiornamento di un campo immutabile con kubectl apply causa l'immediato errore del comando.
Ciò significa che gli strumenti che applicano 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 aggiornamenti ai campi immutabili, 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
Poco dopo aver creato o acquisito una risorsa Google Cloud utilizzando Config Connector, potresti visualizzare i seguenti errori nello stato della risorsa Config Connector:
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'API Google Cloud ha apportato una modifica a un campo immutabile che è stato 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, completa i seguenti passaggi:
- Aggiorna la configurazione YAML della risorsa Config Connector e imposta l'annotazione
cnrm.cloud.google.com/deletion-policysuabandon. - Applica la configurazione YAML aggiornata per aggiornare la politica di cancellazione della risorsa Config Connector.
- Abbandona la risorsa Config Connector.
- Stampa lo stato in tempo reale della risorsa Google Cloud corrispondente utilizzando gcloud CLI.
- Trova la mancata corrispondenza tra l'output di gcloud CLI e la configurazione YAML della risorsa Config Connector e aggiorna questi campi nella configurazione YAML.
- Applica la configurazione YAML aggiornata per acquisire la risorsa abbandonata.
Nessuna corrispondenza per il tipo "RESOURCE_KIND"
Sintomo
Viene visualizzato l'errore No matches for kind "RESOURCE_KIND".
Causa
Il cluster Kubernetes non dispone della CRD per il tipo di risorsa RESOURCE_KIND installato.
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 non è aggiornata 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 risorsa
Google Cloud sottostante. Controlla 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: test.example@example-project.iam
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 comporta la rimozione dalla risorsa.
Causa
La rimozione di un campo dalla specifica di una risorsa gestita da Config Connector non rende il campo vuoto né ne ripristina il valore predefinito. Invece, fa sì che il campo diventi gestito esternamente.
Risoluzione
Se vuoi modificare il valore di un campo in vuoto o predefinito nella risorsaGoogle Cloud sottostante, devi azzerare il campo nella specifica della risorsa Config Connector:
Per il campo del tipo di elenco, imposta il campo su un elenco vuoto utilizzando
[].L'esempio seguente mostra il campo
targetServiceAccountsche vogliamo rimuovere:spec: targetServiceAccounts: - external: "example-sa-1@example-project.iam.gserviceaccount.com" - external: "example-sa-2@example-project.iam.gserviceaccount.com"Per rimuovere questo campo, imposta il valore su vuoto:
spec: targetServiceAccounts: []Per un campo di tipo primitivo, imposta il campo su vuoto utilizzando uno dei seguenti metodi:
Tipo Valore vuoto string "" bool "false" integer 0 L'esempio seguente mostra il campo
identityNamespaceche vogliamo rimuovere:spec: workloadIdentityConfig: identityNamespace: "example-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.
Valore "merge" non valido per l'annotazione state-into-spec
Questo problema si verifica quando una risorsa utilizza l'annotazione cnrm.cloud.google.com/state-into-spec: merge, ma il tipo di risorsa o la versione di Config Connector rifiuta il valore merge.
Sintomo
La riconciliazione della risorsa Config Connector non riesce e viene visualizzato un messaggio di errore simile al seguente:
Update call failed: error applying desired state: invalid value "merge" for "cnrm.cloud.google.com/state-into-spec" annotation
Causa
Questo errore si verifica per uno dei seguenti motivi:
- Il tipo di risorsa non supporta il comportamento
Merge, ma la risorsa ha l'annotazionecnrm.cloud.google.com/state-into-spec: merge. Questa annotazione può essere impostata direttamente sulla risorsa o ereditata dall'impostazionespec.stateIntoSpec: Mergenel CR ConfigConnector o ConfigConnectorContext. Le CRD aggiunte in Config Connector versione 1.114.0 e successive supportano solo il comportamentoAbsent. - Hai eseguito l'upgrade a Config Connector versione 1.134.0 o 1.134.1 e hai una risorsa SQLInstance esistente con l'annotazione
cnrm.cloud.google.com/state-into-spec: mergeper impostazione predefinita da una versione precedente. Le versioni 1.134.0 e 1.134.1 presentavano un problema noto che rifiutava il valoremergenelle risorse SQLInstance.
Risoluzione
Per risolvere il problema, completa i passaggi applicabili al tuo scenario:
- Il tipo di risorsa non supporta il comportamento
Merge: imposta l'annotazionecnrm.cloud.google.com/state-into-spec: absentnel file manifest YAML della risorsa e imposta il campospec.stateIntoSpecsuAbsentnel CR ConfigConnector o ConfigConnectorContext. Per verificare se il tuo tipo di risorsa supporta il comportamentoMerge, consulta Tipi con supporto diMerge. Se l'annotazione è già presente in una risorsa esistente nel cluster, segui i passaggi descritti in Eseguire la migrazione delle risorse daMergeaAbsent. - Utilizzi una risorsa SQLInstance esistente in Config Connector versione 1.134.0 o 1.134.1: esegui l'upgrade di Config Connector alla versione 1.134.2 o successive.
In alternativa, esegui la migrazione della risorsa SQLInstance all'annotazione
cnrm.cloud.google.com/state-into-spec: absentseguendo i passaggi descritti in Eseguire la migrazione delle risorse daMergeaAbsent.
Config Connector non si avvia sui nodi basati su Arm
Se il tuo cluster contiene node pool che utilizzano l'architettura Arm (come le serie di macchine C4A, N4A o Tau T2A), l'esecuzione dei componenti di Config Connector potrebbe non riuscire. 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-systemrimangono nello statoPending. - I pod potrebbero mostrare un
CrashLoopBackOffcon un messaggio di errore nei log simile a:exec user process caused "exec format error". - La descrizione del pod rivela errori di pianificazione o mancate corrispondenze 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 i taint dei nodi: i nodi GKE Arm sono in genere contaminati con
kubernetes.io/arch=arm64:NoScheduleper impedire la pianificazione di 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 finalizzatori.
Puoi eliminare i finalizzatori 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 finalizzatori di una risorsa consente di eliminarla immediatamente 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 i comportamenti imprevisti.
Metriche
Puoi utilizzare Prometheus per raccogliere e mostrare le metriche di Config Connector.
Logging
Tutti i pod Config Connector generano log strutturati in formato JSON.
I log dei pod controller sono particolarmente utili per il debug dei problemi relativi alla 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 risorsePubSubTopichanno unloggerdipubsubtopic-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:
# 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_NAMEcon il nome del cluster GKE che esegue Config ConnectorGKE_CLUSTER_LOCATIONcon la posizione del cluster GKE che esegue Config Connector. Ad esempio,us-central1.RESOURCE_KINDcon il tipo di risorsa in minuscolo. Ad esempio:pubsubtopic.RESOURCE_NAMESPACEcon lo spazio dei nomi della risorsa.RESOURCE_NAMEcon il nome della risorsa.
Ulteriore assistenza
Per ricevere ulteriore supporto, puoi segnalare un problema su GitHub o contattare l'assistenza diGoogle Cloud .