Backup e ripristino di cluster

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

Esegui il backup di un cluster

Il processo di backup è composto da due parti. Innanzitutto, viene creato uno snapshot dall'archivio etcd. Quindi, i relativi certificati PKI vengono salvati in un file tar. L'archivio etcd è il supporto 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 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à (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 l'ecc 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 suo 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 uno snapshot, 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 attuale per evitare di sovrascrivere gli snapshot successivi.

Esci dalla shell del container ed esegui il comando seguente per copiare il file dello 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 dipende dal funzionamento 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 etcd store sono necessari per recuperare un cluster in caso di malfunzionamento del piano di controllo. Segui questi passaggi per 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 del 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 al servizio in altro modo. Ad esempio, i dati etcd sono danneggiati o il pod etcd si trova 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 seguenti passaggi descrivono 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 ripristini l'archivio etcd, il processo dipende dal fatto che il cluster sia o meno in esecuzione in modalità alta disponibilità (HA) e, in caso affermativo, dal fatto che il quorum sia stato conservato o meno. 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 sul piano di controllo seguendo questi passaggi.
Se il cluster è in esecuzione in modalità ad alta disponibilità e il quorum viene conservato, non eseguire alcuna azione. 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 passaggi seguenti per ripristinare l'archivio etcd per ogni membro con errori.

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 principale del piano di controllo.
```
ssh root@CONTROL_PLANE_NAME "mkdir /backup"
```
Questo passaggio non è strettamente obbligatorio, ma è consigliabile. I passaggi riportati di seguito supponiamo che tu abbia creato una directory /backup.
Copia il file snapshot etcd, snapshot.db e etcdctl dal programma binario della 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
```
Utilizza SSH per connetterti al nodo del piano di controllo:
```
ssh root@CONTROL_PLANE_NAME
```

Interrompi i pod statici etcd e kube-apiserver spostando i relativi 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

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

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 si trovano nel file manifest etcd.yaml che è stato spostato nella directory /backup.

Assicurati che /var/lib/etcd sia stato ricreato e che un nuovo membro sia stato creato in /var/lib/etcd/member.
Cambia il proprietario della directory /var/lib/etcd/member in 2003. A partire dalla versione 1.10.0 di Cluster Anthos on bare metal, 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 confermare 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 stai ripristinando più membri non riusciti, una volta ripristinati tutti gli abbonati 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

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