Backup e ripristino di cluster con bmctl

Lo strumento a riga di comando bmctl consente di eseguire il backup e il ripristino dei cluster creati con il software Distributed Cloud solo per bare metal per prepararsi al ripristino di emergenza o per ripristinare un cluster danneggiato in tutti i tipi di cluster. Il ripristino da un backup è l'ultima risorsa che reimposta il cluster e sovrascrive le informazioni esistenti del cluster. Esegui il ripristino dal backup solo se un cluster ha un errore irreversibile. Contatta l'assistenza clienti Google Cloud per decidere la linea d'azione migliore.

Elementi inclusi ed esclusi dal backup

Il processo di backup e ripristino di bmctl opera a livello del control plane di Kubernetes ed è diverso da altre soluzioni di backup. Le soluzioni di backup non Kubernetes acquisiscono i dati dei workload, lo spazio di archiviazione permanente e i sistemi operativi host delle macchine fisiche. Il processo di backup e ripristino di bmctl ripristina i cluster Kubernetes senza eseguire il backup di questi altri componenti.

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. Esegui il ripristino da un file di backup solo se il cluster ha subito un errore irreversibile. Contatta l'assistenza clienti Google Cloud per decidere la linea d'azione migliore.

Stato del control plane (di cui è stato eseguito il backup tramite il processo di backup bmctl)

bmctl esegue il backup dei seguenti oggetti:

• etcd. Tutte le risorse Kubernetes e gli oggetti personalizzati che definiscono la configurazione e lo stato scelto del cluster (ad esempio, specifiche dei pod, deployment, ConfigMap e secret).
• Certificati PKI. Certificati utilizzati per la comunicazione sicura all'interno del cluster.
• File di configurazione e manifest dei nodi. Configurazioni relative ai nodi del cluster.

Spazio di archiviazione per workload e VM Runtime (non sottoposto a backup dal processo di backup di bmctl)

bmctl non esegue il backup dei seguenti dati:

• Stato di runtime di pod e container attivi. bmctl non salva i processi attivi e i dati delle applicazioni in memoria. Dopo un ripristino, Kubernetes riavvia i pod dalle specifiche etcd. Tutti gli stati in memoria non salvati andranno persi.
• Archiviazione di volumi permanenti. bmctl non esegue il backup dei dati archiviati in volumi permanenti, volumi creati dal provisioner di volumi locali (LVP) o driver di archiviazione esterni.
• Dischi delle macchine virtuali. bmctl non esegue il backup dei contenuti del disco rigido virtuale della VM, come database, file o stato del sistema operativo all'interno della VM.

Devi utilizzare meccanismi di backup nativi di Kubernetes o in-guest per proteggere i dati dell'applicazione e lo stato della macchina virtuale. Se il driver di archiviazione sottostante supporta gli snapshot dei volumi CSI, utilizza gli snapshot dei volumi standard di Kubernetes per creare copie point-in-time dei volumi permanenti. Per saperne di più sulla configurazione dello spazio di archiviazione, consulta la panoramica dello spazio di archiviazione.

Esegui gli agenti di backup all'interno del sistema operativo guest delle macchine virtuali VM Runtime o esegui il deployment di strumenti di backup nativi dell'applicazione all'interno dei workload Kubernetes.

Sistemi operativi host fisici (non supportati)

Tratta i sistemi operativi Linux fisici sui nodi Google Distributed Cloud come infrastruttura usa e getta. L'architettura di networking di Kubernetes non supporta il ripristino delle immagini sistema operativo a livello di host. Pertanto, Google non supporta l'installazione di agenti di backup a livello di host di terze parti direttamente sul sistema operativo host o il ripristino di nodi fisici da backup di immagini a livello di sistema operativo o snapshot di dischi.

Se installi agenti di backup fisici di terze parti direttamente sul sistema operativo host Linux, potresti introdurre rischi significativi.

Molti agenti di backup installano moduli kernel proprietari o driver di filtro a livello di blocco per monitorare le modifiche e bloccare i blocchi del disco locale durante le operazioni di snapshot, il che può causare i seguenti problemi:

• Il database etcd non può aggiungere dati ai log write-ahead, gli heartbeat dei nodi scadono, il consenso Raft non riesce e i cluster diventano instabili.
• I driver del kernel di terze parti non supportati entrano in conflitto con le routine del kernel di basso livello e il runtime del container, causando l'errore degli upgrade del cluster.
• Il ripristino di un nodo fisico da un backup di immagini o da uno snapshot del disco viola il protocollo di consenso Raft. Il database etcd non è più sincronizzato con i log sui nodi del control plane e si verifica un grave danneggiamento dello stato del cluster.
• I nodi worker non sono più sincronizzati con la fonte di riferimento del server API, gli indirizzi IP di Dataplane V2 (Cilium) entrano in conflitto e il traffico viene interrotto.

Per recuperare un nodo fisico che ha subito un errore del sistema operativo o dell'hardware, non ripristinare un'immagine sistema operativo. Rimuovi invece il nodo dal cluster, reinstalla un sistema operativo di base pulito e aggiungi di nuovo il nodo al pool di nodi. Per istruzioni dettagliate sul ripristino, consulta Reimposta un nodo con errori.

Se hai bisogno di ulteriore assistenza, contatta l'assistenza clienti Google Cloud. Puoi anche consultare Assistenza per ulteriori informazioni 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.

Esegui il backup di un cluster

Il comando bmctl backup cluster pacchettizza i dati etcd e i certificati PKI del cluster in un file tar. Il database etcd è il datastore centrale per tutti i dati del cluster e contiene tutti gli oggetti Kubernetes e le risorse personalizzate necessari per gestire lo stato del cluster. I certificati PKI eseguono 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 affidabilità (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 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 aggiornati. Regola 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.

Se hai installato Node Agent sui tuoi cluster, la directory /tmp sul nodo di amministrazione e su tutti i nodi di destinazione deve avere 12 GB di spazio libero. Se non puoi modificare le dimensioni della directory /tmp per i nodi di destinazione, consulta Modifica la capacità di archiviazione locale per i nodi di destinazione. Se non riesci a modificare le dimensioni della directory /tmp per il nodo di amministrazione, consulta Modifica la capacità di archiviazione locale per un nodo di amministrazione.

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 del processo di backup è acquisire il cluster in uno stato valido noto, in modo da poter ripristinare il funzionamento 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 vuoi 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 del 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 assegni al cluster il nome test, lo spazio dei nomi avrà un nome simile a cluster-test.
   • ADMIN_KUBECONFIG: il percorso del file kubeconfig per il cluster di amministrazione.

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

   Come mostrato nell'esempio seguente, lo 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 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 subito un errore irreversibile 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.

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 gli oggetti Event esistenti vengono persi. Tuttavia, la perdita di oggetti Event non ha alcun impatto sul funzionamento del cluster. Gli eventi devono essere trattati solo come dati informativi, supplementari e best-effort.

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 utilizzata per ripristinare un cluster deve corrispondere alla versione del cluster di gestione.

Per ripristinare un cluster:

1. Assicurati che tutte le macchine nodo 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 dei 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à dei nodi 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 questo comando 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 questo comando 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 sezioni seguenti potrebbero aiutarti a risolverli.

Se hai bisogno di ulteriore assistenza, 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 che non sono molto chiari o non spiegano i passaggi successivi. Se la workstation su cui esegui il comando bmctl non dispone di molta RAM, potresti non avere memoria sufficiente 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 presentano messaggi di errore più chiari su quali directory 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 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, quindi eseguire il ripristino. Al termine del processo di ripristino, puoi ruotare la chiave SSH.

Impossibile creare un backup per un nodo dell'agente del nodo

Se utilizzi l'agente nodo e ricevi un errore che indica che la creazione del backup non riesce a creare un file di archivio, simile al seguente:

  I0508 15:29:36.831790  657351 backup_cluster.go:255] Retrying backup node: 128.187.102.133, due to error: failed receive chunk data: rpc error: code = Unknown desc = archiver.CreateArchiveWithList
  failed: failed to create archive file: failed to copy data from file: var/lib/etcd-events/member/snap/db, file size: 26136576, copy bytes: 12478464,
  error: write /tmp/uploadFileTemp1561164777: no space left on device

Verifica che siano disponibili 12 GB di spazio libero nella directory /tmp sul nodo di amministrazione e su tutti i nodi di destinazione. Se non riesci a modificare le dimensioni della directory /tmp per i nodi di destinazione, consulta Aumenta la capacità di archiviazione locale per i backup di Node Agent.

Dopo aver verificato che nella directory /tmp siano presenti 12 GB di spazio libero per il nodo di amministrazione e tutti i nodi di destinazione, riprova a eseguire il backup.