Questa pagina descrive come utilizzare bmctl
per eseguire il backup e il ripristino dei cluster creati con Google Distributed Cloud (solo software) su bare metal. Queste istruzioni si applicano a tutti i tipi di cluster.
La procedura di backup e ripristino di bmctl
non include i volumi permanenti. Tutti i volumi creati dal provisioner del volume locale (LVP) rimangono invariati.
Eseguire il backup di un cluster
Il comando bmctl backup cluster
aggiunge le informazioni del cluster dall'armadietto etcd e i certificati PKI per il cluster specificato al file tar. Lo spazio di archiviazione etcd è lo spazio di archiviazione di supporto di Kubernetes per tutti i dati del cluster e contiene tutti gli oggetti Kubernetes e personalizzati necessari per gestire lo stato del cluster. I certificati PKI vengono utilizzati per l'autenticazione tramite TLS. Il backup di questi dati viene eseguito dal control plane del cluster o da uno dei control plane 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 un luogo sicuro. Per evitare l'esposizione indesiderata dei file, la procedura di backup di Google Distributed Cloud utilizza solo file in memoria.
Esegui regolarmente il backup dei cluster per assicurarti che i dati degli snapshot siano relativamente aggiornati. Modifica la frequenza dei backup in base alla frequenza delle modifiche significative ai tuoi cluster.
La versione di bmctl
utilizzata per eseguire il backup di un cluster deve corrispondere a quella del
cluster di gestione.
Per eseguire il backup di un cluster:
Assicurati che il cluster funzioni correttamente, con credenziali e connettività SSH funzionanti per tutti i nodi.
Lo scopo della procedura di backup è acquisire il cluster in uno stato di funzionamento noto, in modo da poter ripristinare il funzionamento in caso di guasto catastrofico.
Utilizza il seguente comando per controllare il cluster:
bmctl check cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
Sostituisci quanto segue:
CLUSTER_NAME
: il nome del cluster di cui vuoi eseguire il backup.ADMIN_KUBECONFIG
: il percorso del file kubeconfig per il cluster di amministrazione.
Esegui il seguente comando per assicurarti che il cluster di destinazione non sia in stato di riconciliazione:
kubectl describe cluster CLUSTER_NAME -n CLUSTER_NAMESPACE --kubeconfig ADMIN_KUBECONFIG
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 Google Distributed Cloud sono il nome del cluster preceduto dacluster-
. Ad esempio, se assegni al cluster il nometest
, lo spazio dei nomi avrà un nome simile acluster-test
.ADMIN_KUBECONFIG
: il percorso del file kubeconfig per il cluster di amministrazione.
Controlla la sezione
Status
nell'output del comando perConditions
di tipoReconciling
.Come mostrato nell'esempio seguente, uno stato
False
per questiConditions
indica 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 il seguente comando per eseguire il backup del cluster:
bmctl backup cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
Sostituisci quanto segue:
CLUSTER_NAME
: il nome del cluster di cui eseguire il backup.ADMIN_KUBECONFIG
: il percorso del file kubeconfig del cluster di amministrazione.
Per impostazione predefinita, il file tar di backup viene salvato nella directory dello spazio di lavoro (
bmctl-workspace
per impostazione predefinita) sulla workstation di amministrazione. Il file tar si chiamaCLUSTER_NAME_backup_TIMESTAMP.tar.gz
, doveCLUSTER_NAME
è il nome del cluster di cui viene eseguito il backup eTIMESTAMP
è 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 atestuser_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.
Ripristinare un cluster
Il ripristino di un cluster da un backup è l'ultima risorsa e deve essere utilizzato quando un cluster ha subito un errore catastrofico e non può essere rimesso in servizio in nessun altro modo. Ad esempio, i dati etcd sono danneggiati o il pod etcd
è in 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 evitare l'esposizione involontaria dei file, la procedura di ripristino di Google Distributed Cloud utilizza solo file in memoria.
La versione di bmctl
utilizzata per ripristinare un cluster deve corrispondere a quella del
cluster di gestione.
Per ripristinare un cluster:
Assicurati che tutte le macchine dei nodi disponibili per il cluster al momento del backup funzionino correttamente e siano raggiungibili.
Assicurati che la connettività SSH tra i nodi funzioni con le chiavi SSH utilizzate al momento del backup.
Queste chiavi SSH vengono reintegrate durante il 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 di amministrazione, ibrida o autonomo, esegui il seguente 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 che stai utilizzando.
Per ripristinare un cluster di utenti, esegui il seguente comando:
bmctl restore cluster -c CLUSTER_NAME --backup-file BACKUP_FILE \ --kubeconfig ADMIN_KUBECONFIG
Sostituisci quanto segue:
CLUSTER_NAME
: il nome del cluster che stai ripristinando.BACKUP_FILE
: il percorso e il nome del file di backup che stai utilizzando.ADMIN_KUBECONFIG
: 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.
Risoluzione dei problemi
Se riscontri problemi con la procedura di backup o ripristino, le sezioni riportate di seguito potrebbero aiutarti a risolverli.
Se hai bisogno di ulteriore assistenza, contatta l'Assistenza Google.
Memoria insufficiente durante un backup o un ripristino
Durante il processo di backup o ripristino potresti ricevere messaggi di errore che non sono molto autoesplicativi o chiari sui passaggi successivi. Se la workstation su cui esegui il comando bmctl
non ha molta RAM, potresti avere memoria insufficiente per eseguire il processo di backup o ripristino.
Google Distributed Cloud versione 1.13 e successive può utilizzare il parametro --use-disk
nel
comando di backup. Per preservare le autorizzazioni dei file, questo parametro modifica le autorizzazioni dei file, pertanto richiede che l'utente che esegue il comando sia un utente root (o utilizzi sudo
).
Autorizzazioni mancanti per i file durante il ripristino
Dopo un'attività di ripristino riuscita, l'eliminazione del bootstrap può non riuscire con un messaggio di errore simile al seguente esempio:
Error: failed to restore node config files: sftp: "Failure" (SSH_FX_FAILURE)
Questo errore potrebbe indicare che alcune directory richieste dal ripristino non sono scrivibili.
Google Distributed Cloud versione 1.14 e successive hanno messaggi di errore più chiari sulle directory che devono essere scrivibili. Assicurati che le directory segnalate siano scrivibili e aggiorna le autorizzazioni nelle directory in base alle necessità.
L'aggiornamento della chiave SSH dopo un backup interrompe il processo di ripristino
Le operazioni relative a SSH durante la procedura di ripristino potrebbero non riuscire se la chiave SSH viene aggiornata dopo l'esecuzione del backup. In questo caso, la nuova chiave SSH diventa invalida per la procedura di ripristino.
Per risolvere il problema, puoi aggiungere di nuovo temporaneamente la chiave SSH originale, quindi eseguire il ripristino. Al termine del processo di ripristino, puoi ruotare la chiave SSH.