Risolvere i problemi relativi agli errori di archiviazione in Backup per GKE

Questa pagina descrive gli errori relativi allo spazio di archiviazione che potresti riscontrare quando utilizzi Backup per GKE, gli aspetti da considerare quando esegui l'azione e i passaggi per risolvere il problema.

Errore 100010105: Failed to backup PersistentVolumeClaim - Disk referenced by PersistentVolume does not exist

L'errore 100010105 si verifica quando un tentativo di eseguire il backup di un PersistentVolumeClaim non riesce perché fa riferimento a un disco inesistente, generando un errore che indica Failed to backup PersistentVolumeClaim - Disk referenced by PersistentVolume does not exist.

In Google Kubernetes Engine, PersistentVolumeClaims richiedono spazio di archiviazione da PersistentVolumes. Un PersistentVolume, a sua volta, rappresenta una parte di spazio di archiviazione, spesso un disco permanente di Compute Engine sottostante. Può verificarsi un errore quando un PersistentVolumeClaim è associato a un PersistentVolume e la configurazione di PersistentVolume' specifica un disco permanente di Compute Engine. Tuttavia, il disco effettivo con il nome e la località specificati nella configurazione PersistentVolume non è stato trovato nel tuo Cloud de Confiance by S3NS progetto. Di conseguenza, Backup per GKE non può procedere con il backup di un disco inesistente e si verifica un errore.

Per risolvere questo errore, segui queste istruzioni:

  1. Identifica il PersistentVolumeClaim e il PersistentVolume problematici. I nomi sia del PersistentVolumeClaim problematico sia del relativo PersistentVolume sono elencati nel campo state reason dell'operazione di Backup per GKE non riuscita non riuscita. Ti consigliamo di documentare sia il PersistentVolumeClaim nome, il relativo spazio dei nomi e il nome del PersistentVolume.

  2. Ispeziona il PersistentVolume. Per descrivere il PersistentVolume, utilizza il nome di PersistentVolume che hai identificato dal campo del motivo dello stato nel seguente comando:

    kubectl describe pv PERSISTENTVOLUME_NAME

    Sostituisci PERSISTENTVOLUME_NAME con il nome del tuo PersistentVolume.

  3. Nell'output, esamina la sezione source, in particolare sotto csi. Questa sezione descrive il VolumeHandle a cui PersistentVolume sta tentando di fare riferimento. Ad esempio:

    Source:
  Type: GCEPersistentDisk (a Persistent Disk resource in Google Compute Engine)
PDName: my-non-existent-disk
FSType: ext4
Partition: 0
ReadOnly: false
            In this example, the PD name is my-non-existent-disk.

    Source:
  Type:       CSI (a Container Storage Interface (CSI) volume)
  Driver:     pd.csi.storage.gke.io
  VolumeHandle: projects/PROJECT_ID/zones/ZONE/disks/DISK_NAME
...

    In questo esempio, VolumeHandle contiene il percorso completo del disco, inclusi il nome e la località. Ad esempio, projects/my-gcp-project/zones/us-central1-a/disks/my-disk-name.

  4. Utilizza VolumeHandle ottenuto dalla descrizione di PersistentVolume per identificare il nome e la zona del disco.

  5. Verifica che il disco esista nel tuo Cloud de Confiance by S3NS progetto utilizzando uno dei seguenti metodi:

    Disco a livello di zona

    Se utilizzi un disco a livello di zona, utilizza Google Cloud CLI per eseguire il comando gcloud compute disks describe:

    gcloud compute disks describe DISK_NAME \
    --zone=ZONE_NAME \
    --project=PROJECT_ID

    Sostituisci quanto segue:

    • DISK_NAME: il nome del disco che hai ottenuto dalla descrizione di PersistentVolume.

    • ZONE_NAME: la zona del disco che hai ottenuto dalla descrizione di PersistentVolume.

    • PROJECT_ID: l'ID del tuo Cloud de Confiance by S3NS progetto.

    Disco regionale

    Se utilizzi un disco regionale, utilizza Google Cloud CLI per eseguire il comando gcloud compute disks describe:

    gcloud compute disks describe DISK_NAME \
    --region=REGION_NAME \
    --project=PROJECT_ID

    Sostituisci quanto segue:

    • DISK_NAME: il nome del disco che hai ottenuto dalla descrizione di PersistentVolume.

    • REGION_NAME: la regione del disco che hai ottenuto dalla descrizione di PersistentVolume.

    • PROJECT_ID: l'ID del tuo Cloud de Confiance by S3NS progetto.

    Se ricevi un messaggio di errore Resource not found o The resource DISK_NAME was not found, il disco non esiste. Utilizza uno dei seguenti metodi per risolvere il problema a seconda dello scenario più adatto alle tue esigenze:

    • Se il disco è stato eliminato o rinominato per errore e vuoi conservare i dati o PersistentVolumeClaim, oppure se PersistentVolume è stato configurato con un nome disco errato, utilizza uno dei seguenti metodi per risolvere il problema:

      • Ripristina il disco: se hai un backup del disco, ripristinalo con lo stesso nome e la stessa località a cui fa riferimento PersistentVolume.

      • Crea un nuovo disco: se il ripristino del disco non è un'opzione, crea un nuovo disco con lo stesso nome e la stessa località presenti nella PersistentVolume configurazione.

    • Se PersistentVolumeClaim o PersistentVolume, i relativi dati o l' applicazione non sono più necessari, ti consigliamo di rimuovere l'entità non necessaria:

      • Elimina il PersistentVolumeClaim: elimina il PersistentVolumeClaim utilizzando lo strumento a riga di comando kubectl per eseguire il comando kubectl delete pvc:
      kubectl delete pvc PVC_NAME -n NAMESPACE

      Sostituisci quanto segue:

      • PVC_NAME: il nome di PersistentVolumeClaim che vuoi eliminare.

      • NAMESPACE: lo spazio dei nomi di PersistentVolumeClaim che vuoi eliminare.

    • Il PersistentVolume è ancora presente dopo l'eliminazione di PersistentVolumeClaim: se PersistentVolumeReclaimPolicy di PersistentVolume è impostato su Delete, il PersistentVolume viene eliminato automaticamente quando viene eliminato PersistentVolumeClaim. Se persistentVolumeReclaimPolicy è impostato su Retain, devi eliminare manualmente PersistentVolume dopo l'eliminazione di PersistentVolumeClaim. Per eliminare il PersistentVolume, utilizza lo strumento a riga di comando kubectl per eseguire il comando kubectl delete pv:

      kubectl delete pv PV_NAME

      Sostituisci PV_NAME con il nome di PersistentVolume che vuoi eliminare.

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

Errore 100010202: Snapshotting volume failed

L'errore 100010202 si verifica quando la creazione dello snapshot del disco permanente di Compute Engine non riesce, generando un messaggio di errore che indica Snapshotting volume failed.

Un'operazione di snapshot del disco permanente di Compute Engine non riesce se lo stato di collegamento del disco a un'istanza di macchina virtuale (VM) cambia durante il processo di creazione dello snapshot avviato dal servizio Backup per GKE. Gli scenari comuni che attivano questo problema includono i seguenti:

  • Riparazione automatica dei nodi: i nodi non integri vengono ricreati, causando la riprogrammazione dei pod e il distacco e il ricollegamento dei dischi.
  • Upgrade dei nodi: durante gli upgrade dei pool di nodi, i nodi vengono in genere svuotati e sostituiti. I pod vengono terminati normalmente e riprogrammati sui nuovi nodi, attivando cicli di distacco e ricollegamento dei dischi.
  • Scalabilità automatica del cluster: durante gli eventi di riduzione, se il gestore della scalabilità automatica del cluster rimuove un nodo, tutti i pod su quel nodo con dischi permanenti vengono eliminati, causando il distacco dei dischi. Se questi pod vengono riprogrammati altrove, i collegamenti si verificheranno sui nuovi nodi. Durante gli eventi di scalabilità orizzontale, i nuovi nodi non causano direttamente ricollegamenti, ma i pod pianificati su di essi attiveranno i collegamenti iniziali.

Si tratta di un errore temporaneo. In genere, il backup viene eseguito correttamente alla successiva esecuzione automatica una volta stabilizzato il collegamento del disco. Per evitare che gli eventi del cluster influiscano sui backup, applica i seguenti consigli:

  1. Attiva la pianificazione intelligente: configura il piano di backup utilizzando la pianificazione intelligente (una pianificazione basata sull'RPO). In questo modo, il sistema può riprovare automaticamente a eseguire i backup non riusciti temporaneamente entro la finestra di tempo specificata senza influire sull'RPO complessivo del piano di backup.

  2. Configura le finestre di esclusione dei backup: se esegui operazioni di upgrade pool di nodi o di ridimensionamento del cluster, aggiungi una finestra di esclusione dei backup alle impostazioni di backup durante questi intervalli. In questo modo, il servizio Backup per GKE metterà in pausa ed eviterà di pianificare gli snapshot mentre il cluster sta modificando attivamente i collegamenti dei dischi.

  3. Riprova a eseguire i backup manuali: nel caso di backup manuali o on demand, riprova a eseguire l'operazione di backup al termine dell'evento del cluster.

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

Passaggi successivi