Attivare la modalità permissiva in un piano di backup

Questa pagina spiega come attivare la modalità permissiva su un piano di backup.

Durante l'esecuzione del backup, se Backup per GKE rileva condizioni che potrebbero causare il fallimento del ripristino, il backup stesso non va a buon fine. Il motivo dell'errore è fornito nel campo state_reason del backup. Nella console Google Cloud, questo campo è denominato Motivo dello stato.

Se attivi la modalità permissiva, la descrizione del problema viene comunque fornita nel campo Motivo stato, ma il backup non avrà esito negativo. Puoi attivare questo comportamento se conosci il problema e sei pronto a utilizzare una soluzione alternativa al momento del ripristino.

Di seguito è riportato un esempio di messaggio di errore che potresti visualizzare nel campo Motivo stato del backup che suggerisce di attivare la modalità permissiva: If you cannot implement the recommended fix, you may create a new backup with Permissive Mode enabled.

gcloud

Attiva la modalità permissiva:

gcloud beta container backup-restore backup-plans update BACKUP_PLAN \
    --project=PROJECT_ID \
    --location=LOCATION
    --permissive-mode

Sostituisci quanto segue:

Console

Segui le istruzioni riportate di seguito per attivare la modalità permissiva nella console Google Cloud:

  1. Nella console Google Cloud, vai alla pagina Google Kubernetes Engine.

    Vai a Google Kubernetes Engine

  2. Nel menu di navigazione, fai clic su Backup per GKE.

  3. Fai clic sulla scheda Piani di backup.

  4. Espandi il cluster e fai clic sul nome del piano.

  5. Fai clic sulla scheda Dettagli per modificare i dettagli del piano.

  6. Fai clic su Modifica per modificare la sezione con la modalità di backup.

  7. Fai clic sulla casella di controllo Modalità permissiva e poi su Salva modifiche.

Terraform

Aggiorna la risorsa google_gke_backup_backup_plan esistente.

resource "google_gke_backup_backup_plan" "NAME" {
   ...
   backup_config {
     permissive_mode = true
     ...
   }
}

Sostituisci quanto segue:

  • NAME: il nome del google_gke_backup_backup_plan da aggiornare.

Per ulteriori informazioni, consulta gke_backup_backup_plan.

Risolvere i problemi di backup

La tabella seguente fornisce spiegazioni e azioni consigliate per vari messaggi di errore del backup visualizzati nel campo Motivo stato del backup.

Messaggio di errore del backup Descrizione del messaggio e motivo dell'errore Azione consigliata

CustomResourceDefinitions "..." have invalid schemas

Descrizione: una definizione di risorsa personalizzata (CRD) nel cluster è stata originariamente applicata come apiextensions.k8s.io/v1beta1 e manca uno schema strutturale richiesto in apiextensions.k8s.io/v1.

Motivo: Backup per GKE non può definire automaticamente lo schema strutturale. Il ripristino della CRD nei cluster Kubernetes 1.22 e versioni successive, dove apiextensions.k8s.io/v1beta1 non è disponibile, causa il fallimento del ripristino. Questo errore si verifica durante il ripristino delle risorse personalizzate definite dal file CRD. 		Ti consigliamo di utilizzare le seguenti opzioni:
  • Se si tratta di un CRD gestito da GKE, puoi chiamare kubectl delete crd se non sono presenti risorse esistenti gestite dal CRD. Se esistono risorse già pubblicate dal CRD, puoi attivare la modalità permissiva conoscendo il comportamento di ripristino. Per consigli sui CRD comuni, consulta la documentazione.
  • Se si tratta di un CRD di terze parti, consulta la documentazione pertinente per eseguire la migrazione a apiextensions.k8s.io/v1.

Quando la modalità permissiva è attivata, il CRD senza uno schema strutturale non verrà sottoposto a backup in un cluster Kubernetes versione 1.22 e successive. Per eseguire correttamente il ripristino di un backup di questo tipo, devi escludere le risorse servite dal CRD dal ripristino o creare il CRD nel cluster di destinazione prima di avviare il ripristino.

PersistentVolumeClaims "..." are bound to PersistentVolumes of unsupported types "..." and cannot be backed up

Descrizione: nel cluster di origine, un PVC è associato a un PV che non è un volume di Persistent Disk.

Motivo: Backup per GKE supporta solo il backup dei dati dei volumi dei Persistent Disk. I PVC di dischi non permanenti ripristinati utilizzando la policy Esegui il provisioning di nuovi volumi e ripristina i dati di volume dal backup non avranno alcun dato di volume ripristinato. Tuttavia, il criterio Riutilizza i volumi esistenti contenenti i tuoi dati consente di ricollegare i PVC all'handle del volume originale. Questo è utile per i tipi di volumi basati su un server esterno, come NFS. 		Attiva la modalità permissiva dopo aver compreso le opzioni di ripristino disponibili per i volumi non Persistent Disk nel cluster di origine. Per eseguire il backup dei volumi Filestore, consulta Gestire i volumi Filestore con Backup per GKE.

Quando la modalità permissiva è attiva, viene eseguito il backup della configurazione del PVC, ma non dei dati del volume.

PersistentVolumeClaims "..." are not bound to PersistentVolumes and cannot be backed up

Descrizione: un PVC nel cluster non è associato a un PV.

Motivo: Backup per GKE può eseguire il backup del PVC, ma non ci sono dati del volume di cui eseguire il backup. Questa situazione potrebbe indicare una configurazione errata o una mancata corrispondenza tra lo spazio di archiviazione richiesto e quello disponibile. 		Controlla che il PVC sfuso sia in condizioni accettabili. In caso contrario, attiva la modalità permissiva. Tieni presente le implicazioni per il comportamento del backup.

Quando la modalità permissiva è attiva, viene eseguito il backup della configurazione del PVC, ma non esistono dati di volume di cui eseguire il backup.

Failed to query API resources ...

Descrizione: un servizio API nel cluster non è configurato correttamente. Di conseguenza, le richieste al percorso dell'API restituiscono il messaggio "Impossibile eseguire query sulle risorse dell'API". Il servizio sottostante potrebbe non esistere o non essere ancora pronto.

Motivo: Backup per GKE non è in grado di eseguire il backup di alcuna risorsa pubblicata dall'API non disponibile. 		Controlla il servizio sottostante nel spec.service del servizio API per assicurarti che sia pronto.

Quando la modalità permissiva è attiva, il backup delle risorse dei gruppi di API che non è stato caricato non verrà eseguito.

Secret ... is an auto-generated token from ServiceAccount ... referenced in Pod specs

Descrizione: in Kubernetes 1.23 e versioni precedenti, gli account di servizio generano automaticamente un token basato su un segreto. Tuttavia, nelle versioni successive, Kubernetes ha rimosso questa funzionalità di token generato automaticamente. Un pod nel cluster potrebbe aver montato il volume del secret nel file system dei suoi container.

Motivo: se Backup per GKE tenta di ripristinare un account di servizio insieme al relativo secret generato automaticamente e un pod che monta il volume del secret, il ripristino sembra essere riuscito. Tuttavia, Kubernetes rimuove il secret, causando il blocco del pod durante la creazione del container e l'impossibilità di avviarlo. 		Definisci il campo spec.serviceAccountName nel pod. Questa azione garantisce che il token venga montato automaticamente su /var/run/secrets/kubernetes.io/serviceaccount nei contenitori. Per ulteriori informazioni, consulta la documentazione su come configurare gli account di servizio per i pod.

Quando la modalità permissiva è attiva, viene eseguito il backup del secret, ma non può essere montato nei pod nei cluster Kubernetes 1.24 e versioni successive.

CRD comuni con problemi e azioni consigliate

Di seguito sono riportati alcuni CRD comuni che presentano problemi di backup e le azioni consigliate per risolverli:

  • capacityrequests.internal.autoscaling.k8s.io: questo CRD è stato utilizzato temporaneamente nei cluster della versione 1.21. Esegui kubectl delete crd capacityrequests.internal.autoscaling.k8s.io per rimuovere il CRD.
  • scalingpolicies.scalingpolicy.kope.io: questo CRD veniva utilizzato per controllare le risorse fluentd, ma GKE ha eseguito la migrazione all'utilizzo di fluentbit. Esegui kubectl delete crd scalingpolicies.scalingpolicy.kope.io per rimuovere il CRD.
  • memberships.hub.gke.io: Esegui kubectl delete crd memberships.hub.gke.io per rimuovere il CRD se non sono presenti risorse di adesione. Attiva la modalità permissiva se sono presenti risorse per gli abbonati.
  • applications.app.k8s.io: attiva la modalità permissiva con una comprensione del comportamento di ripristino.