Risolvere gli errori di autorizzazione in Backup per GKE

Questo documento descrive gli errori e i codici corrispondenti che potresti riscontrare quando utilizzi Backup per GKE per eseguire operazioni di ripristino. In ogni sezione sono inclusi aspetti da considerare quando esegui azioni per risolvere gli errori di ripristino e istruzioni su come risolvere gli errori dell'operazione di ripristino.

Errore 200010301: impossibile completare l'operazione di ripristino a causa del servizio webhook di ammissione non disponibile

L'errore 200010301 si verifica quando un tentativo di completare un'operazione di ripristino non va a buon fine perché un servizio webhook di ammissione, chiamato anche callback HTTP, non è disponibile, il che genera il seguente messaggio di errore. Il messaggio di errore indica che il server API GKE ha tentato di contattare un webhook di controllo dell'ammissione durante il tentativo di ripristinare una risorsa, ma il servizio di supporto del webhook non era disponibile o non è stato trovato:

  resource [/example-group/ClusterSecretStore/example-store] restore failed:

  Internal error occurred: failed calling webhook "example-webhook.io":
  failed to call webhook: Post "https://example-webhook.example-namespace.svc:443/validate-example": service "example-webhook" not found.

Questo errore si verifica quando una risorsa GKE ValidatingAdmissionWebhook o MutatingAdmissionWebhook è attiva nel cluster di destinazione, ma il server API GKE non riesce a raggiungere l'endpoint configurato nel webhook. Gli webhook di controllo degli accessi intercettano le richieste al server API GKE e la loro configurazione specifica in che modo il server API GKE deve eseguire query sulle richieste.

clientConfig del webhook specifica il backend che gestisce le richieste di ammissione, che può essere un servizio di cluster interno o un URL esterno. La scelta tra queste due opzioni dipende dai requisiti operativi e architetturali specifici del tuo webhook. A seconda del tipo di opzione, l'operazione di ripristino potrebbe non essere riuscita per i seguenti motivi:

  • Servizi nel cluster: il servizio GKE e i relativi pod di supporto non vengono ripristinati o non sono pronti quando il server API GKE ha tentato di chiamare il webhook. Ciò si verifica durante le operazioni di ripristino in cui le configurazioni webhook con ambito cluster vengono applicate prima che i servizi con spazio dei nomi si trovino completamente nello stato ready.

  • URL esterni: l'endpoint esterno non è temporaneamente disponibile a causa di problemi di connettività di rete tra il cluster GKE e l'endpoint esterno oppure a causa di problemi di risoluzione DNS o regole firewall.

Per risolvere questo errore, segui queste istruzioni:

  1. Identifica il webhook non riuscito menzionato nel messaggio di errore. Ad esempio: failed calling webhook "...".

  2. Ispeziona il webhook eseguendo il comando kubectl get validatingwebhookconfigurations:

    kubectl get validatingwebhookconfigurations WEBHOOK_NAME -o yaml

    Sostituisci WEBHOOK_NAME con il nome del webhook identificato nel messaggio di errore.

    Puoi anche eseguire il comando kubectl get mutatingwebhookconfigurations per esaminare il webhook:

    kubectl get mutatingwebhookconfigurations WEBHOOK_NAME -o yaml

    Sostituisci WEBHOOK_NAME con il nome del webhook identificato nel messaggio di errore.

  3. Esegui la seguente procedura per la risoluzione dei problemi in base al tipo di configurazione:

    Basato sul servizio clientConfig

    Definisci un ordine di ripristino personalizzato modificando la risorsa RestorePlan in modo da includere un RestoreOrder con voci GroupKindDependency. In questo modo, i componenti che supportano il webhook, come Deployment, StatefulSet o Service, vengono ripristinati e sono pronti prima di ValidatingWebhookConfiguration o MutatingWebhookConfiguration.

    Per istruzioni su come definire un ordine di ripristino personalizzato, vedi Specifica l'ordine di ripristino delle risorse durante il ripristino.

    Questo approccio può non riuscire perché i pod del servizio non entrano in uno stato ready completo anche dopo la creazione dell'oggetto Service. Un altro motivo del mancato funzionamento potrebbe essere che la configurazione del webhook è stata creata in modo imprevisto da un'altra applicazione. In alternativa, puoi eseguire un'operazione di ripristino in due fasi seguendo questi passaggi:

    1. Crea una risorsa Restore utilizzando il backup configurando l'operazione di ripristino con un filtro di ripristino granulare che includa le risorse specifiche necessarie per il funzionamento del webhook, ad esempio Namespaces, Deployments, StatefulSets o Services.

      Per ulteriori informazioni su come configurare il ripristino con un filtro di ripristino granulare, consulta Abilita il ripristino granulare.

    2. Crea un'altra risorsa Restore per l'operazione di backup e configura le altre risorse che scegli.

    Basato sull'URL clientConfig

    1. Verifica l'endpoint HTTPS esterno e assicurati che sia attivo, raggiungibile e funzionante correttamente.

    2. Verifica che esista una connettività di rete dai nodi e dal control plane del cluster GKE all'URL esterno. Potresti anche dover controllare le regole firewall, ad esempio se utilizzi Virtual Private Cloud, on-premise o un provider cloud che ospita il webhook, i criteri di rete e la risoluzione DNS.

  4. Riprova l'operazione di ripristino. Se l'operazione continua a non riuscire, contatta l'assistenza clienti Google Cloud per ulteriore assistenza.

Errore 200010302: Impossibile completare l'operazione di ripristino a causa della richiesta di creazione della risorsa negata

L'errore 200010302 si verifica quando un tentativo di completare un'operazione di ripristino non va a buon fine perché un webhook di controllo degli accessi nega una richiesta di creazione di risorse, il che comporta il seguente messaggio di errore che indica che una risorsa del backup non è stato possibile creare nel cluster di destinazione perché un webhook di controllo degli accessi attivo ha intercettato la richiesta e l'ha rifiutata in base a un criterio personalizzato:

  [KubeError]; e.g. resource

  [/example-namespace/example-api/ExampleResource/example-name]

  restore failed: admission webhook "example-webhook.example.com" denied the request: {reason for denial}

Questo errore è causato dalla configurazione impostata nel cluster GKE di destinazione, che ha un ValidatingAdmissionWebhook o un MutatingAdmissionWebhook che applica regole specifiche alla creazione e alla modifica delle risorse, bloccando la richiesta di creazione delle risorse. Ad esempio, un webhook impedisce la creazione di una risorsa perché nel cluster esiste già una risorsa correlata, ma in conflitto. Ad esempio, un webhook potrebbe negare la creazione di un deployment se è già gestito da una risorsa API GKE HorizontalPodAutoscaler.

Per risolvere questo errore, segui queste istruzioni:

  1. Identifica il webhook che nega la richiesta utilizzando il messaggio di errore che si verifica quando l'operazione di ripristino non va a buon fine. Ad esempio, webhook WEBHOOK_NAME denied the request Il messaggio di errore contiene le seguenti informazioni:

    • Nome webhook: il nome del webhook che nega la richiesta.

    • Motivo del rifiuto: il motivo specifico del rifiuto della richiesta.

  2. Ispeziona il webhook eseguendo il comando kubectl get validatingwebhookconfigurations:

    kubectl get validatingwebhookconfigurations WEBHOOK_NAME -o yaml

    Sostituisci WEBHOOK_NAME con il nome del webhook che hai identificato nel messaggio di errore.

    Puoi anche eseguire il comando kubectl get mutatingwebhookconfigurations per ispezionare il webhook:

    kubectl get mutatingwebhookconfigurations WEBHOOK_NAME -o yaml

    Sostituisci WEBHOOK_NAME con il nome del webhook che hai identificato dal messaggio di errore.

  3. Risolvi il problema sottostante nel cluster di destinazione. L'azione corretta dipende dall'errore specifico. Per l'esempio, se esiste un conflitto HorizontalPodAutoscaler, devi eliminare l'HorizontalPodAutoscaler esistente nel cluster di destinazione prima di eseguire il ripristino per consentire la creazione dei carichi di lavoro di cui è stato eseguito il backup e delle risorse associate.

  4. Riprova l'operazione di ripristino. Se l'operazione di ripristino continua a non riuscire, contatta l'assistenza clienti Google Cloud per ulteriore assistenza.

Errore 200060202: impossibile completare l'operazione di ripristino a causa della risorsa GKE mancante durante la convalida del workload

L'errore 200060202 si verifica durante la fase di convalida del carico di lavoro di un'operazione di ripristino quando una risorsa GKE che Backup per GKE prevede di convalidare non viene trovata nel cluster di destinazione, il che genera il seguente messaggio di errore:

  Workload Validation Error: [KIND] "[NAME]" not found

Ad esempio, Example: Workload Validation Error: pods "jenkins-0" not found

Questo errore si verifica quando Backup per GKE crea o aggiorna correttamente la risorsa GKE nell'ambito del processo di operazione di ripristino, ma quando inizia la fase di convalida, una o più risorse GKE non sono più presenti nel cluster di destinazione perché sono state eliminate dopo la creazione o l'aggiornamento iniziale da parte del processo di ripristino, ma prima che la convalida del workload per la risorsa GKE potesse essere completata. Un errore di questo tipo può verificarsi per i seguenti motivi:

  • Eliminazione manuale: un utente o un amministratore ha eliminato manualmente la risorsa utilizzando kubectl o altri strumenti Google Cloud .

  • Automazione esterna: i controller GitOps, ad esempio Config Sync, ArgoCD, Flux, script personalizzati o altri strumenti di gestione dei cluster hanno ripristinato o eliminato la risorsa in modo che corrisponda a uno stato desiderato in un repository.

  • Controller GKE: un controller GKE ha eliminato una risorsa perché è in conflitto con altre risorse o criteri oppure una catena OwnerReference porta alla garbage collection o al processo di pulizia automatica di GKE che elimina le risorse dipendenti quando viene eliminata la risorsa owner.

Per risolvere questo errore, segui queste istruzioni:

  1. Identifica la risorsa mancante utilizzando il messaggio di errore visualizzato quando l'operazione di ripristino non viene completata.

  2. Individua lo spazio dei nomi a cui appartiene la risorsa utilizzando uno dei seguenti metodi:

    • Audit log di GKE: esamina gli audit log di GKE generati quando hai tentato l'operazione di ripristino. Puoi filtrare i log per le operazioni di eliminazione sulla risorsa Kind e Name. La voce di log di controllo contiene lo spazio dei nomi originale.

    • Dettagli backup: rivedi l'ambito dell'operazione di ripristino e i contenuti del backup. L'indice di backup mostra lo spazio dei nomi originale della risorsa. Puoi anche verificare se RestorePlan contiene un TransformationRule che specifica le regole per ripristinare la risorsa nello spazio dei nomi che scegli.

    • Cerca negli spazi dei nomi: esegui il comando kubectl get per cercare la risorsa in tutti gli spazi dei nomi:

      kubectl get KIND --all-namespaces | grep NAME

      Sostituisci KIND e NAME con i valori del messaggio di errore. Se la risorsa esiste ancora, questo comando mostrerà il suo spazio dei nomi.

  3. Verifica l'eliminazione eseguendo il comando kubectl get:

    kubectl get KIND NAME -n [NAMESPACE]

    Sostituisci KIND e NAME con i valori del messaggio di errore. Dovresti ricevere un messaggio di errore not found.

  4. Indaga sulla causa dell'eliminazione utilizzando uno dei seguenti metodi:

    • Audit log di GKE: identificano l'entità che ha emesso la richiesta di eliminazione. Ad esempio, l'utente, il account di servizio o il controller.

    • Controlla le automazioni configurate: se utilizzi GitOps o altri strumenti di automazione, controlla i log e lo stato per verificare se hanno interferito con le risorse ripristinate.

    • Esamina gli eventi correlati: controlla gli eventi GKE nello spazio dei nomi determinato eseguendo il comando kubectl get events:

      kubectl get events -n NAMESPACE_NAME --sort-by='.lastTimestamp'

      Sostituisci NAMESPACE_NAME con il nome dello spazio dei nomi.

  5. Risolvi la causa dell'eliminazione della risorsa in base ai risultati del passaggio precedente. Ad esempio, metti in pausa le automazioni in conflitto, correggi le configurazioni errate o modifica le autorizzazioni utente.

  6. Recupera la risorsa mancante utilizzando uno dei seguenti metodi:

    • Riapplica i file manifest: se hai il manifest per la risorsa mancante, puoi riapplicarlo allo spazio dei nomi corretto.

    • Esegui un ripristino granulare: esegui un'operazione di ripristino granulare per ripristinare in modo selettivo solo la risorsa mancante dallo stesso backup, il che ti consente di specificare lo spazio dei nomi corretto. Per ulteriori informazioni su come eseguire un'operazione di ripristino granulare, vedi Abilita il ripristino granulare.

  7. Riprova l'operazione di ripristino. Se l'operazione di ripristino continua a non riuscire, contatta l'assistenza clienti Google Cloud per ulteriore assistenza.

Errore 200060201: impossibile completare l'operazione di ripristino a causa del timeout della convalida del workload

L'errore 200060201 si verifica quando uno o più workload ripristinati non diventano completamente ready durante un'operazione di ripristino entro il limite di tempo previsto dopo la creazione delle risorse nel cluster, con conseguente messaggio di errore seguente:

Workload Validation Error: Timedout waiting for workloads to be ready - [namespace/workload_name, ...]

Questo errore si verifica perché Backup per GKE esegue un passaggio di convalida dopo il ripristino delle configurazioni delle risorse GKE per garantire il corretto funzionamento dei carichi di lavoro critici. Backup per GKE attende che determinati carichi di lavoro raggiungano lo stato ready, ma almeno un carico di lavoro non ha soddisfatto il seguente criterio di disponibilità entro il periodo di timeout allocato:

  • Per Pods: status.Phase è Running

  • Per Deployments: status.ReadyReplicas è uguale a spec.Replicas

  • Per StatefulSets: status.ReadyReplicas è uguale a spec.Replicas

  • Per DaemonSets: status.NumberReady è uguale a status.DesiredNumberScheduled

Per risolvere questo errore, segui queste istruzioni:

  1. Identifica i workload che non si trovano nello stato ready nel messaggio di errore che elenca i workload e i relativi spazi dei nomi che non sono riusciti a entrare nello stato ready.

  2. Ispeziona lo stato del workload e ottieni dettagli ed eventi per i workload non riusciti eseguendo il comando kubectl describe:

    kubectl describe WORKLOAD_TYPE WORKLOAD_NAME -n NAMESPACE_NAME
kubectl get pods -n NAMESPACE_NAME -l SELECTOR_FOR_WORKLOAD

    Sostituisci quanto segue:

    • WORKLOAD_TYPE: il tipo di workload, ad esempio Deployment, StatefulSet o DaemonSet.

    • WORKLOAD_NAME: il nome dell'istanza del workload specifico.

    • NAMESPACE_NAME: lo spazio dei nomi in cui si trova il workload.

    • SELECTOR_FOR_WORKLOAD: il selettore di etichette per trovare Pods associato al workload. Ad esempio: app=my-app.

    Per i pod all'interno dei tipi di workload Deployments o StatefulSets, controlla lo stato dei singoli pod eseguendo il comando kubectl describe pod:

    kubectl describe pod POD_NAME -n NAMESPACE_NAME

    Sostituisci quanto segue:

    • POD_NAME: il nome del pod specifico.

    • NAMESPACE_NAME: lo spazio dei nomi in cui si trova il pod.

  3. Nella sezione Events, analizza gli eventi e i log nell'output describe e individua le seguenti informazioni:

    • ImagePullBackOff / ErrImagePull: indica che si sono verificati problemi durante il recupero delle immagini container.

    • CrashLoopBackOff: indica che i container si avviano e si arrestano in modo anomalo.

  4. Nella sezione Containers, analizza i log dei container nell'output describe per trovare il nome del container eseguendo il comando kubectl logs:

    kubectl logs POD_NAME -n NAMESPACE_NAME -c CONTAINER_NAME

    Sostituisci quanto segue:

    • POD_NAME: il nome del pod specifico.

    • NAMESPACE_NAME: lo spazio dei nomi in cui si trova il pod.

    • CONTAINER_NAME: il nome del container all'interno del pod.

    Secondo l'output di describe, esistono diversi motivi per cui il pod potrebbe non essere visualizzato nell'output della risorsa, tra cui:

    • Errori del probe di idoneità: i probe di idoneità del container non vanno a buon fine.

    • Problemi relativi alle risorse: CPU, memoria o altre risorse insufficienti nel cluster o raggiungimento dei limiti di quota.

    • Problemi con i container di inizializzazione: errori nei container di inizializzazione che impediscono l'avvio dei container principali.

    • Errori di configurazione: errori in ConfigMaps, Secrets o nelle variabili di ambiente.

    • Problemi di rete: Pods non riesce a comunicare con i servizi richiesti.

  5. Controlla le risorse del cluster GKE per assicurarti che il cluster GKE disponga di capacità dei nodi, CPU e memoria sufficienti per eseguire i workload ripristinati. Nei cluster Autopilot, il provisioning automatico dei nodi potrebbe richiedere più tempo, pertanto ti consigliamo di verificare la presenza di eventuali limitazioni o errori di scalabilità dei nodi. Risolvi i problemi di base in base ai risultati e risolvi i problemi che impediscono ai workload di entrare in uno stato ready. Questo approccio può comportare la correzione dei manifest, la modifica delle richieste o dei limiti delle risorse, la correzione delle norme di rete o la garanzia che le dipendenze siano soddisfatte.

  6. Una volta risolti i problemi di fondo, attendi che i workload entrino nello stato ready. Non è necessario eseguire di nuovo l'operazione di ripristino.

Se il problema persiste, contatta l'assistenza clienti Google Cloud per ulteriore assistenza.

Errore 200060102: Impossibile completare l'operazione di ripristino a causa di un errore di convalida del volume

L'errore 200060102 si verifica perché una o più risorse VolumeRestore, che gestiscono il processo di ripristino dei dati da VolumeBackup a un PersistentVolume, sono entrate in uno stato failed o deleting durante la fase di convalida del volume di un'operazione di ripristino. Il ripristino del volume non riuscito genera il seguente messaggio di errore nel campo stateReason della risorsa di ripristino:

Volume Validation Error: Some of the volume restores failed - [projects/PROJECT_ID/locations/LOCATION/restorePlans/RESTORE_PLAN_ID/restores/RESTORE_ID/volumeRestores/VOLUME_RESTORE_ID (PVC: NAMESPACE/PVC_NAME), ...]

Il messaggio di errore elenca i nomi completi delle risorse VolumeRestore non riuscite, inclusi il nome e lo spazio dei nomi PersistentVolumeClaim di destinazione. Il messaggio di errore indica che la procedura di ripristino dei dati per PersistentVolumeClaim interessato non è stata completata correttamente quando Backup per GKE ha avviato le risorse VolumeRestore per il provisioning di PersistentVolumes da VolumeBackups e la creaziPersistent Diskente sottostante dallo snapshot non è riuscita. Gli errori VolumeRestore possono verificarsi per i seguenti motivi:

  • Quota insufficiente: la quota di Persistent Disk allocata nel progetto o nella regione non è sufficiente, ad esempio SSD_TOTAL_GB.

  • Problemi di autorizzazione: l'account di servizio utilizzato da Backup per GKE non dispone delle autorizzazioni necessarie per creare dischi o accedere agli snapshot.

  • Problemi di rete: si verificano problemi di rete transitori o persistenti che interrompono il processo di creazione del disco.

  • Snapshot non valido: l'origine VolumeBackup o lo snapshot Persistent Disk sottostante è danneggiato o inaccessibile.

  • Vincoli delle risorse: altri vincoli delle risorse del cluster ostacolano il provisioning del volume.

  • Errori interni: si sono verificati problemi interni al servizio Persistent Disk.

Per risolvere questo errore, segui queste istruzioni:

  1. Identifica il PersistentVolumeClaims non riuscito elencato nel messaggio di errore, che elenca i nomi completi delle risorse degli oggetti VolumeRestore non riusciti.

  2. Per visualizzare i dettagli di ogni risorsa VolumeRestore non riuscita, esegui il comando gcloud beta container backup-restore volume-restores describe:

    gcloud beta container backup-restore volume-restores describe VOLUME_RESTORE_ID \
--project=PROJECT_ID \
--location=LOCATION \
--restore-plan=RESTORE_PLAN_ID \
--restore=RESTORE_ID

    Sostituisci quanto segue:

    • VOLUME_RESTORE_ID: l'ID della risorsa VolumeRestore non riuscita.

    • PROJECT_ID: l'ID del tuo Google Cloud progetto.

    • LOCATION: la Google Cloud posizione del ripristino.

    • RESTORE_PLAN_ID: l'ID del piano di ripristino.

    • RESTORE_ID: l'ID dell'operazione di ripristino.

  3. Esamina i campi state e stateMessage nell'output per i dettagli relativi all'errore.

  4. Esamina lo stato della destinazione PersistentVolumeClaim eseguendo il comando kubectl get pvc:

    kubectl get pvc PVC_NAME -n NAMESPACE_NAME -o yaml

    Sostituisci quanto segue:

    • PVC_NAME: il nome della risorsa PersistentVolumeClaim.

    • NAMESPACE_NAME: lo spazio dei nomi in cui si trova PersistentVolumeClaim.

  5. Verifica che la sezione status.phase dell'output indichi una fase Pending. Questa fase indica che PersistentVolumeClaim non è ancora associato a un PersistentVolume, il che è previsto se VolumeRestore non va a buon fine.

  6. Esamina la sezione Events nell'output YAML per i messaggi relativi a errori di provisioning, ad esempio ProvisioningFailed, ad esempio:

    Cloud KMS error when using key projects/PROJECT_ID/locations/LOCATION/keyRings/KEY_RING/cryptoKeys/CRYPTO_KEY:  Permission 'cloudkms.cryptoKeyVersions.useToEncrypt' denied  on resource 'projects/PROJECT_ID/locations/LOCATION/keyRings/KEY_RING/cryptoKeys/CRYPTO_KEY' (or it may not exist).

    L'output indica che si è verificato un problema di autorizzazione durante l'accesso alla chiave di crittografia durante la creazione del disco. Per fornire l'autorizzazione pertinente per accedere alla chiave, utilizza le istruzioni descritte nella documentazione di Backup per GKE sull'attivazione della crittografia CMEK.compute service agent

  7. Esamina gli eventi GKE nello spazio dei nomi PersistentVolumeClaim, che forniscono messaggi di errore dettagliati dal controller PersistentVolume o dal driver CSI, eseguendo il comando kubectl get events:

    kubectl get events -n NAMESPACE_NAME --sort-by='.lastTimestamp'

    Sostituisci NAMESPACE_NAME con lo spazio dei nomi di PersistentVolumeClaim,

  8. Identifica gli eventi correlati al nome PersistentVolumeClaim, che contiene parole chiave come FailedProvisioning o ExternalProvisioning. Gli eventi possono contenere anche errori del provisioning di archiviazione, ad esempio pd.csi.storage.gke.io.

  9. Esamina i log del disco permanente controllando Cloud Audit Logs e i log Persistent Disk in Cloud Logging per individuare eventuali errori relativi alle operazioni di creazione del disco nel momento dell'errore.

  10. In base ai messaggi di errore generati, risolvi i seguenti problemi sottostanti:

    • Aumenta le quote di Persistent Disk, se indicato, ad esempio (QUOTA_EXCEEDED}: Quota SSD_TOTAL_GB exceeded.

    • Verifica e correggi le autorizzazioni IAM.

    • Esamina e risolvi i problemi di rete.

    • Contatta l'assistenza clienti Google Cloud per risolvere i problemi relativi allo snapshot o al servizio Persistent Disk.

    • PersistentVolumeClaim rimane nello stato Pending.

    • Il processo di ripristino non ripete automaticamente l'operazione VolumeRestore. Per risolvere il problema, devi attivare un'operazione di ripristino per il carico di lavoro Deployment o StatefulSet che utilizza il PersistentVolumeClaim interessato.

    • Utilizza un ripristino granulare per ripristinare in modo selettivo il carico di lavoro Deployment o StatefulSet associato al PersistentVolumeClaim non riuscito. Questo approccio consente ai meccanismi GKE standard di gestire nuovamente il processo di creazione e binding di PersistentVolumeClaim se il problema sottostante viene risolto. Per ulteriori informazioni sul ripristino granulare, vedi Abilita il ripristino granulare.

Se il problema persiste o la causa dell'errore VolumeRestore non è chiara, contatta l'assistenza clienti Google Cloud per ulteriore assistenza.

Errore 200060101: Impossibile completare l'operazione di ripristino a causa del timeout della convalida del volume

L'errore 200060101 si verifica durante la fase di convalida del volume di un'operazione di ripristino quando Backup per GKE smette di attendere perché almeno una risorsa VolumeRestore, che gestisce il ripristino dei dati da un VolumeBackup, non ha raggiunto lo stato succeeded entro il periodo di timeout allocato. Anche altre risorse VolumeRestore potrebbero essere incomplete.

Il messaggio di errore nel campo stateReason della risorsa Restore mostra la prima risorsa VolumeRestore rilevata che non si trovava ancora nello stato succeeded quando è stato controllato il timeout. Include il nome e lo spazio dei nomi PersistentVolumeClaim di destinazione per quel VolumeRestore specifico, ad esempio:

Volume Validation Error: Timed out waiting for volume restore [projects/PROJECT_ID/locations/LOCATION/restorePlans/RESTORE_PLAN_NAME/restores/RESTORE_NAME/volumeRestores/VOLUME_RESTORE_ID (PVC: PVC_NAMESPACE/PVC_NAME)]

Backup per GKE avvia il provisioning delle risorse VolumeRestore PersistentVolumes da VolumeBackups. L'errore indica che la creazione Persistent Disk sottostante dallo snapshot e il successivo binding di PersistentVolumeClaim a PersistentVolume hanno richiesto più tempo del timeout calcolato per VolumeRestore citato. Anche altri VolumeRestores per la stessa operazione di ripristino potrebbero essere in uno stato non completato.

Anche se il timeout è stato raggiunto dal punto di vista di Backup per GKE, il processo di creazione del disco sottostante per la risorsa VolumeRestore menzionata e potenzialmente per le risorse VolumeRestore potrebbe essere ancora in corso o non essere riuscito.

Per risolvere il problema, segui queste istruzioni:

  1. Identifica il nome e lo spazio dei nomi PersistentVolumeClaim scaduti nel messaggio di errore, ad esempio (PVC: PVC_NAMESPACE/PVC_NAME).

  2. Elenca tutti i VolumeRestores associati all'operazione di ripristino per visualizzarne gli stati attuali eseguendo il comando gcloud beta container backup-restore volume-restores list:

    gcloud beta container backup-restore volume-restores list \
--project=PROJECT_ID \
--location=LOCATION \
--restore-plan=RESTORE_PLAN_NAME \
--restore=RESTORE_NAME

    Sostituisci quanto segue:

    • PROJECT_ID: l'ID del Google Cloud progetto.

    • LOCATION: la Google Cloud posizione del ripristino.

    • RESTORE_PLAN_NAME: il nome del piano di ripristino.

    • RESTORE_NAME: il nome dell'operazione di ripristino.

  3. Individua VolumeRestores che non si trovano nello stato succeeded.

  4. Per visualizzare i dettagli relativi a VolumeRestore menzionato nell'errore e a qualsiasi altro VolumeRestores che non si trova nello stato succeeded, esegui il comando gcloud beta container backup-restore volume-restores describe:

    gcloud beta container backup-restore volume-restores describe VOLUME_RESTORE_ID \
--project=PROJECT_ID \
--location=LOCATION \
--restore-plan=RESTORE_PLAN_NAME \
--restore=RESTORE_NAME

    Sostituisci quanto segue:

    • VOLUME_RESTORE_ID: l'ID della risorsa VolumeRestore.

    • PROJECT_ID: l'ID del tuo Google Cloud progetto.

    • LOCATION: la Google Cloud posizione del ripristino.

    • RESTORE_PLAN_NAME: il nome del piano di ripristino.

    • RESTORE_NAME: il nome dell'operazione di ripristino.

  5. Controlla i campi state e stateMessage. Il valore del campo state è probabilmente creating o restoring. Il campo stateMessage potrebbe fornire più contesto e contenere i dettagli della PersistentVolumeClaim di destinazione.

  6. Esamina lo stato della destinazione identificata PersistentVolumeClaims eseguendo il comando kubectl get pvc:

    kubectl get pvc PVC_NAME -n PVC_NAMESPACE -o yaml

    Sostituisci quanto segue:

    • PVC_NAME: il nome di PersistentVolumeClaim.

    • PVC_NAMESPACE: lo spazio dei nomi di PersistentVolumeClaim.

    Il valore di PersistentVolumeClaim's status.phase è probabilmente Pending. Controlla la sezione Events per verificare la presenza dei seguenti errori:

    • Waiting for first consumer to be created before binding: indica che StorageClass ha volumeBindingMode: WaitForFirstConsumer.

      Il provisioning di PersistentVolume viene ritardato fino a quando non viene creato e pianificato un Pod che utilizza PersistentVolumeClaim. Il problema potrebbe riguardare la pianificazione di Pod, non il provisioning del volume stesso. Pertanto, ti consigliamo di verificare perché Pods che consumano PersistentVolumeClaim non vengono pianificati o non vengono avviati.

    • FailedProvisioning o errori del provisioner di archiviazione: ad esempio, pd.csi.storage.gke.io.

  7. Esamina gli eventi GKE negli spazi dei nomi pertinenti eseguendo il comando kubectl get events:

    kubectl get events -n PVC_NAMESPACE --sort-by='.lastTimestamp'

    Sostituisci PVC_NAMESPACE con lo spazio dei nomi di PersistentVolumeClaim.

    Cerca eventi correlati ai nomi PersistentVolumeClaim, ad esempio messaggi o errori di provisioning.

  8. Controlla i log di Cloud Audit Logs e di Persistent Disk in Cloud Logging.

  9. Monitora lo stato di tutti i VolumeRestores negli stati creating e restoring.

    Una volta risolto il problema, lo stato di VolumeRestores può passare allo stato succeeded o failed. Se VolumeRestores raggiunge lo stato succeeded, PersistentVolumeClaims deve diventare Bound e i carichi di lavoro devono essere funzionali. Se uno qualsiasi dei VolumeRestore entra in uno stato failed, devi eseguire i passaggi per la risoluzione dei problemi per risolvere l'errore di convalida del volume. Per saperne di più, vedi Errore 200060102: impossibile completare l'operazione di ripristino a causa di un errore di convalida del volume.

Se VolumeRestores rimangono negli stati creating o restoring per un periodo di tempo eccessivo, contatta l'assistenza clienti Google Cloud per ulteriore assistenza.

Passaggi successivi