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.

Tecniche di risoluzione dei problemi di base

Controllare 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. Il controllo dello stato e degli 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 namespaced-mode, 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.

Problemi comuni

La risorsa continua ad aggiornarsi ogni 5-15 minuti

Se la risorsa Config Connector passa continuamente dallo stato UpToDate allo stato Updating ogni 5-10 minuti, è probabile che Config Connector rilevi differenze non intenzionali tra lo stato desiderato e lo stato effettivo della risorsa, causando l'aggiornamento costante della risorsa da parte di Config Connector.

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

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

Eliminazioni di spazi dei nomi bloccate su "Terminating"

L'eliminazione degli spazi dei nomi potrebbe bloccarsi a Terminating se hai installato Config Connector in modalità con spazio dei nomi e se ConfigConnectorContext dello spazio dei nomi è stato eliminato prima di tutte le risorse Config Connector in quello spazio dei nomi. Quando viene eliminato 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 in quello spazio dei nomi.

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.

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.

Eliminazioni di risorse bloccate su "DeleteFailed" dopo l'eliminazione del progetto

L'eliminazione delle risorse Config Connector potrebbe 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 risolvere questo problema in futuro, elimina solo i progetti 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.

Metadati Compute Engine non definiti

Se la risorsa Config Connector ha uno stato UpdateFailed con un messaggio che indica che i metadati di Compute Engine non sono definiti, è probabile che il account di servizio IAM utilizzato da Config Connector non esista.

Messaggio di esempio UpdateFailed:

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

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

Messaggio di esempio UpdateFailed:

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 l'indagine, 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

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

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 abilitare anche la federazione delle identità per i carichi di lavoro per GKE sui node pool del cluster. Scopri di più su come abilitare Workload Identity Federation for GKE sui 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 cluster, poiché Config Connector potrebbe essere eseguito su uno qualsiasi di questi.

403 Forbidden: il chiamante non dispone dell'autorizzazione; consulta la documentazione di Workload Identity Federation for GKE

Se la risorsa Config Connector ha uno stato UpdateFailed con un messaggio che indica un errore 403 dovuto a Workload Identity Federation for GKE, è probabile che al account di servizio Kubernetes di Config Connector manchino le autorizzazioni IAM appropriate per rappresentare il tuo service account IAM come utente di Workload Identity Federation for GKE.

Messaggio di esempio UpdateFailed:

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: al 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, è probabile che al account di servizio IAM utilizzato da Config Connector manchi l'autorizzazione IAM indicata nel messaggio necessaria per gestire la risorsa Google Cloud .

Messaggio di esempio UpdateFailed:

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 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 è attivata sul tuo cluster GKE.

Per risolvere il 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 di versione e funzionalità.

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.

Il messaggio di errore viene visualizzato anche se Workload Identity Federation for GKE o GKE Monitoring sono disabilitati. Assicurati che queste funzionalità siano attive per correggere l'errore.

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'errore immediato 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 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 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.

La risorsa non ha uno stato

Se le tue 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"

Quando si verifica questo errore, significa che nel cluster Kubernetes non è installata la 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'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

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

Chiamata webhook x509 non riuscita: il certificato si basa sul campo Common Name legacy

Se visualizzi un errore simile al seguente esempio, potresti riscontrare 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"

Una volta eliminate queste risorse, il certificato corretto viene rigenerato.

Per saperne di più su questo errore, consulta la segnalazione su GitHub.

Errore dovuto a caratteri speciali nel nome della risorsa

I caratteri speciali non sono validi nel campo Kubernetes metadata.name. Se visualizzi un errore simile al seguente esempio, la metadata.name della risorsa probabilmente ha 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 è 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

La rimozione di un campo dalla specifica di una risorsa Config Connector (aggiornando il file .yaml della risorsa e riapplicandolo 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. La rimozione di un campo dalla specifica lo rende invece gestito esternamente.

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: "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, 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, al momento in Config Connector non esiste un modo semplice per impostare un intero campo di tipo 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: syncer excessively updating resource

Se utilizzi Config Sync e visualizzi errori KNV2005 per le risorse Config Connector, è probabile che Config Sync e Config Connector si contendano la 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 uno attiva l'altro per agire e aggiornare la risorsa, il che fa sì che l'altro agisca e aggiorni la risorsa e così via.

Il combattimento non è 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 devono mai aggiornare lo stesso campo con valori diversi.

Esiste un'eccezione: 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 finiranno per scontrarsi se Config Sync imposta un campo elenco e Config Connector imposta come predefiniti i campi secondari all'interno di questo 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 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, controlla la pagina di riferimento della risorsa corrispondente. Scopri di più sull'annotazione.

failed calling webhook

È possibile che Config Connector si trovi in uno stato in cui non è possibile disinstallarlo. Ciò accade in genere quando si utilizza il componente aggiuntivo Config Connector e si disabilita Config Connector prima di rimuovere i CRD di Config Connector. Quando provi a disinstallare, 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

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.

Errore di aggiornamento con IAMPolicy, IAMPartialPolicy e IAMPolicyMember

Se elimini una risorsa Config Connector IAMServiceAccount 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. In questo modo, lo stato di UpdateFailed viene visualizzato 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 service account e verifica se il account di servizio richiesto per queste risorse IAM è stato eliminato. Se il 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 i binding che coinvolgono il account di servizio eliminato. Tuttavia, questa pulizia non rimuove immediatamente i binding dei ruoli Google Cloud . I binding dei ruoli Google Cloud vengono conservati per 60 giorni a causa della conservazione dell'account di servizio eliminato. Per ulteriori informazioni, consulta la Google Cloud documentazione IAM su come eliminare un service account.

Per evitare questo problema, devi sempre eseguire la pulizia delle risorse Config Connector IAMPolicy, IAMPartialPolicy,IAMPolicyMember prima di eliminare IAMServiceAccount a cui viene fatto 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 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 dal controller manager 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 trigger esterni e Config Connector sta tentando di riconciliarle.

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

Se visualizzi un errore OOMKilled in un pod controller Config Connector, significa che un container o l'intero pod è stato terminato perché utilizzava più memoria del consentito. Puoi verificarlo eseguendo il comando kubectl describe. Lo stato del pod potrebbe essere OOMKilled o Terminating. Inoltre, l'analisi approfondita dei log degli eventi del pod può rivelare eventuali occorrenze di eventi correlati a OOM.

kubectl describe pod POD_NAME -n cnrm-system

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

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 il passaggio dal componente aggiuntivo Config Connector a un'installazione manuale e l'upgrade di Config Connector a una nuova versione, l'utilizzo di PodSecurityPolicies 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]

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.

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.

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

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 Cloud Logging per query avanzate sui log

Se utilizzi GKE, puoi utilizzare Cloud Logging per eseguire query per i 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 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 .