Backup e ripristino di cluster

Questa pagina descrive come eseguire il backup e il ripristino dei cluster creati con Cluster Anthos su Bare Metal. Queste istruzioni si applicano a tutti i tipi di cluster supportati dai cluster Anthos su Bare Metal.

Eseguire il backup di un cluster

Il processo di backup si compone di due parti. Innanzitutto, viene creato uno snapshot dall'archivio etcd. I certificati PKI correlati verranno quindi salvati in 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 richiesti 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 alta disponibilità (HA).

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

Crea un'istantanea dell'archivio etcd

Nei cluster Anthos su Bare Metal, un pod denominato etcd-CONTROL_PLANE_NAME nello spazio dei nomi kube-system esegue il etcd per il piano di controllo. Per eseguire il backup dell'archivio etcd del cluster, esegui i passaggi seguenti dalla workstation di amministrazione:

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

Esegui una shell Bash nel container etcd:

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

Dalla shell all'interno del container etcd, utilizza 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 la sovrascrittura di eventuali snapshot successivi.

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

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

Archivia il file dello 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 etcd store snapshot.db sono necessari per recuperare un cluster in caso di interruzione completa del piano di controllo. I passaggi seguenti servono a creare un file tar contenente i certificati PKI.

Utilizza ssh per connetterti al piano di controllo del cluster come root.
```
ssh root@CONTROL_PLANE_NAME
```
Dal piano di controllo, crea un file tar, certs_backup.tar.gz con i contenuti della directory /etc/kubernetes/pki.
```
tar -czvf certs_backup.tar.gz -C /etc/kubernetes/pki .
```
La creazione del file tar all'interno del piano di controllo conserva tutte le autorizzazioni dei file del certificato.
Esci dal piano di controllo e, dalla workstation, copia il file tar contenente i certificati in una 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 in alcun altro modo. 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 certificati PKI

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

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:~/
```
Utilizza ssh per connetterti al piano di controllo del cluster come root.
```
ssh root@CONTROL_PLANE_NAME
```
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/
```
Esci dal piano di controllo.

Ripristina il negozio etcd

Quando si ripristina l'archivio etcd, la procedura dipende dal fatto che il cluster sia in esecuzione o meno in modalità alta disponibilità (HA) e, in tal caso, se sia stato mantenuto o meno il quorum. Utilizza la seguente guida per ripristinare l'archivio etcd per una determinata situazione di errore del cluster:

Se il cluster in errore non è in esecuzione in modalità ad alta disponibilità, ripristina l'archivio etcd nel piano di controllo seguendo questa procedura.
Se il cluster è in esecuzione in modalità ad alta disponibilità e il quorum viene conservato, non eseguire alcuna operazione. 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.

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

Crea una directory /backup nella directory radice del piano di controllo.
```
ssh root@CONTROL_PLANE_NAME "mkdir /backup"
```
Questo passaggio non è strettamente obbligatorio, ma ti consigliamo di farlo. I passaggi seguenti indicano che hai creato una directory /backup.
Copia il file snapshot etcd, snapshot.db e etcdctl dalla console di lavoro alla directory backup del piano di controllo del cluster.
```
sudo scp snapshot.db root@CONTROL_PLANE_NAME:/backup
sudo scp etcdctl root@CONTROL_PLANE_NAME:/backup
```
Utilizza SSH per connetterti al nodo del piano di controllo:
```
ssh root@CONTROL_PLANE_NAME
```

Interrompi i pod etcd e kube-apiserver spostando i relativi file manifest dalla directory /etc/kubernetes/manifests e nella directory /backup.

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

Rimuovi la directory dei dati etcd.
```
rm -rf /var/lib/etcd/
```

Esegui il ripristino dello 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 si trovano nel file manifest etcd.yaml spostato nella directory /backup.

Assicurati che /var/lib/etcd sia stato ricreato e che sia stato creato un nuovo membro in /var/lib/etcd/member.
Cambia il proprietario della directory /var/lib/etcd/member in 2003. A partire dai cluster Anthos sulla release Bare Metal 1.10.0, il container etcd viene eseguito come utente non root con UID e GID di 2003.
```
sudo chown -R 2003:2003 /var/lib/etcd
```

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

Esegui una shell Bash nel container etcd:

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

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 non riusciti, esegui il comando con gli indirizzi IP del piano di controllo di tutti i membri ripristinati nel campo "--endpoints'.

Ad esempio:

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

Se l'operazione riesce per ogni endpoint, il cluster dovrebbe funzionare correttamente.