Risolvi i problemi relativi agli errori dell'operazione di ripristino 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 che supporta il 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. I webhook di ammissione intercettano le richieste al server API GKE e la loro configurazione specifica in che modo il server API GKE deve eseguire query sulle richieste.

Il campo clientConfig del webhook specifica il backend che gestisce le richieste di ammissione, che può essere un servizio cluster interno o un URL esterno. La scelta tra queste due opzioni dipende dai requisiti operativi e architetturali specifici del 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. Questo accade durante le operazioni di ripristino in cui le configurazioni dei webhook con ambito cluster vengono applicate prima che i servizi con namespace siano completamente in uno 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 con errori menzionato nel messaggio di errore. Ad esempio, failed calling webhook "...".

  2. Esamina 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 i seguenti passaggi 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, possono essere ripristinati e 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 saperne di più 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 di servizi cloud che ospita il webhook, le policy 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 non è stato possibile creare una risorsa dal backup nel cluster di destinazione perché un webhook di controllo degli accessi attivo ha intercettato la richiesta e l'ha rifiutata in base a una policy personalizzata:

  [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. Esamina 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 di fondo 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 workload 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 dell'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 come 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 norme oppure una catena OwnerReference porta alla garbage collection o al processo di pulizia automatica di GKE che elimina le risorse dipendenti quando la risorsa owner viene eliminata.

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: esamina 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 in tutti gli 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. Esamina la causa dell'eliminazione utilizzando uno dei seguenti metodi:

    • Audit log di GKE: identifica 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 relativi 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, sospendere le automazioni in conflitto, correggere le configurazioni errate o modificare le autorizzazioni dell'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 garantisce di specificare lo spazio dei nomi corretto. Per saperne di più su come eseguire un'operazione di ripristino granulare, consulta 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ù carichi di lavoro 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 visualizzazione del seguente messaggio di errore:

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 preparazione 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 sono in stato ready nel messaggio di errore che elenca i workload e i relativi namespace che non sono entrati in 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 è in grado di 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 eventuali limitazioni o errori di scalabilità dei nodi. Risolvi i problemi sottostanti 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 policy di rete o la garanzia che le dipendenze siano soddisfatte.

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

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

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 creazione del Persistent Disk sottostante dallo snapshot non è riuscita. Gli errori di 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: il account di servizio utilizzato da Backup per GKE non dispone delle autorizzazioni necessarie per creare dischi o accedere agli snapshot.

  • Problemi di rete: si sono verificati problemi di rete temporanei o persistenti che interrompono il processo di creazione del disco.

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

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

  • Errori interni: si verificano 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. Controlla la sezione Events nell'output YAML per individuare messaggi relativi a errori di provisioning, come 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 compute service agentl'autorizzazione pertinente per accedere alla chiave, utilizza le istruzioni descritte nella documentazione di Backup per GKE sull'abilitazione della crittografia CMEK.

  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 provisioner 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 verificare la presenza di errori relativi alle operazioni di creazione del disco nel momento in cui si è verificato l'errore.

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

    • Aumenta le quote dei 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 in stato Pending.

    • La procedura di ripristino non riprova 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 associazione di PersistentVolumeClaim se il problema di fondo viene risolto. Per saperne di più 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 interrompe l'attesa perché almeno una risorsa VolumeRestore, che gestisce il ripristino dei dati da un VolumeBackup, non ha raggiunto uno stato succeeded entro il periodo di timeout assegnato. Anche altre risorse VolumeRestore potrebbero essere incomplete.

Il messaggio di errore nel campo stateReason della risorsa Restore mostra l'elenco delle risorse VolumeRestore rilevate che non si trovavano ancora in uno stato succeeded al momento del controllo del timeout. Include il nome e lo spazio dei nomi della destinazione PersistentVolumeClaim per queste risorse VolumeRestore, 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), ...]

Inoltre, se il ripristino di un volume non è riuscito, il messaggio di errore include questi errori, 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), ...] and 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), ...]

Backup per GKE avvia il provisioning delle risorse VolumeRestore PersistentVolumes da VolumeBackups. L'errore indica che la creazione del Persistent Disk sottostante dallo snapshot e la successiva associazione del PersistentVolumeClaim al PersistentVolume hanno richiesto più tempo del timeout calcolato per il VolumeRestores 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 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. Se sono presenti volumi in 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 alcuni volumi non sono stati caricati, vengono elencati nella seconda parte del messaggio di errore.

  5. Ottieni dettagli su VolumeRestore menzionato nell'errore e su qualsiasi altro VolumeRestores che non si trova nello stato succeeded eseguendo 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.

  6. Controlla i campi state e stateMessage. Il valore del campo state è probabilmente creating o restoring. Il campo stateMessage potrebbe fornire maggiori informazioni sul contesto e contenere i dettagli della destinazione PersistentVolumeClaim.

  7. Esamina lo stato della destinazione PersistentVolumeClaims identificata 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 alla creazione e alla pianificazione di un Pod che utilizza PersistentVolumeClaim. Il problema potrebbe riguardare la pianificazione di Pod, non il provisioning del volume stesso. Pertanto, ti consigliamo di verificare il motivo per cui i Pods che utilizzano i PersistentVolumeClaim non vengono pianificati o non vengono avviati.

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

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

  9. Controlla gli audit log di Cloud e i log di Persistent Disk in Cloud Logging.

  10. 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 i VolumeRestores raggiungono lo stato succeeded, i PersistentVolumeClaims devono diventare Bound e i carichi di lavoro devono essere funzionali. Se uno dei VolumeRestore entra nello 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