Backup e ripristino di cluster con bmctl

In questa pagina viene descritto come utilizzare bmctl per eseguire il backup e il ripristino dei cluster creati con GDCV per Bare Metal. Queste istruzioni si applicano a tutti i tipi di cluster supportati da GKE su Bare Metal.

Il processo di backup e ripristino di bmctl non include volumi permanenti. I volumi creati dal provisioner del volume locale (LVP) non vengono modificati.

Esegui il backup di un cluster

Il comando bmctl backup cluster aggiunge le informazioni sul cluster dall'archivio etcd e i certificati PKI per il cluster specificato il cluster a un file tar. L'archivio etcd è l'archivio di supporto Kubernetes per tutti i dati del cluster e contiene tutti gli oggetti Kubernetes e gli oggetti personalizzati necessari per gestire lo stato del cluster. I certificati PKI vengono utilizzati per l'autenticazione su TLS. Questi dati vengono sottoposti a backup dal piano di controllo del cluster o da uno dei piani di controllo per un deployment ad alta disponibilità (HA).

Il file tar di backup contiene credenziali sensibili, tra cui le chiavi dell'account di servizio e la chiave SSH. Archivia i file di backup in una posizione sicura. Per evitare l'esposizione involontaria dei file, il processo di backup di GKE su Bare Metal utilizza solo file in memoria.

Esegui regolarmente il backup dei cluster per assicurarti che i dati degli snapshot siano relativamente attuali. Modifica la frequenza dei backup in modo da riflettere la frequenza di modifiche significative ai cluster.

La versione di bmctl che utilizzi per il backup di un cluster deve corrispondere alla versione del cluster di gestione.

Per eseguire il backup di un cluster:

Assicurati che il cluster funzioni correttamente, con credenziali funzionanti e connettività SSH a tutti i nodi.

Lo scopo del processo di backup è acquisire il cluster in uno stato buono noto, per consentirti di ripristinare l'operazione in caso di errore catastrofico.

Utilizza questo comando per verificare il cluster:
```
bmctl check cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBEONFIG
```
Sostituisci quanto segue:
- CLUSTER_NAME: il nome del cluster di cui prevedi di eseguire il backup.
- ADMIN_KUBEONFIG: il percorso del file kubeconfig per il cluster di amministrazione.
Esegui questo comando per assicurarti che il cluster di destinazione non sia in stato di riconciliazione:
```
kubectl describe cluster CLUSTER_NAME -n CLUSTER_NAMESPACE --kubeconfig ADMIN_KUBEONFIG
```
Sostituisci quanto segue:
- CLUSTER_NAME: il nome del cluster di cui eseguire il backup.
- CLUSTER_NAMESPACE: lo spazio dei nomi per il cluster. Per impostazione predefinita, gli spazi dei nomi del cluster per GKE su Bare Metal sono il nome del cluster preceduto da cluster-. Ad esempio, se il nome del cluster è test, lo spazio dei nomi avrà un nome simile a cluster-test.
- ADMIN_KUBEONFIG: il percorso del file kubeconfig per il cluster di amministrazione.

Controlla la sezione Status nell'output comando per Conditions di tipo Reconciling.

Come mostrato nell'esempio seguente, lo stato False di questi Conditions significa che il cluster è stabile e pronto per il backup.

...
Status:
  ...
  Cluster State:  Running
  ...
  Control Plane Node Pool Status:
    ...
    Conditions:
      Last Transition Time:  2023-11-03T16:37:15Z
      Observed Generation:   1
      Reason:                ReconciliationCompleted
      Status:                False
      Type:                  Reconciling
  ...

Esegui questo comando per eseguire il backup del cluster:
```
bmctl backup cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBEONFIG
```
Sostituisci quanto segue:
- CLUSTER_NAME: il nome del cluster di cui eseguire il backup.
- ADMIN_KUBEONFIG: il percorso del file kubeconfig del cluster di amministrazione.
Per impostazione predefinita, il file tar di backup è stato salvato nella directory dell'area di lavoro (bmctl-workspace, per impostazione predefinita) sulla workstation di amministrazione. Il file tar è denominato CLUSTER_NAME_backup_TIMESTAMP.tar.gz, dove CLUSTER_NAME è il nome del cluster di cui viene eseguito il backup e TIMESTAMP è la data e l'ora in cui è stato eseguito il backup. Ad esempio, se il nome del cluster è testuser, il file di backup ha un nome simile a testuser_backup_2006-01-02T150405Z0700.tar.gz.

Per specificare un nome e una posizione diversi per il file di backup, utilizza il flag --backup-file.

Il file di backup scade dopo un anno e il processo di ripristino del cluster non funziona con i file di backup scaduti.

Ripristina un cluster

Il ripristino di un cluster da un backup è l'ultima risorsa e deve essere utilizzato quando un cluster ha avuto un errore catastrofico e non può essere restituito al servizio in nessun altro modo. Ad esempio, i dati etcd sono danneggiati o il pod etcd ha un loop di arresto anomalo.

Il file tar di backup contiene credenziali sensibili, tra cui le chiavi dell'account di servizio e la chiave SSH. Per impedire l'esposizione involontaria dei file, il processo di ripristino di GKE su Bare Metal utilizza solo file in memoria.

La versione di bmctl che utilizzi per ripristinare un cluster deve corrispondere alla versione del cluster in gestione.

Per ripristinare un cluster:

Assicurati che tutte le macchine nodo che erano disponibili per il cluster al momento del backup funzionino correttamente e siano raggiungibili.
Assicurati che la connettività SSH tra nodi funzioni con le chiavi SSH utilizzate al momento del backup.

Queste chiavi SSH vengono reintegrate nell'ambito del processo di ripristino.
Assicurati che le chiavi dell'account di servizio utilizzate al momento del backup siano ancora attive.

Queste chiavi dell'account di servizio vengono reintegrate per il cluster ripristinato.
Per ripristinare un cluster amministratore, ibrido o autonomo, esegui questo comando:
```
bmctl restore cluster -c CLUSTER_NAME --backup-file BACKUP_FILE
```
Sostituisci quanto segue:
- CLUSTER_NAME: il nome del cluster che stai ripristinando.
- BACKUP_FILE: il percorso e il nome del file di backup in uso.
Per ripristinare un cluster utente, esegui questo comando:
```
bmctl restore cluster -c CLUSTER_NAME --backup-file BACKUP_FILE \
    --kubeconfig ADMIN_KUBEONFIG
```
Sostituisci quanto segue:
- CLUSTER_NAME: il nome del cluster che stai ripristinando.
- BACKUP_FILE: il percorso e il nome del file di backup in uso.
- ADMIN_KUBEONFIG: il percorso del file kubeconfig del cluster di amministrazione.

Al termine del processo di ripristino, viene generato un nuovo file kubeconfig per il cluster ripristinato.

Risolvere i problemi

In caso di problemi con la procedura di backup o ripristino, le sezioni seguenti potrebbero aiutarti a risolverli.

Se hai bisogno di ulteriore aiuto, contatta l'Assistenza Google.

Esaurimento della memoria durante un backup o un ripristino

Durante il processo di backup o ripristino, potresti ricevere messaggi di errore poco chiari o chiari nei passaggi successivi. Se la workstation in cui esegui l'esecuzione del comando bmctl non dispone di molta RAM, la memoria potrebbe essere insufficiente per eseguire il processo di backup o ripristino.

GDCV per Bare Metal versione 1.13 e successive può utilizzare il parametro --use-disk nel comando di backup. Per mantenere le autorizzazioni dei file, questo parametro modifica le autorizzazioni dei file, pertanto richiede che l'utente che esegue il comando sia un utente root (oppure utilizzare sudo).

Autorizzazioni mancanti per i file durante il ripristino

Dopo un'attività di ripristino riuscita, l'eliminazione del bootstrap può non riuscire e viene visualizzato un messaggio di errore simile al seguente esempio:

Error: failed to restore node config files: sftp: "Failure" (SSH_FX_FAILURE)

Questo errore potrebbe significare che alcune directory richieste dal ripristino non sono scrivibili.

GDCV per Bare Metal versione 1.14 e successive mostra messaggi di errore più chiari in cui le directory devono essere scrivibili. Assicurati che le directory segnalate siano scrivibili e aggiorna le autorizzazioni sulle directory, se necessario.

L'aggiornamento della chiave SSH dopo un backup interrompe il processo di ripristino

Le operazioni relative a SSH durante il processo di ripristino potrebbero non riuscire se la chiave SSH viene aggiornata dopo l'esecuzione del backup. In questo caso, la nuova chiave SSH non è più valida per il processo di ripristino.

Per risolvere il problema, puoi aggiungere temporaneamente la chiave SSH originale ed eseguire il ripristino. Al termine del processo di ripristino, puoi ruotare la chiave SSH.