Backup e ripristino di cluster con bmctl

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.

Avviso: l'utilizzo di un file di backup per ripristinare il cluster è l'ultima risorsa. Il processo di ripristino reimposta il cluster esistente e sovrascrive le informazioni del cluster. Sconsigliamo il ripristino da un file di backup a meno che il cluster non abbia subito un errore irreversibile. Contatta l'assistenza clienti Google Cloud per ricevere aiuto nella scelta della migliore linea di condotta.

La procedura di backup e ripristino di bmctl non include i volumi persistenti. I volumi creati dal provisioner del volume locale (LVP) rimangono invariati.

Se hai bisogno di ulteriore assistenza, contatta l'assistenza clienti Google Cloud. Puoi anche consultare la sezione Richiedere assistenza per saperne di più sulle risorse di assistenza, tra cui:

• Requisiti per l'apertura di una richiesta di assistenza.
• Strumenti per aiutarti a risolvere i problemi, ad esempio la configurazione dell'ambiente, i log e le metriche.
• Componenti supportati.

Eseguire il backup di un cluster

Il comando bmctl backup cluster aggiunge le informazioni del cluster dall'archivio etcd e i certificati PKI per il cluster specificato a un file tar. L'archivio etcd è l'archivio di backup di 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 tramite TLS. Questi dati vengono sottoposti a backup 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 una posizione sicura. Per evitare l'esposizione involontaria 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 recenti. Modifica la frequenza dei backup in modo che rifletta la frequenza delle modifiche significative ai tuoi cluster.

La versione di bmctl utilizzata per eseguire il backup di un cluster deve corrispondere alla versione del cluster di gestione.

Per eseguire il backup di un cluster:

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

   Lo scopo della procedura di backup è acquisire il cluster in uno stato buono noto, in modo da poter ripristinare l'operatività in caso di errore irreversibile.

   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 prevedi di eseguire il backup.
   • ADMIN_KUBECONFIG: il percorso del file kubeconfig per il cluster di amministrazione.

2. 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 il cluster. Per impostazione predefinita, gli spazi dei nomi del cluster per Google Distributed Cloud sono il nome del cluster preceduto da cluster-. Ad esempio, se chiami il cluster test, lo spazio dei nomi ha un nome come cluster-test.
   • ADMIN_KUBECONFIG: il percorso del file kubeconfig per il cluster di amministrazione.

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

   Come mostrato nell'esempio seguente, uno stato False per questi 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
     ...
   

4. 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 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 è 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 come 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.

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 irreversibile e non può essere ripristinato in altro modo. Ad esempio, i dati etcd sono danneggiati o il pod etcd è in un loop di arresto anomalo.

Nota: per migliorare le prestazioni del cluster, Google Distributed Cloud utilizza un'istanza etcd separata per archiviare gli oggetti Event. Questi oggetti Event hanno una durata (TTL) di un'ora. L'operazione di ripristino del cluster crea una nuova istanza etcd-events vuota, quindi perdi gli oggetti Event esistenti. Tuttavia, la perdita di oggetti Event non ha alcun impatto sul funzionamento del cluster. Gli eventi devono essere trattati come dati informativi, supplementari e ottenuti con il massimo impegno.

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, il processo di ripristino di Google Distributed Cloud utilizza solo file in memoria.

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

Per ripristinare un cluster:

1. Assicurati che tutte le macchine dei nodi disponibili per il cluster al momento del backup funzionino correttamente e siano raggiungibili.

2. Assicurati che la connettività SSH tra i nodi funzioni con le chiavi SSH utilizzate al momento del backup.

   Queste chiavi SSH vengono reintegrate nell'ambito del processo di ripristino.

3. Assicurati che le chiavi del account di servizio utilizzate al momento del backup siano ancora attive.

   Queste chiavi del account di servizio vengono reintegrate per il cluster ripristinato.

4. Per ripristinare un cluster di amministrazione, 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 che stai utilizzando.

5. 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 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.

Al termine del ripristino, segui questi passaggi per verificare che sia andato a buon fine:

1. Esegui questi comandi per verificare l'idoneità del nodo e i pod di sistema in esecuzione con il file kubeconfig generato:

   Esistono due tipi di pod etcd:

   • etcd-HOST_NAME, che corrisponde al pod etcd principale
   • etcd-events-HOST_NAME, che corrisponde al pod etcd-events

   kubectl get pods -n kube-system --kubeconfig GENERATED_KUBECONFIG
   kubectl get nodes --kubeconfig GENERATED_KUBECONFIG
   

2. Per ogni pod etcd, esegui il comando seguente per verificare l'integrità di etcd:

   kubectl exec ETCD_POD_NAME -n kube-system \
       --kubeconfig GENERATED_KUBECONFIG \
       -- /bin/sh -c 'ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
       --cacert=/etc/kubernetes/pki/etcd/ca.crt --key=/etc/kubernetes/pki/etcd/peer.key \
       --cert=/etc/kubernetes/pki/etcd/peer.crt endpoint health'
   

   Per un membro etcd integro, la risposta dovrebbe essere simile alla seguente:

   https://127.0.0.1:2379 is healthy: successfully committed proposal: took = 11.514177ms
   

3. Per ogni pod etcd-events, esegui il comando seguente per verificare l'integrità di etcd-events:

   kubectl exec ETCD_EVENTS_POD_NAME -n kube-system \
       --kubeconfig GENERATED_KUBECONFIG \
       -- /bin/sh -c 'ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2382 \
       --cacert=/etc/kubernetes/pki/etcd/ca.crt --key=/etc/kubernetes/pki/etcd/peer.key \
       --cert=/etc/kubernetes/pki/etcd/peer.crt endpoint health'
   

   Per un membro etcd-events integro, la risposta dovrebbe essere simile alla seguente:

   https://127.0.0.1:2382 is healthy: successfully committed proposal: took = 14.308148ms
   

Risoluzione dei problemi

Se riscontri problemi con la procedura di backup o ripristino, le seguenti sezioni potrebbero aiutarti a risolvere il problema.

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

Esaurimento della memoria durante un backup o un ripristino

Potresti ricevere messaggi di errore durante il processo di backup o ripristino che non sono molto autoesplicativi o chiari sui passaggi successivi. Se la workstation in 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 possono 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'operazione di ripristino riuscita, l'eliminazione del bootstrap può non riuscire e restituire 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 per il 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 sulle directory in base alle necessità.

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

Le operazioni correlate 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 è valida per la procedura di ripristino.

Per risolvere il problema, puoi aggiungere temporaneamente di nuovo la chiave SSH originale, quindi eseguire il ripristino. Al termine della procedura di ripristino, puoi ruotare la chiave SSH.