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:
- Aggiorna la configurazione YAML della risorsa Config Connector e imposta
l'annotazione
cnrm.cloud.google.com/deletion-policy
suabandon
. - Applica la configurazione YAML aggiornata per aggiornare il criterio di eliminazione 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.
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:
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 esserecnrm-controller-manager-NAMESPACE
. SostituisciNAMESPACE
con lo spazio dei nomi utilizzato durante l'installazione.Crea il pod nel tuo cluster GKE:
kubectl apply -f wi-test.yaml
Apri una sessione interattiva nel pod:
kubectl exec -it workload-identity-test \ --namespace cnrm-system \ -- /bin/bash
Elenca la tua identità:
gcloud auth list
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.
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:
- Aggiorna la configurazione YAML della risorsa Config Connector e imposta
l'annotazione
cnrm.cloud.google.com/deletion-policy
suabandon
. - Applica la configurazione YAML aggiornata per aggiornare il criterio di eliminazione della risorsa Config Connector.
- Abbandona la risorsa Config Connector.
- Stampa lo stato in tempo reale della Google Cloud risorsa corrispondente utilizzando gcloud CLI.
- 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.
- 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:
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.
Impedire a Config Sync di reagire agli aggiornamenti della risorsa sul server API Kubernetes impostando l'annotazione
client.lifecycle.config.k8s.io/mutation
suignore
. Scopri di più su come fare in modo che Config Sync ignori le mutazioni degli oggetti.Per impedire a Config Connector di aggiornare completamente la specifica della risorsa, imposta l'annotazione
cnrm.cloud.google.com/state-into-spec
suabsent
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 risorsePubSubTopic
hanno unlogger
pari apubsubtopic-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 ConnectorGKE_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.