In questa pagina viene descritto come utilizzare bmctl
per eseguire il backup e il ripristino dei cluster creati
con Google Distributed Cloud. Queste istruzioni si applicano a tutti i tipi di cluster supportati
di Google Distributed Cloud.
Il processo di backup e ripristino di bmctl
non include
come i bilanciatori del carico
e i volumi di archiviazione. Tutti i volumi creati dal provisioner del volume locale (LVP) vengono lasciati
inalterato.
Esegui il backup di un cluster
Il comando bmctl backup cluster
aggiunge le informazioni sul cluster dal file etcd
e i certificati PKI per il cluster specificato, il cluster in un tar
. L'archivio etcd è il datastore di supporto Kubernetes per tutti i dati del cluster e
contiene tutti gli oggetti Kubernetes e gli oggetti personalizzati necessari per gestire
nello stato del cluster. I certificati PKI vengono utilizzati per l'autenticazione su TLS. Questo
viene fatto il backup dei dati dal piano di controllo del cluster o da uno dei
aerei per un
alta disponibilità (HA)
e deployment continuo.
Il file tar di backup contiene credenziali sensibili, incluso il tuo servizio e la chiave SSH. Archivia i file di backup in un luogo sicuro. A prevenire l'esposizione involontaria dei file, il processo 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 corrente. Regola la frequenza dei backup in modo che rifletta la frequenza dei modifiche ai cluster.
La versione di bmctl
che utilizzi per il backup di un cluster deve corrispondere alla versione di
il cluster di gestione.
Per eseguire il backup di un cluster:
Assicurati che il cluster funzioni correttamente, con credenziali funzionanti e SSH e la connettività a tutti i nodi.
Lo scopo del processo di backup è acquisire il cluster in un ambiente noto in modo da poter ripristinare l'operazione in caso di errore catastrofico.
Utilizza questo comando per controllare il cluster:
bmctl check cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
Sostituisci quanto segue:
CLUSTER_NAME
: il nome del cluster che prevedi di usare fare il backup.ADMIN_KUBECONFIG
: il percorso del file kubeconfig per il cluster di amministrazione.
Esegui questo comando per assicurarti che il cluster di destinazione non sia in uno 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 in un cluster Kubernetes. Per impostazione predefinita, gli spazi dei nomi del cluster per Google Distributed Cloud è il nome del cluster preceduto dacluster-
. Ad esempio, se assegni al cluster il nometest
, lo spazio dei nomi ha un nome similecluster-test
.ADMIN_KUBECONFIG
: il percorso del file kubeconfig per il cluster di amministrazione.
Controlla la sezione
Status
nell'output comando per verificareConditions
di tipoReconciling
.Come mostrato nell'esempio seguente, per queste richieste uno stato
False
Conditions
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 questo 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 cluster di amministrazione kubeconfig.
Per impostazione predefinita, il file tar di backup viene salvato nella directory di Workspace (
bmctl-workspace
per impostazione predefinita) sulla workstation di amministrazione. Il file tar è denominatoCLUSTER_NAME_backup_TIMESTAMP.tar.gz
, doveCLUSTER_NAME
è il nome del cluster backup eseguito eTIMESTAMP
è la data e l'ora in cui è stato eseguito. 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 la
--backup-file
flag.
Il file di backup scade dopo un anno e il processo di ripristino del cluster lavorare con file di backup scaduti.
Ripristina un cluster
Il ripristino di un cluster da un backup è l'ultima risorsa e dovrebbe essere utilizzato quando
un cluster ha avuto un errore catastrofico e non può essere restituito al servizio di altri
in molti modi diversi. Ad esempio, i dati etcd sono danneggiati o il pod etcd
ha avuto un arresto anomalo
ciclo.
Il file tar di backup contiene credenziali sensibili, incluso il tuo servizio e la chiave SSH. Per evitare un'esposizione accidentale dei file, Il processo di ripristino di Google Distributed Cloud utilizza solo file in memoria.
La versione bmctl
che utilizzi per ripristinare un cluster deve corrispondere alla versione di
il cluster di gestione.
Per ripristinare un cluster:
Assicurati che tutte le macchine nodo che erano disponibili per il cluster al momento della il backup funzioni correttamente e sia raggiungibile.
Assicurati che la connettività SSH tra nodi funzioni con le chiavi SSH che erano utilizzata al momento del backup.
Queste chiavi SSH vengono reintegrate nell'ambito del processo di ripristino.
Assicurati che le chiavi dell'account di servizio siano state utilizzate al momento dell'esecuzione di backup sono ancora attivi.
Queste chiavi dell'account di servizio vengono reintegrate per il cluster ripristinato.
Per ripristinare un cluster di amministrazione, ibrido o autonomo, esegui questo :
bmctl restore cluster -c CLUSTER_NAME --backup-file BACKUP_FILE
Sostituisci quanto segue:
CLUSTER_NAME
: il nome del cluster che stai il ripristino.BACKUP_FILE
: il percorso e il nome del file di backup che che utilizzano.
Per ripristinare un cluster utente, esegui questo 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 il ripristino.BACKUP_FILE
: il percorso e il nome del file di backup che che utilizzano.ADMIN_KUBECONFIG
: il percorso del cluster di amministrazione kubeconfig.
Al termine del processo di ripristino, viene generato un nuovo file kubeconfig per il cluster ripristinato.
Risoluzione dei problemi
Se hai problemi con il processo di backup o ripristino, consulta le sezioni seguenti potrebbe aiutarti a risolvere il problema.
Se hai bisogno di ulteriore assistenza, contatta 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 esplicative o sono chiare sui passaggi successivi. Se la workstation in cui
quando esegui il comando bmctl
non ha molta RAM, potresti
memoria insufficiente per eseguire il processo di backup o ripristino.
Google Distributed Cloud 1.13 e versioni successive possono utilizzare il parametro --use-disk
in
il comando di backup. Per conservare le autorizzazioni del file, questo parametro modifica
le autorizzazioni dei file, quindi l'utente che esegue il comando deve essere
utente root (o utilizza sudo
).
Autorizzazioni mancanti per i file durante il ripristino
Dopo un'attività di ripristino riuscita, l'eliminazione del bootstrap può non riuscire e generando un errore simile all'esempio seguente:
Error: failed to restore node config files: sftp: "Failure" (SSH_FX_FAILURE)
Questo errore potrebbe significare che alcune directory richieste dal ripristino non sono in scrittura.
Google Distributed Cloud versione 1.14 e successive presentano messaggi di errore più chiari sui quali devono essere scrivibili. Assicurati che le directory segnalate siano scrivibili e aggiorna le autorizzazioni sulle directory in base alle esigenze.
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 aggiornati dopo l'esecuzione del backup. In questo caso, la nuova chiave SSH diventa non valido per il processo 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 chiave SSH.