Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Risolvi i problemi di Config Sync

Questa pagina mostra come risolvere i problemi relativi a Config Sync.

Cerchiamo costantemente di far funzionare l'esperienza Config Sync per te, ma in alcuni casi potresti riscontrare la necessità di risolvere dei problemi durante la configurazione. Questa guida illustra alcuni meccanismi comuni che possono aiutarti a risolvere i problemi riscontrati.

Best practice generali

Visualizza stato di Config Sync

Il comando nomos status fornisce dati ed errori aggregati per aiutarti a capire cosa sta succedendo con l'installazione di Config Sync. Con nomos status sono disponibili le seguenti informazioni:

  • Stato di installazione per cluster
  • Errori di sincronizzazione (sia quelli letti da Git che quelli di riconciliazione delle modifiche)

Per utilizzare nomos status, installa il comando nomos.

Puoi anche utilizzare il comando gcloud alpha anthos config sync repo per ottenere lo stato di Config Sync per repository. Per scoprire di più, consulta Visualizzare lo stato di Config Sync in più cluster.

Utilizza kubectl per esaminare le risorse

Config Sync è composto da più risorse personalizzate su cui puoi eseguire query utilizzando i comandi kubectl. Questi comandi ti aiutano a comprendere lo stato di ciascun oggetto di Config Sync.

Dovresti conoscere le seguenti informazioni sulle risorse Kubernetes gestite da Config Sync:

  • config-management-system è lo spazio dei nomi che utilizziamo per eseguire tutti i componenti di sistema principali di Config Sync.
  • configmanagement.gke.io/v1 e configsync.gke.io sono i prefissi delle versioni che utilizziamo per tutte le risorse personalizzate.

Puoi ottenere un elenco completo delle risorse personalizzate eseguendo questo comando:

kubectl api-resources | grep -E "configmanagement.gke.io|configsync.gke.io"

Le singole risorse personalizzate possono essere utilizzate eseguendo: kubectl get RESOURCE -o yaml.

Ad esempio, l'output del seguente comando consente di controllare lo stato di un oggetto rootSync:

kubectl get rootsync -n config-management-system -o yaml

Puoi anche utilizzare il comando gcloud alpha anthos config sync resources per scaricare le risorse gestite di Config Sync. Per scoprire di più, consulta Visualizzare le risorse gestite di Config Sync.

Esplora gli oggetti RootSync e RepoSync

Quando installi Config Sync utilizzando kubectl, crei un oggetto RootSync che contiene i dettagli sulla configurazione del repository principale. Quando installi Config Sync utilizzando Google Cloud Console o Google Cloud CLI, Config Sync crea automaticamente un oggetto RootSync per te. Quando configuri la sincronizzazione da più repository, crei oggetti RepoSync che contengono informazioni di configurazione sui tuoi repository di spazi dei nomi.

L'esplorazione di questi oggetti può rivelare informazioni preziose sullo stato di Config Sync. Per scoprire di più, consulta Monitorare gli oggetti RootSync e RepoSync.

Usa audit log

Gli audit log possono essere uno strumento di debug utile.

Se hai installato Config Sync tramite Google Cloud Console o Google Cloud CLI, completa i passaggi seguenti per utilizzare gli audit log per esaminare Config Sync.

Console

  1. Abilita gli audit log delle API GKE Connect/Hub.

    1. In Google Cloud Console, vai alla pagina Log di controllo di IAM.

      Vai alla pagina Audit log

    2. Nella tabella, seleziona la casella di controllo API GKE/Hub di GKE.

    3. Seleziona le seguenti caselle di controllo:

      • Lettura amministratore
      • Lettura dati
      • Scrittura dati
    4. Fai clic su Salva.

  2. Vai alla pagina Esplora log.

    Vai alla pagina Esplora log

  3. Nella casella di testo Query builder, aggiungi i seguenti filtri:

    resource.type="audited_resource" resource.labels.service="gkehub.googleapis.com"
    
  4. Fai clic su Esegui query.

  5. Nella sezione Query results, seleziona le voci per scoprire di più sugli eventi.

Risolvere i problemi generali

Evento con pianificazione non riuscita

L'output di kubectl get events potrebbe includere un evento con il tipo FailedScheduling. Questo evento è simile al seguente esempio:

LAST SEEN   TYPE      REASON              OBJECT                                       MESSAGE
9s          Warning   FailedScheduling    pod/config-management-operator-74594dc8f6    0/1 nodes are available: 1 Insufficient cpu.

Questo evento può verificarsi perché non è possibile pianificare i pod sui nodi, il che significa che la CPU o la memoria sui nodi è insufficiente. Per correggere questo errore, scegli una delle seguenti opzioni:

  • Aggiungi un nodo a un pool di nodi GKE esistente.
  • Crea un pool di nodi con nodi più grandi.

Oggetto ConfigManagement valido ma errato

Se installi Config Sync utilizzando i comandi kubectl e l'installazione non riesce a causa di un problema dell'oggetto ConfigManagement non dovuto a un errore di sintassi YAML o JSON, è possibile che venga creata un'istanza del cluster nell'istanza, ma potrebbe non funzionare correttamente. In questo caso, puoi utilizzare il comando nomos status per verificare la presenza di errori nell'oggetto.

Lo stato di un'installazione valida senza problemi è PENDING o SYNCED.

Un'installazione non valida ha lo stato NOT CONFIGURED ed elenca uno dei seguenti errori:

  • missing git-creds Secret
  • missing required syncRepo field
  • git-creds Secret is missing the key specified by secretType

Per risolvere il problema, correggi l'errore di configurazione. A seconda del tipo di errore, potresti dover applicare di nuovo il manifest di ConfigManagement al cluster.

Se il problema consiste nel fatto che hai dimenticato di creare il secret di git-creds, Config Sync rileva il secret non appena lo crei e non devi riapplicare la configurazione.

I campi ResourceGroup continuano a cambiare

Per ogni repository Git sincronizzato con il cluster, lo stato di riconciliazione di tutte le risorse è aggregato in una risorsa denominata ResourceGroup. Per ogni oggetto Sincronizzazione radice o RepoSync, viene generato un ResourceGroup per acquisire il set di risorse applicate al cluster e aggregare i relativi stati.

Occasionalmente, il tuo ResourceGroup può inserire un loop che continua ad aggiornare il spec di ResourceGroup. In questo caso, potresti riscontrare i seguenti problemi:

  • Il metadata.generation di un ResourceGroup continua ad aumentare in un breve periodo di tempo.
  • Il gruppo di risorse spec continua a cambiare.
  • Il gruppo di risorse spec non include il valore status.resourceStatuses delle risorse sincronizzate con il cluster.

Se riscontri questi problemi, significa che alcune risorse nei tuoi repository Git non sono state applicate al cluster. Il problema è dovuto alla mancanza delle autorizzazioni necessarie per applicare queste risorse.

Puoi verificare che le autorizzazioni non siano ottenute recuperando lo stato della risorsa RepoSync:

kubectl get reposync repo-sync -n NAMESPACE -o yaml

Sostituisci NAMESPACE con lo spazio dei nomi in cui hai creato il repository.

Puoi anche utilizzare nomos status.

Se lo stato mostra i seguenti messaggi, significa che il riconciliatore in NAMESPACE non ha l'autorizzazione necessaria per applicare la risorsa:

errors:
  - code: "2009"
    errorMessage: |-
      KNV2009: deployments.apps "nginx-deployment" is forbidden: User "system:serviceaccount:config-management-system:ns-reconciler-     default" cannot get resource "deployments" in API group "apps" in the namespace "default"

      For more information, see https://g.co/cloud/acm-errors#knv2009

Per risolvere questo problema, devi dichiarare una configurazione RoleBinding che concede l'autorizzazione all'account di servizio ns-reconciler-NAMESPACE per gestire la risorsa non riuscita in tale spazio dei nomi. I dettagli su come aggiungere un'associazione dei ruoli sono inclusi in Configurare la sincronizzazione da più repository.

Numero elevato di risorse nel repository Git

Quando il repository Git sincronizzato con un cluster da un oggetto RepoSync o RootSync contiene una configurazione per più di qualche mille risorse, può causare che il valore di ResourceResource superi il limite di etcdoggetto. In questo caso, non puoi visualizzare lo stato aggregato delle risorse nel tuo repository Git. Anche se non potrai visualizzare lo stato aggregato, il tuo repository potrebbe essere comunque sincronizzato.

Se viene visualizzato il seguente errore dall'oggetto RootSync, dal ReposSync o dai log del riconciliatore, significa che la risorsa ResourceGroup supera il limite di dimensioni dell'oggetto etcd.

KNV2009: etcdserver: request is too large

La soluzione consigliata consiste nel suddividere il repository Git in più repository seguendo le istruzioni. Se non riesci a suddividere il repository Git, in Config Sync v1.11.0 e versioni successive puoi mitigarlo disattivando la visualizzazione dei dati di stato. Per farlo, imposta il campo .spec.override.statusMode dell'oggetto RootSync o RepoSync su disabled. In questo modo, Config Sync interrompe l'aggiornamento dello stato delle risorse gestite nell'oggetto ResourceGroup. Riduce le dimensioni dell'oggetto ResourceGroup. Tuttavia, non potrai visualizzare lo stato delle risorse gestite da nomos status o gcloud alpha anthos config sync.

Se non vedi errori nell'oggetto RootSync o RepoSync, significa che il tuo repository Git è sincronizzato con il cluster. Per verificare se la risorsa ResourceGroup supera il limite di oggetti etcd, controlla sia lo stato della risorsa ResourceGroup sia il log del controller ResourceGroup:

  1. Controlla lo stato ResourceGroup:

    • Per controllare l'oggetto RootSync, esegui il comando seguente:
     kubectl get resourcegroup.kpt.dev root-sync -n config-management-system
    
    • Per controllare l'oggetto RepoSync, esegui il comando seguente:
    kubectl get resourcegroup.kpt.dev repo-sync -n NAMESPACE
    

    L'output è simile all'esempio seguente:

    NAME        RECONCILING   STALLED   AGE
    root-sync   True          False     35m
    

    Se il valore nella colonna RECONCILING è True, significa che la risorsa ResourceGroup è ancora in fase di riconciliazione.

  2. Controlla i log per il controller ResourceGroup:

    kubectl logs deployment/resource-group-controller-manager -c manager -n resource-group-system
    

    Se nell'output viene visualizzato il seguente errore, la risorsa ResourceGroup è troppo grande e supera il limite di dimensioni dell'oggetto etcd:

    "error":"etcdserver: request is too large"
    

Per evitare che ResourceGroup diventi troppo grande, riduci il numero di risorse nel tuo repository Git. Puoi seguire le istruzioni per suddividere il repository principale in più repository radice.

Non sincronizzato dal repository Git

Se viene eseguito il push di nuovi commit nel repository Git, ma lo stato di Config Sync del cluster è ancora Synced a un commit precedente per un periodo di tempo superiore a spec.git.period, devi controllare i log del container git-sync:

# check git-sync logs for a root reconciler
kubectl logs -n config-management-system deployment/root-reconciler -c git-sync

# check git-sync logs for a namespace reconciler
kubectl logs -n config-management-system deployment/ns-reconciler-NAMESPACE -c git-sync

È probabile che git-sync non riesca a eseguire la sincronizzazione dal repository Git, ma il rivenditore continua la sincronizzazione dal commit sincronizzato in precedenza. Il seguente output di esempio indica che hai un problema git-sync:

"msg"="unexpected error syncing repo, will retry" "error"="Run(git fetch -f
--tags --depth 1 origin develop): exit status 128: { stdout: "", stderr: "fatal:
couldn't find remote ref develop\n" }"

Webhook rifiuta la richiesta di aggiornamento/eliminazione di una risorsa gestita da RootSync/RepoSync eliminato

L'eliminazione di un oggetto RootSync o RepoSync non elimina le annotazioni e le etichette di Config Sync e il webhook di ammissione Config Sync nega le richieste di tentativo di modificare o eliminare queste risorse se Config Sync è ancora abilitato nel cluster.

Se il tuo intento è conservare queste risorse gestite, per prima cosa puoi annullarne la gestione impostando l'annotazione configmanagement.gke.io/managed su disabled per ogni risorsa gestita dichiarata nel repository Git. In questo modo le annotazioni e le etichette di Config Sync vengono rimosse dalle risorse gestite, ma non vengono eliminate. Al termine della sincronizzazione, puoi rimuovere l'oggetto RootSync o RepoSync.

Se l'intento è quello di eliminare queste risorse gestite, puoi prima eliminarle utilizzando l'oggetto RootSync o RepoSync per la sincronizzazione da una directory Git vuota. Al termine della sincronizzazione, puoi rimuovere l'oggetto RootSync o RepoSync.

Se l'oggetto RootSync o RepoSync è stato eliminato prima di annullare la gestione o l'eliminazione delle risorse gestite, puoi aggiungere di nuovo l'oggetto RootSync o RepoSync, annullare la gestione o eliminare le risorse gestite, quindi eliminare di nuovo l'oggetto RootSync o RepoSync.

Scalabilità automatica pod orizzontale non funzionante

Config Sync gestisce tutti i campi specificati nei manifest nel tuo repository Git. Potrebbero verificarsi combattimenti tra le risorse quando due controller tentano di controllare lo stesso campo e si verificano quando provi a utilizzare la scalabilità automatica pod orizzontale con Config Sync.

Se vuoi utilizzare la scalabilità automatica pod orizzontale, devi lasciare che sia il gestore della scalabilità automatica orizzontale a gestire il campo spec.replicas rimuovendo il campo da tutti i manifest nel repository Git. In caso contrario, Config Sync tenta di annullare le modifiche apportate a quanto specificato nel repository.

PersistentVolumeClaim è in stato Lost

Quando esegui l'upgrade di un cluster Kubernetes alla versione 1.22 e successive, è possibile che gli oggetti PersistentVolumeClaim gestiti possano generare uno stato Lost. Questo si verifica quando l'associazione di PersistentVolume e PersistentVolumeClaim viene definito tramite il campo claimRef all'interno di una risorsa PersistentVolume. Le modifiche a monte di Kubernetes hanno reso il campo claimRef atomico, il che causa questo bug poiché impedisce a proprietari di campi diversi per i diversi sottocampi claimRef quando si applica il lato server.

Fino a quando questo problema non viene risolto nell'upstream Kubernetes (GitHub issue tracker, bug-fix PR), ti consigliamo di aggiornare le risorse PersistentVolume e PersistentVolumeClaim per utilizzare un metodo alternativo di binding. L'associazione può invece essere impostata all'interno della risorsa spec.volumeName di PersistentVolumeClaim. Questa operazione può essere eseguita in Kubernetes versione 1.21 e precedenti per evitare interruzioni durante l'upgrade alla versione 1.22.

Di seguito è riportato un esempio minimo di associazione di staging-pvc a staging-pv:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: staging-pvc
  namespace: staging
spec:
  volumeName: staging-pv
  ...

---

apiVersion: v1
kind: PersistentVolume
metadata:
  name: staging-pv
spec:
  ...

L'utilizzo di volumeName anziché claimRef per l'associazione non garantisce alcun privilegio di associazione a PersistentVolume.

Risoluzione dei messaggi di errore

KNV1045: non sono consentite configurazioni con stato specificato

Se specifichi un campo status nel repository di codice sorgente, verrà visualizzato KNV1045: le configurazioni con "stato" specificato non sono consentite. Non è consentito utilizzare Config Sync per sincronizzare il campo status. Un altro controller deve gestire e aggiornare il campo status nel cluster in modo dinamico. Se Config Sync tenta di controllare lo stato desiderato del campo status, combatte con il controller responsabile della gestione del campo status.

Per correggere questo errore, rimuovi il campo status dal repository di origine. Per configurazioni di terze parti che non sono di tua proprietà, utilizza le patch kustomize per rimuovere collettivamente i campi status specificati nei manifest.

KNV2004: impossibile sincronizzare il repository durante l'errore nel container git-sync

Config Sync crea un clone minimo del tuo repository Git. In rari casi, Config Sync potrebbe non riuscire a trovare il commit dal clone poco profondo. In questo caso, Config Sync aumenta il numero di commit Git da recuperare.

Puoi impostare il numero di commit Git da recuperare impostando il campo spec.override.gitSyncDepth in un oggetto RootSync o RepoSync:

  • Se questo campo non viene fornito, Config Sync lo configura automaticamente.
  • Config Sync esegue un clone completo se il campo è pari a 0 e un clone poco profondo se il campo è maggiore di 0.
  • Non è consentito impostare questo campo su un valore negativo.

Ecco un esempio di impostazione del numero di commit Git da recuperare su 88:

apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  override:
    gitSyncDepth: 88
  git:
    ...

Esegui questo comando per verificare che la modifica abbia effetto (GIT_SYNC_DEPTH deve essere impostato su 88 nel campo data dell'oggetto ConfigMap root-reconciler-git-sync):

kubectl get cm root-reconciler-git-sync -n config-management-system -o yaml

Puoi sostituire il numero di commit Git da recuperare in un riconciliatore dello spazio dei nomi in modo simile.

Errore: autorizzazione negata

Se viene visualizzato un messaggio di errore simile all'esempio seguente quando provi a configurare Config Sync, potresti non avere il ruolo Amministratore GKE Hub:

Permission 'gkehub.features.create' denied on 'projects/PROJECT_ID/locations/global/features/configmanagement'

Per assicurarti di avere le autorizzazioni richieste, assicurati di aver concesso i ruoli IAM richiesti.

Errore: il webhook di ammissione ha rifiutato una richiesta

Se viene visualizzato il messaggio di errore seguente quando tenti di applicare una modifica a un campo gestito da Config Sync, è possibile che la modifica sia stata in conflitto:

error: OBJECT could not be patched: admission webhook "v1.admission-webhook.configsync.gke.io"
denied the request: fields managed by Config Sync can not be modified

Quando dichiari un campo in una configurazione e il tuo repository è sincronizzato con un cluster, Config Sync gestisce tale campo. Qualsiasi modifica che provi a modificare in questo campo è una modifica in conflitto.

Ad esempio, se nel repository è presente una configurazione di deployment con un'etichetta environment:prod e cerchi di modificare l'etichetta in environment:dev nel cluster, si verificherà una modifica in conflitto e riceverai il messaggio di errore precedente. Tuttavia, se aggiungi una nuova etichetta (ad esempio tier:frontend) al deployment, non si verifica alcun conflitto.

Se vuoi che Config Sync ignori qualsiasi modifica di un oggetto, puoi aggiungere l'annotazione descritta in Ignorare le mutazioni dell'oggetto.

Errore: timeout I/O della richiesta di webhook di ammissione

Se ricevi il seguente errore quando il riconciliatore cerca di applicare una configurazione al cluster, la porta del webhook di ammissione 8676 potrebbe essere bloccata dal firewall nella rete del piano di controllo:

KNV2009: Internal error occurred: failed calling webhook "v1.admission-webhook.configsync.gke.io": Post https://admission-webhook.config-management-system.svc:8676/admission-webhook?timeout=3s: dial tcp 10.1.1.186:8676: i/o timeout

Per risolvere questo problema, aggiungi una regola firewall per consentire la porta 8676, che il webhook di ammissione di Config Sync utilizza per la prevenzione delle deviazioni.

Errore: connessione webhook di ammissione rifiutata

Se viene visualizzato il seguente errore quando un riconciliatore tenta di applicare una configurazione al cluster, significa che il webhook di ammissione non è ancora pronto:

KNV2009: Internal error occurred: failed calling webhook "v1.admission-webhook.configsync.gke.io": Post "https://admission-webhook.config-management-system.svc:8676/admission-webhook?timeout=3s": dial tcp 10.92.2.14:8676: connect: connection refused

Si tratta di un errore temporaneo che potresti visualizzare durante il bootstrap di Config Sync. Se il problema persiste, dai un'occhiata al deployment del webhook di ammissione per verificare se i suoi pod possono essere pianificati e sono integri.

kubectl describe deploy admission-webhook -n config-management-system

kubectl get pods -n config-management-system -l app=admission-webhook

Errore: impossibile montare il secret Git

Se viene visualizzato il seguente errore quando il container git-sync tenta di sincronizzare un repository con un secret, il secret Git non viene montato correttamente nel container git-sync:

KNV2004: unable to sync repo Error in the git-sync container: ERROR: can't configure SSH: can't access SSH key: stat /etc/git-secret/ssh: no such file or directory: lstat /repo/root/rev: no such file or directory

L'errore potrebbe essere causato dal passaggio del tipo di autenticazione del tuo repository Git da none, gcenode o gcpserviceaccount ad altri tipi che richiedono un secret.

Per risolvere questo problema, esegui questi comandi per riavviare il gestore di riconciliazione e i riconciliatori:

# Stop the reconciler-manager Pod. The reconciler-manager Deployment will spin
# up a new Pod which can pick up the latest `spec.git.auth`.
kubectl delete po -l app=reconciler-manager -n config-management-system

# Delete the reconciler Deployments. The reconciler-manager will recreate the
# reconciler Deployments with correct volume mount.
kubectl delete deployment -l app=reconciler -n config-management-system

Errore: impossibile estrarre le basi remote dai repository pubblici

Se viene visualizzato il seguente errore durante il processo di rendering, quando provi a estrarre basi remote dai repository pubblici, il processo di rendering non viene completato correttamente:

KNV1068: failed to run kustomize build in /repo/source/0a7fd88d6c66362584131f9dfd024024352916af/remote-base, stdout:...
no 'git' program on path: exec: "git": executable file not found in $PATH

For more information, see https://g.co/cloud/acm-errors#knv1068

Per risolvere questo problema, in Anthos Config Management versione 1.12.0 e successive, imposta spec.override.enableShellInRendering come true.

I contenitori reconciler, hydration-controller e/o git-sync sono OOMKilled

Puoi sostituire le richieste di CPU e/o memoria e i limiti di un repository radice o dello spazio dei nomi. Per sostituire questi valori, utilizza il campo spec.override.resources di un oggetto RootSync o RepoSync.

L'esempio seguente mostra come eseguire l'override dei limiti di CPU e memoria del container reconciler e della richiesta di CPU e del limite di memoria del container git-sync di un riconciliatore root. È consentito eseguire l'override dei soli container git-sync e reconciler. È consentito eseguire un override parziale: quando non viene fornito un valore di sostituzione per una richiesta di risorse o un limite, viene utilizzato il valore predefinito della risorsa.

apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  sourceFormat: "unstructured"
  override:
    resources:
    - containerName: "reconciler"
      cpuLimit: "800m"
      memoryLimit: "500Mi"
    - containerName: "git-sync"
      cpuRequest: "100m"
      memoryLimit: "400Mi"
  git:
     ...

Esegui questo comando per verificare che i nuovi limiti delle risorse abbiano effetto:

kubectl get deployment.apps/root-reconciler -n config-management-system -o yaml

Puoi sostituire, allo stesso modo, i limiti delle risorse di un riconciliatore dello spazio dei nomi.

Errore: uno spazio dei nomi si blocca nella fase Terminating

Uno spazio dei nomi bloccato nella fase Terminating deve avere la seguente condizione:

    message: 'Failed to delete all resource types, 1 remaining: admission webhook
      "v1.admission-webhook.configsync.gke.io" denied the request: system:serviceaccount:kube-system:namespace-controller
      is not authorized to delete managed resource "_configmap_bookstore_cm1"'
    reason: ContentDeletionFailed
    status: "True"
    type: NamespaceDeletionContentFailure

Questo errore si verifica quando tenti di eliminare uno spazio dei nomi da un repository principale, ma alcuni oggetti nello spazio dei nomi sono comunque gestiti attivamente da un riconciliatore dello spazio dei nomi. Quando uno spazio dei nomi viene eliminato, il controller dello spazio dei nomi, il cui account di servizio è system:serviceaccount:kube-system:namespace-controller, tenterà di eliminare tutti gli oggetti nello spazio dei nomi. Tuttavia, il hub di ammissione Config Sync consente solo al riconciliatore radice o dello spazio dei nomi di eliminare questi oggetti e nega il controller dello spazio dei nomi per eliminarli.

La soluzione alternativa consiste nell'eliminare il webhook di ammissione di Config Sync:

kubectl delete deployment.apps/admission-webhook -n config-management-system

L'operatore Config Management ricrea il webhook di ammissione di Config Sync.

Se questa soluzione alternativa non funziona, potresti dover reinstallare Config Sync.

Per evitare di riscontrare di nuovo l'errore, rimuovi il repository dello spazio dei nomi prima di rimuovere lo spazio dei nomi.

Errore: campo webhooks non trovato in ValidatingWebhookConfiguration

Se riscontri i seguenti errori nei log webhook di ammissione di Config Sync durante l'esecuzione di kubectl logs -n config-management-system -l app=admission-webhook:

cert-rotation "msg"="Unable to inject cert to webhook." "error"="`webhooks` field not found in ValidatingWebhookConfiguration" "gvk"={"Group":"admissionregistration.k8s.io","Version":"v1","Kind":"ValidatingWebhookConfiguration"} "name"="admission-webhook.configsync.gke.io"
controller-runtime/manager/controller/cert-rotator "msg"="Reconciler error" "error"="`webhooks` field not found in ValidatingWebhookConfiguration" "name"="admission-webhook-cert" "namespace"="config-management-system"

Ciò significa che root-reconciler non ha sincronizzato alcuna risorsa nel cluster. Il problema potrebbe essere dovuto al fatto che root-reconciler non è ancora pronto oppure non è presente nulla da sincronizzare dal repository Git (ad esempio, la directory di sincronizzazione è vuota). Se il problema persiste, devi controllare lo stato di root-reconciler:

kubectl get pods -n config-management-system -l configsync.gke.io/reconciler=root-reconciler

Se root-reconciler sta subendo un arresto anomalo o OOMKilled, aumenta i limiti di risorse.

Errore: impossibile creare l'esportatore Stackdriver/GoogleCloud

Quando un componente in OpenTelemetry Collector non può accedere all'account di servizio predefinito nello stesso spazio dei nomi, potresti notare che il pod otel-collector in config-management-monitoring è in stato CrashLoopBackoff oppure potresti visualizzare un messaggio di errore simile al seguente:

Error: cannot build exporters: error creating stackdriver exporter: cannot configure Google Cloud metric exporter: stackdriver: google: could not find default credentials. See https://developers.google.com/accounts/docs/application-default-credentials for more information.

Questo problema si verifica di solito quando Workload Identity è abilitato nel cluster.

Per risolvere questo problema, segui le istruzioni riportate in Monitoring Config Sync per concedere l'autorizzazione di scrittura delle metriche all'account di servizio predefinito.

Se l'errore persiste dopo la configurazione di IAM, riavvia il pod otel-collector per rendere effettive le modifiche.