Backup e ripristino di cluster

Version 1.15 (latest)

• Più recente
• Versione 1.16
• Versioni precedenti (non supportate)

Questa pagina descrive come eseguire il backup e il ripristino dei cluster creati con Anthos clusters on bare metal. Queste istruzioni si applicano a tutti i tipi di cluster supportati da Anthos clusters on bare metal.

Avviso: l'utilizzo di un file di backup per ripristinare i dati etcd è l'ultima possibilità. È sconsigliato ripristinare da un file di backup, a meno che il cluster non sia completamente danneggiato. Contatta l'Assistenza Google per decidere quale sia la procedura migliore.

Esegui il backup di un cluster

Il processo di backup si compone di due parti. Innanzitutto, viene creato uno snapshot nell'archivio etcd. Quindi, i relativi certificati PKI vengono salvati in un file tar. L'archivio etcd è l'archivio di supporto di Kubernetes per tutti i dati del cluster e contiene tutti gli oggetti e gli oggetti personalizzati di Kubernetes necessari per gestire lo stato del cluster. I certificati PKI vengono utilizzati per l'autenticazione su TLS. Il backup di questi dati viene eseguito dal piano di controllo del cluster o da uno dei piani di controllo per un deployment ad alta disponibilità.

Ti consigliamo di eseguire regolarmente il backup dei tuoi cluster per assicurarti che i tuoi dati snapshot siano relativamente attuali. La frequenza dei backup dipende dalla frequenza con cui si verificano cambiamenti significativi per i tuoi cluster.

Crea un'istantanea dello store etcd

Nei Anthos clusters on bare metal, un pod denominato etcd-CONTROL_PLANE_NAME nello spazio dei nomi kube-system esegue l' etcd per il piano di controllo. Per eseguire il backup dell'archivio etcd del cluster, esegui questi passaggi dalla workstation di amministrazione:

1. Utilizza kubectl get po per identificare il pod etcd.

   kubectl --kubeconfig CLUSTER_KUBECONFIG get po -n kube-system \
       -l 'component=etcd,tier=control-plane'
   

   La risposta include il nome del pod etcd e il relativo stato.

2. Utilizza kubectl describe pod per visualizzare i container in esecuzione nel pod etcd, incluso il container etcd.

   kubectl --kubeconfig CLUSTER_KUBECONFIG describe pod ETCD_POD_NAME -n kube-system
   

3. Esegui una shell Bash nel container etcd:

   kubectl --kubeconfig CLUSTER_KUBECONFIG exec -it \
       ETCD_POD_NAME --container etcd --namespace kube-system \
       -- bin/sh
   

4. Dalla shell all'interno del container etcd, usa etcdctl (versione 3 dell'API) per salvare un'istantanea, snapshot.db, dell'archivio etcd.

   ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
       --cacert=/etc/kubernetes/pki/etcd/ca.crt \
       --cert=/etc/kubernetes/pki/etcd/peer.crt \
       --key=/etc/kubernetes/pki/etcd/peer.key \
       snapshot save /tmp/snapshotDATESTAMP.db
   

   Sostituisci DATESTAMP con la data corrente per evitare di sovrascrivere eventuali snapshot successivi.

5. Esci dalla shell del container ed esegui il comando seguente per copiare il file snapshot nella workstation di amministrazione.

   kubectl --kubeconfig CLUSTER_KUBECONFIG cp \
       kube-system/ETCD_POD_NAME:/tmp/snapshot.db \
       --container etcd snapshot.db
   

6. Copia il programma binario etcdctl dal pod etcd in modo che possa essere utilizzato durante il processo di ripristino.

   kubectl --kubeconfig CLUSTER_KUBECONFIG cp \
     kube-system/ETCD_POD_NAME:/usr/local/bin/etcdctl \
     --container etcd etcdctl
   

7. Archivia il file di snapshot e il programma binario etcdctl in una posizione esterna al cluster e non dipendente dall'operazione del cluster.

Archivia i certificati PKI

I certificati di cui eseguire il backup si trovano nella directory /etc/kubernetes/pki del piano di controllo. I certificati PIK insieme al file snapshot.db etcdstore sono necessari per recuperare un cluster nel caso in cui il piano di controllo smetta completamente di funzionare. I passaggi seguenti creano un file tar contenente i certificati PKI.

1. Utilizza ssh per connetterti al piano di controllo del cluster come root.

   ssh root@CONTROL_PLANE_NAME
   

2. Dal piano di controllo, crea un file tar, certs_backup.tar.gz con il contenuto della directory /etc/kubernetes/pki.

   tar -czvf certs_backup.tar.gz -C /etc/kubernetes/pki .
   

   La creazione del file tar dal piano di controllo conserva tutte le autorizzazioni del file del certificato.

3. Esci dal piano di controllo e, dalla workstation, copia il file tar contenente i certificati nella posizione preferita sulla workstation.

   sudo scp root@CONTROL_PLANE_NAME:certs_backup.tar.gz BACKUP_PATH
   

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 altri modi. Ad esempio, i dati etcd sono danneggiati o il pod etcd è in un loop di arresto anomalo.

Il processo di ripristino del cluster si compone di due parti. Innanzitutto, i certificati PKI vengono ripristinati sul piano di controllo. Quindi, i dati del negozio etcd vengono ripristinati.

Ripristina i certificati PKI

Supponendo che tu abbia eseguito il backup dei certificati PKI come descritto in Archiviare i certificati PKI, i seguenti passaggi descrivono come ripristinare i certificati dal file tar a un piano di controllo.

1. Copia il file tar dei certificati PKI, certs_backup.tar.gz, dalla workstation al piano di controllo del cluster.

   sudo scp -r BACKUP_PATH/certs_backup.tar.gz root@CONTROL_PLANE_NAME:~/
   

2. Utilizza ssh per connetterti al piano di controllo del cluster come root.

   ssh root@CONTROL_PLANE_NAME
   

3. Dal piano di controllo, estrai i contenuti del file tar nella directory /etc/kubernetes/pki.

   tar -xzvf certs_backup.tar.gz -C /etc/kubernetes/pki/
   

4. Esci dal piano di controllo.

Ripristina il negozio etcd

Quando si ripristina l'archivio etcd, il processo dipende dall'esecuzione o meno del cluster in modalità ad alta disponibilità (HA) e, in caso affermativo, dal fatto che il quorum sia stato preservato o meno. Utilizza le seguenti istruzioni per ripristinare l'archivio etcd in caso di errore del cluster:

• Se il cluster in errore non è in esecuzione in modalità ad alta disponibilità, ripristina l'archivio etcd sul piano di controllo seguendo i passaggi riportati di seguito.

• Se il cluster è in esecuzione in modalità ad alta disponibilità e il quorum viene conservato, non fare nulla. Finché un quorum viene conservato, non è necessario ripristinare i cluster non riusciti.

• Se il cluster è in esecuzione in modalità ad alta disponibilità e il quorum viene perso, ripeti i seguenti passaggi per ripristinare l'archivio etcd per ogni membro non riuscito.

Per rimuovere e ripristinare l'archivio etcd su un piano di controllo per un cluster in errore, segui questi passaggi dalla workstation:

1. Crea una directory /backup nella directory principale del piano di controllo.

   ssh root@CONTROL_PLANE_NAME "mkdir /backup"
   

   Questo passaggio non è obbligatorio, ma lo consigliamo. I passaggi seguenti suppongono che tu abbia creato una directory /backup.

2. Copia il file snapshot etcd, snapshot.db e il programma binario etcdctl dalla workstation alla directory backup nel piano di controllo del cluster.

   sudo scp snapshot.db root@CONTROL_PLANE_NAME:/backup
   sudo scp etcdctl root@CONTROL_PLANE_NAME:/backup
   

3. Utilizza SSH per connetterti al nodo del piano di controllo:

   ssh root@CONTROL_PLANE_NAME
   

4. Arresta i pod statici di etcd e kube-apiserver spostando i file manifest dalla directory /etc/kubernetes/manifests alla directory /backup.

   sudo mv /etc/kubernetes/manifests/etcd.yaml /backup/etcd.yaml
   sudo mv /etc/kubernetes/manifests/kube-apiserver.yaml /backup/kube-apiserver.yaml
   

5. Rimuovi la directory dei dati etcd.

   rm -rf /var/lib/etcd/
   

6. Esegui il ripristino degli snapshot etcdctl utilizzando il programma binario salvato.

   sudo chmod +x /backup/etcdctl
   sudo ETCDCTL_API=3 /backup/etcdctl \
       --cacert=/etc/kubernetes/pki/etcd/ca.crt \
       --cert=/etc/kubernetes/pki/etcd/server.crt \
       --key=/etc/kubernetes/pki/etcd/server.key \
       --data-dir=/var/lib/etcd \
       --name=CONTROL_PLANE_NAME \
       --initial-advertise-peer-urls=https://CONTROL_PLANE_IP:2380 \
       --initial-cluster=CONTROL_PLANE_NAME=https://CONTROL_PLANE_IP:2380 \
       snapshot restore /backup/snapshot.db
   

   Le voci per --name, --initial-advertise-peer-urls e --initial-cluster sono disponibili nel file manifest etcd.yaml che è stato spostato nella directory /backup.

7. Assicurati che /var/lib/etcd sia stato ricreato e che sia stato creato un nuovo membro in /var/lib/etcd/member.

8. Cambia il proprietario della directory /var/lib/etcd/member in 2003. A partire dalla versione 1.10.0 Anthos clusters on bare metal, il container etcd viene eseguito come utente non root con UID e GID pari a 2003.

   sudo chown -R 2003:2003 /var/lib/etcd
   

9. Sposta i manifest etcd e kube-apiserver nella directory /manifests in modo che i pod statici possano essere riavviati.

   sudo mv /backup/etcd.yaml /etc/kubernetes/manifests/etcd.yaml
   sudo mv /backup/kube-apiserver.yaml /etc/kubernetes/manifests/kube-apiserver.yaml
   

10. Esegui una shell Bash nel container etcd:

    kubectl --kubeconfig CLUSTER_KUBECONFIG exec -it \
        ETCD_POD_NAME --container etcd --namespace kube-system \
        -- bin/sh
    

    1. Utilizza etcdctl per verificare che il membro aggiunto funzioni correttamente.

    ETCDCTL_API=3 etcdctl --cert=/etc/kubernetes/pki/etcd/peer.crt  \
        --key=/etc/kubernetes/pki/etcd/peer.key \
        --cacert=/etc/kubernetes/pki/etcd/ca.crt \
        --endpoints=CONTROL_PLANE_IP:2379 \
        endpoint health
    

    Se ripristini più membri non riusciti, una volta ripristinati tutti i membri con errori, esegui il comando con gli indirizzi IP del piano di controllo di tutti i membri ripristinati nel campo "--endpoint".

    Ecco alcuni esempi:

    ETCDCTL_API=3 etcdctl --cert=/etc/kubernetes/pki/etcd/peer.crt  \
        --key=/etc/kubernetes/pki/etcd/peer.key \
        --cacert=/etc/kubernetes/pki/etcd/ca.crt \
        --endpoints=10.200.0.3:2379,10.200.0.4:2379,10.200.0.5:2379 \
        endpoint health
    

    In caso di successo per ogni endpoint, il cluster dovrebbe funzionare correttamente.

Risolvere i problemi

Se hai problemi con il processo di backup o ripristino, le seguenti sezioni potrebbero aiutarti a risolverli.

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

Autorizzazioni mancanti per i file durante il ripristino

Dopo un'attività di ripristino riuscita, l'eliminazione del bootstrap non riesce 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.

Anthos clusters on bare metal 1.14 e versioni successive hanno messaggi di errore più chiari in cui è necessario scrivere le directory. Assicurati che le directory segnalate siano scrivibili e aggiorna le autorizzazioni per le directory secondo necessità.

Aggiornamento della chiave SSH dopo che 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. Una volta completato il processo di ripristino, puoi ruotare la chiave SSH.