Questa pagina è stata tradotta dall'API Cloud Translation.

Attivare la modalità permissiva in un piano di backup

Autopilota Standard

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

Durante l'esecuzione del backup, se Backup per GKE rileva condizioni probabili per impedire la riuscita del ripristino, il backup non va a buon fine. Il motivo dell'errore viene fornito nel set di dati state_reason . 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 dello stato, ma il backup non avrà esito negativo. Puoi attivare questa funzionalità comportamento del cliente se si è a conoscenza del problema e si è pronti a impiegare una soluzione alternativa al momento del ripristino.

Di seguito è riportato un esempio di messaggio di errore che potresti visualizzare nella Il campo Motivo dello stato del backup che suggerisce l'abilitazione della modalità permissiva: If you cannot implement the recommended fix, you may create a new backup with Permissive Mode enabled.

gcloud

Abilita la modalità permissiva:

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

Sostituisci quanto segue:

BACKUP_PLAN: il nome del piano di backup che vuoi aggiornare.
PROJECT_ID: l'ID del tuo account Google Cloud progetto.
LOCATION: il regione di computing per la risorsa, ad esempio us-central1. Consulta Informazioni sulle località delle risorse.

Per un elenco completo delle opzioni, consulta la documentazione di gcloud beta container backup-restore backup-plans update.

Console

Segui le istruzioni riportate di seguito per abilitare la modalità permissiva nel Console Google Cloud:

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

Vai a Google Kubernetes Engine
Nel menu di navigazione, fai clic su Backup per GKE.
Fai clic sulla scheda Piani di backup.
Espandi il cluster e fai clic sul nome del piano.
Fai clic sulla scheda Dettagli per modificare i dettagli del piano.
Fai clic su Modifica per modificare la sezione con Modalità di backup.
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, vedi 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 backup non riuscito	Descrizione del messaggio e motivo dell'errore	Azione consigliata
`CustomResourceDefinitions "..." have invalid schemas`	Descrizione: una definizione di risorsa personalizzata (CRD) in il cluster era stato applicato inizialmente `apiextensions.k8s.io/v1beta1` e non ha uno schema strutturale obbligatorio in `apiextensions.k8s.io/v1`. Motivo: Backup for GKE non può definire automaticamente lo schema strutturale. Ripristino della CRD nei cluster Kubernetes v1.22 e versioni successive. dove `apiextensions.k8s.io/v1beta1` non è disponibile, causa il ripristino non vada a buon fine. Questo errore si verifica durante il ripristino delle risorse personalizzate definite dal file CRD.	Ti consigliamo di utilizzare le seguenti opzioni: Se gestisci la CRD, segui i passaggi documentazione di Kubernetes per specificare uno schema strutturale per la tua CRD. Se è un CRD gestito da GKE, puoi chiamare `kubectl delete crd` se non ci sono risorse esistenti gestite da quest'ultima. Se esistono risorse già gestite da CRD, puoi abilitare modalità permissiva con una comprensione del comportamento di ripristino. Per consigli sui CRD più comuni, consulta 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 è abilitata, il CRD senza uno schema strutturale non verrà eseguito il backup in un cluster Kubernetes v1.22 o versioni successive. A ripristinare un backup di questo tipo, devi escludere le risorse gestite CRD dal ripristino o dalla creazione del CRD nel cluster di destinazione prima di iniziare per eseguire 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 disco permanente. Motivo: Backup per GKE supporta solo il backup dei dati dei volumi dei dischi permanenti. I PVC di dischi non permanenti ripristinati utilizzando il criterio Esegui il provisioning di nuovi volumi e ripristina i dati di volume dal backup non avranno dati di volume ripristinati. 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 supportati da un server esterno, come NFS.	Abilita la modalità permissiva con una comprensione del ripristino disponibile per i volumi non permanenti nel cluster di origine. Per per il backup di volumi Filestore, Gestisci 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: una PVC nel cluster non è associata a un PV. Motivo: Backup per GKE può eseguire il backup della PVC, ma ci sono dati di volume di cui eseguire il backup. Questa situazione potrebbe indicare che o una mancata corrispondenza tra lo spazio di archiviazione richiesto e quello disponibile.	Controlla se il PVC sfuso è 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 PVC, ma non c'è alcun volume di dati di cui effettuare 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 v1.23 e versioni precedenti, il servizio generano automaticamente un token supportato da un secret. 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 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. Se la modalità permissiva è abilitata, viene eseguito il backup del secret, ma non è possibile montare nei pod nei cluster Kubernetes v1.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 rimuovi il CRD.
scalingpolicies.scalingpolicy.kope.io: Questo CRD è stato utilizzato per controllare le risorse fluenti, ma GKE ha eseguito la migrazione all'utilizzo 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 la CRD se sono presenti nessuna risorsa di appartenenza. Abilita la modalità permissiva in caso di membri Google Cloud.
applications.app.k8s.io: attiva la modalità permissiva con una comprensione del comportamento di ripristino.