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

Tecniche di base per la risoluzione dei problemi

Controllare la versione di Config Connector

Esegui il seguente comando per ottenere la versione di Config Connector installata e consulta 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}'

Controllare lo stato e gli eventi della risorsa

In genere, puoi determinare il problema con le risorse di 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 della mancata riconciliazione.

Verifica che Config Connector sia in esecuzione

Per verificare 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 hai installato Config Connector in modalità con spazi dei nomi, avrai un pod controller (cnrm-controller-manager) per ogni spazio dei nomi responsabile della gestione delle risorse di Config Connector nello spazio dei nomi in questione.

Puoi controllare lo stato del pod del controller responsabile di uno specifico spazio dei nomi 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 del controller registra informazioni ed errori relativi alla riconciliazione delle risorse di 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 nome spazio dei nomi, il comando precedente mostra i log di tutti i pod del controller combinati. 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, 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 il criterio 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.

Problemi comuni

La risorsa continua ad aggiornarsi ogni 5-15 minuti

Se la risorsa Config Connector continua a passare da uno stato UpToDate a uno stato Updating ogni 5-10 minuti, è probabile che Config Connector stia rilevando differenze non intenzionali tra lo stato desiderato e lo stato effettivo della risorsa, causando così un aggiornamento costante della risorsa.

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

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

Ottieni lo stato della Google Cloud risorsa 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, quindi aggiorna la risorsa Config Connector in modo che corrisponda. In particolare, cerca eventuali valori che sono stati riformattati da Google Cloud. Ad esempio, consulta i problemi GitHub #578 e #294.

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

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

Le eliminazioni degli spazi dei nomi rimangono bloccate in "Terminating" (In corso di terminazione)

Le eliminazioni degli spazi dei nomi potrebbero bloccarsi su Terminating se hai installato Config Connector in modalità con spazi dei nomi e se ConfigConnectorContext dello spazio dei nomi è stato eliminato prima dell'eliminazione di tutte le risorse di Config Connector nello spazio dei nomi. Quando viene eliminato ConfigConnectorContext di uno spazio dei nomi, Config Connector viene disattivato per lo spazio dei nomi in questione, impedendo l'eliminazione delle risorse Config Connector rimanenti nello spazio dei nomi.

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

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

Scopri anche come l'eliminazione di uno spazio dei nomi contenente un progetto e i relativi elementi secondari o una cartella e i relativi elementi secondari può bloccarsi.

Le eliminazioni delle risorse rimangono bloccate su "DeleteFailed" dopo l'eliminazione del progetto

Le eliminazioni delle risorse di Config Connector potrebbero bloccarsi su DeleteFailed se il progetto Google Cloud è stato eliminato in precedenza.

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 ridurre il problema in futuro, elimina i Google Cloud project solo dopo aver eliminato tutte le risorse Config Connector secondarie da Kubernetes. 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.

Metadati Compute Engine non definiti

Se la risorsa Config Connector ha lo stato UpdateFailed con un messaggio che indica che i metadati di Compute Engine non sono definiti, probabilmente significa che il service account IAM utilizzato da Config Connector non esiste.

Messaggio UpdateFailed di esempio:

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:

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

Per ridurre al minimo questo problema in futuro, assicurati di seguire le istruzioni di installazione di Config Connector.

Errore 403: la richiesta aveva finalità di autenticazione insufficienti

Se la risorsa Config Connector ha uno stato UpdateFailed con un messaggio che indica un errore 403 a causa di ambiti di autenticazione insufficienti, è probabile che Workload Identity non sia abilitata sul tuo cluster GKE.

Messaggio UpdateFailed di esempio:

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.

Per eseguire accertamenti, 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 nome spazio dei nomi, serviceAccountName deve essere cnrm-controller-manager-NAMESPACE. Sostituisci NAMESPACE con lo spazio dei nomi utilizzato durante l'installazione.

  2. Crea il pod nel tuo 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à indicata corrisponda all'account del servizio Google associato alle tue risorse.

    Se invece vedi l'account di servizio predefinito di Compute Engine, significa che la federazione delle identità per i carichi di lavoro per GKE non è abilitata nel tuo cluster GKE e/o nel pool di nodi.

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

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

Per risolvere il problema, utilizza un cluster GKE con la federazione delle identità per i carichi di lavoro per GKE attivata.

Se continui a visualizzare lo stesso errore su un cluster GKE con la federazione delle identità per i carichi di lavoro per GKE abilitata, assicurati di non aver dimenticato di attivare anche la federazione delle identità per i carichi di lavoro per GKE nei pool di nodi del cluster. Scopri di più su come abilitare Workload Identity Federation per GKE nei pool di nodi esistenti. Ti consigliamo di abilitare la federazione delle identità per i carichi di lavoro per GKE su tutti i pool di nodi del tuo cluster, poiché il connettore di configurazione potrebbe essere eseguito su qualsiasi pool.

403 Forbidden: l'utente che ha effettuato la chiamata non dispone dell'autorizzazione. Fai riferimento alla documentazione di Workload Identity Federation for GKE

Se la risorsa Config Connector ha lo stato UpdateFailed con un messaggio che indica un errore 403 a causa della federazione delle identità per i carichi di lavoro per GKE, è probabile che all'account di servizio Kubernetes di Config Connector manchino le autorizzazioni IAM appropriate per rubare l'identità del tuo account di servizio IAM come utente della federazione delle identità per i carichi di lavoro per GKE.

Messaggio UpdateFailed di esempio:

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 Federation for GKE documentation:
  https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#creating_a_relationship_between_ksas_and_gsas

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

Errore 403: all'utente chiamante manca l'autorizzazione IAM

Se la risorsa Config Connector ha lo stato UpdateFailed con un messaggio che indica che al chiamante manca un'autorizzazione IAM, probabilmente significa che all'account di servizio IAM utilizzato da Config Connector manca l'autorizzazione IAM indicata nel messaggio necessaria per gestire la risorsa. Google Cloud

Messaggio UpdateFailed di esempio:

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:

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 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 basate sul progetto.

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

Per ridurre al minimo questo problema in futuro, assicurati di seguire le istruzioni di installazione di Config Connector.

Versione non supportata nelle installazioni del componente aggiuntivo Config Connector

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. Per risolvere questo errore, verifica che la versione del cluster GKE soddisfi i requisiti relativi a funzionalità e versione.

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

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

Sostituisci ZONE con la zona Compute Engine.

Scegli dall'elenco una versione che soddisfi i requisiti.

Il messaggio di errore viene visualizzato anche se Workload Identity Federation for GKE o Monitoraggio GKE sono disattivati. Per correggere l'errore, assicurati che queste funzionalità siano attive.

Impossibile apportare modifiche ai campi immutabili

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

Ad esempio, l'aggiornamento di un campo immutabile con kubectl apply fa sì che il comando non vada a buon fine immediatamente.

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 aggiornamenti ai campi non modificabili, l'unico modo per eseguire questo aggiornamento è 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:

  • 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)

Ciò 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 del connettore di configurazione. 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 attivo. 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 il criterio di eliminazione della risorsa Config Connector.
  3. Abbandona la risorsa Config Connector.
  4. Stampa lo stato in tempo reale della Google Cloud risorsa corrispondente utilizzando gcloud CLI.
  5. Individua la mancata corrispondenza tra l'output della CLI gcloud 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.

La risorsa non ha stato

Se le risorse non hanno un campo status, è probabile che Config Connector non funzioni correttamente. Verifica che Config Connector sia in esecuzione.

Nessuna corrispondenza per il tipo "Foo"

Se si verifica questo errore, significa che il cluster Kubernetes non ha installato il CRD per il tipo di risorsa Foo.

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'upgrade della tua installazione dovrebbe essere eseguito 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 determinate versioni di Config Connector (ad esempio, qui sono i tipi supportati dalla versione 1.44.0 di Config Connector).

Le etichette non vengono propagate alla risorsa Google Cloud

Config Connector propaga le etichette trovate in metadata.labels alla risorsaGoogle Cloud sottostante. Tuttavia, tieni presente che non tutte le Google Cloud risorse supportano le etichette. Controlla la documentazione dell'API REST della risorsa (ad esempio, ecco la documentazione dell'API per PubSubTopic) per verificare se supporta le etichette.

Impossibile chiamare il certificato x509 webhook: il certificato si basa sul campo Common Name precedente

Se viene visualizzato un errore simile all'esempio seguente, è possibile che si stia verificando un problema con i certificati:

Error from server (InternalError): error when creating "/mnt/set-weaver-dns-record.yml": Internal error occurred: failed calling webhook "annotation-defaulter.cnrm.cloud.google.com": Post "https://cnrm-validating-webhook.cnrm-system.svc:443/annotation-defaulter?timeout=30s": x509: certificate relies on legacy Common Name field, use SANs or temporarily enable Common Name matching with GODEBUG=x509ignoreCN=0

Per risolvere il problema, elimina i certificati e i pod pertinenti:

kubectl delete -n cnrm-system secrets cnrm-webhook-cert-abandon-on-uninstall
kubectl delete -n cnrm-system secrets cnrm-webhook-cert-cnrm-validating-webhook
kubectl delete -n cnrm-system pods -l "cnrm.cloud.google.com/component=cnrm-webhook-manager"

Dopo aver eliminato queste risorse, il certificato corretto viene rigenerato.

Per ulteriori informazioni su questo errore, consulta la segnalazione di GitHub.

Errore dovuto a caratteri speciali nel nome della risorsa

I caratteri speciali non sono validi nel campo metadata.name Kubernetes. Se visualizzi un errore simile all'esempio seguente, è probabile che metadata.name della risorsa abbia un valore con caratteri speciali:

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])?)*')

Ad esempio, la seguente risorsa SQLUser contiene un carattere non valido in metadata.name:

apiVersion: sql.cnrm.cloud.google.com/v1beta1
kind: SQLUser
metadata:
  name: test.example@example-project.iam
spec:
  instanceRef:
    name: test-cloudsql-db
  type: "CLOUD_IAM_USER"

Se provi a creare questa risorsa, viene visualizzato il seguente errore:

Error from server (Invalid): error when creating "sqlusercrd.yaml": SQLUser.sql.cnrm.cloud.google.com "test.example@example-project.iam" is invalid: metadata.name: Invalid value: "test.example@example-project.iam": 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])?)*')

Se vuoi assegnare alla risorsa un nome che non sia un nome Kubernetes valido, ma che sia un nome Google Cloud risorsa 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

La rimozione di un campo dalla specifica di una risorsa Config Connector (aggiornando il file .yaml della risorsa e applicandola di nuovo o utilizzando kubectl edit per modificare la specifica della risorsa) non comporta la rimozione effettiva del campo dalla specifica della risorsa Config Connector o dalla risorsa Google Cloud sottostante. Invece, la rimozione di un campo dalla specifica comporta solo che il campo sia gestito esternamente.

Se vuoi impostare il valore di un campo su vuoto o predefinito nella risorsaGoogle Cloud sottostante, dovrai impostare il campo su zero 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 targetServiceAccounts che vogliamo rimuovere:

    spec:
  targetServiceAccounts:
    - external: "foo-bar@foo-project.iam.gserviceaccount.com"
    - external: "bar@foo-project.iam.gserviceaccount.com"

    Per rimuovere questo campo, imposta il valore su vuoto:

    spec:
  targetServiceAccounts: []

  • Per il campo di tipo primitivo, imposta il campo su vuoto utilizzando una delle seguenti opzioni:

    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 del tipo di oggetto, al momento in Config Connector non esiste un modo semplice per impostare un intero campo del tipo di oggetto come "NULL". Puoi provare a impostare i campi secondari del tipo di oggetto come vuoti o predefiniti seguendo le indicazioni riportate sopra e verificare se funziona.

KNV2005: il sincronizzatore aggiorna eccessivamente la risorsa

Se utilizzi Config Sync e vedi errori KNV2005 per le risorse Config Connector, è probabile che Config Sync e Config Connector stiano cercando di accedere alla stessa risorsa.

Messaggio di log di esempio:

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

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 una risorsa attiva l'altra per aggiornare la risorsa, che attiva l'altra per aggiornare la risorsa e così via.

I combattimenti non sono un problema per la maggior parte dei campi. I campi specificati in Config Sync non vengono modificati da Config Connector, mentre 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 mai aggiornare lo stesso campo con valori diversi.

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

Di conseguenza, Config Sync e Config Connector finiranno per entrare in conflitto se Config Sync imposta un campo di elenco e Config Connector imposta come predefiniti eventuali campi secondari all'interno di quell'elenco.

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 completi la riconciliazione della risorsa e poi aggiornare il manifest della risorsa in modo che corrisponda alla risorsa sul server dell'API Kubernetes.

  2. Impedire 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 mutazioni degli oggetti.

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

failed calling webhook

È possibile che Config Connector sia in uno stato in cui non puoi disinstallarlo. Questo accade di solito quando si utilizza il componente aggiuntivo Config Connector e si disattiva Config Connector prima di rimuovere i CRD di Config Connector. Quando provi a eseguire la disinstallazione, ricevi un messaggio di 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

Per risolvere questo errore, devi prima eliminare manualmente gli 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

Puoi quindi procedere alla disinstallazione di Config Connector.

Aggiornamento errore con IAMPolicy, IAMPartialPolicy e IAMPolicyMember

Se elimini una risorsa IAMServiceAccount Config Connector prima di ripulire le risorse IAMPolicy, IAMPartialPolicy e IAMPolicyMember che dipendono da quell'account di servizio, Config Connector non riesce a trovare l'account di servizio a cui fa riferimento in queste risorse IAM durante la riconciliazione. Il risultato è uno stato UpdateFailed con un messaggio di errore simile al seguente:

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

Per risolvere il problema, controlla i tuoi account di servizio e verifica se l'account di servizio richiesto per queste risorse IAM è stato eliminato. Se l'account di servizio viene eliminato, ripulisci anche le risorse Config Connector IAM correlate. Per IAMPolicyMember, elimina l'intera risorsa. Per IAMPolicy e IAMParitialPolicy, rimuovi solo le associazioni che coinvolgono l'account di servizio eliminato. Tuttavia, questa operazione di pulizia non rimuove immediatamente le associazioni di ruoli. Google Cloud Le associazioni ai ruoli Google Cloud vengono conservate per 60 giorni a causa della conservazione nell'account di servizio eliminato. Per ulteriori informazioni, consulta la Google Cloud documentazione IAM su come eliminare un account di servizio.

Per evitare questo problema, devi sempre ripulire le risorse Config Connector IAMPolicy, IAMPartialPolicy,IAMPolicyMember prima di eliminare IAMServiceAccount a cui fai riferimento.

Risorsa eliminata da Config Connector

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 può causare l'eliminazione delle risorse.

Un malinteso 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 del controller di Config Connector 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 attivatori esterni e Config Connector sta tentando di riconciliare le richieste di eliminazione.

Per determinare il motivo dell'eliminazione di una risorsa, 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 sugli 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, cerca la prima richiesta di eliminazione, quindi controlla authenticationInfo.principalEmail del messaggio di log di eliminazione per determinare la causa dell'eliminazione.

Pod del controller terminato per OOM

Se viene visualizzato un errore OOMKilled in un pod del controller Config Connector, significa che un container o l'intero pod è stato terminato perché ha utilizzato più memoria del consentito. Per verificare, esegui il comando kubectl describe. Lo stato del pod potrebbe essere OOMKilled o Terminating. Inoltre, l'esame dei log degli eventi del pod può rivelare eventuali occorrenze di eventi relativi a OOM.

kubectl describe pod POD_NAME -n cnrm-system

Sostituisci POD_NAME con il pod di cui stai cercando di risolvere il problema.

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

PodSecurityPolicy impedisce gli upgrade

Dopo aver passato dal componente aggiuntivo Config Connector a un'installazione manuale e aver eseguito l'upgrade di Config Connector a una nuova versione, l'utilizzo di PodSecurityPolicies può impedire l'aggiornamento dei pod cnrm.

Per verificare che i PodSecurityPolicies stiano impedendo 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]

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

Pulizia forzata

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

sottostanti.

Puoi eliminare i finalizzatori di una risorsa modificando la risorsa utilizzando kubectl edit, eliminando il campo metadata.finalizers e salvando il file per conservare le modifiche apportate all'API server 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 Google Cloud risorse in un secondo momento.

Monitoraggio

Metriche

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

Logging

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

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

Puoi eseguire query sui log per risorse specifiche filtrando in base ai seguenti campi nei messaggi di log:

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

Utilizzo di Cloud Logging per query sui log avanzate

Se utilizzi GKE, puoi utilizzare Cloud Logging per eseguire query sui log di 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_NAME con il nome del cluster GKE su cui è in esecuzione Config Connector
  • GKE_CLUSTER_LOCATION con la posizione del cluster GKE in cui è in esecuzione 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 assistenza, puoi segnalare un problema su GitHub o contattare l'Google Cloud assistenza.