Sauvegarder et restaurer des clusters

Cette page explique comment sauvegarder et restaurer des clusters créés avec les clusters Anthos sur Bare Metal. Ces instructions s'appliquent à tous les types de clusters compatibles avec les clusters Anthos sur Bare Metal.

Sauvegarder un cluster

Le processus de sauvegarde comporte deux parties. Tout d'abord, un instantané est généré à partir du magasin etcd. Les certificats PKI associés sont ensuite enregistrés dans un fichier tar. Le magasin etcd est le magasin Kubernetes de stockage pour toutes les données de cluster. Il contient tous les objets Kubernetes et les objets personnalisés requis pour gérer l'état du cluster. Les certificats PKI sont utilisés pour l'authentification via TLS. Ces données sont sauvegardées à partir du plan de contrôle du cluster ou de l'un des plans de contrôle dans le cas d'un déploiement haute disponibilité.

Nous vous recommandons de sauvegarder régulièrement vos clusters pour vous assurer que vos données instantanées sont à peu près à jour. La fréquence des sauvegardes dépend de la fréquence à laquelle vos clusters enregistrent des modifications importantes.

Créer un instantané du magasin etcd

Dans les clusters Anthos sur Bare Metal, un pod répertorié etcd-CONTROL_PLANE_NAME dans l'espace de noms kube-system exécute l'etcd pour ce plan de contrôle. Pour sauvegarder le magasin etcd du cluster, accédez au poste de travail administrateur, puis procédez comme suit :

Utilisez kubectl get po pour identifier le pod etcd.

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

La réponse inclut le nom et l'état du pod etcd.

Utilisez kubectl describe pod pour afficher les conteneurs s'exécutant dans le pod etcd, y compris le conteneur etcd.
```
kubectl --kubeconfig CLUSTER_KUBECONFIG describe pod ETCD_POD_NAME -n kube-system
```

Exécutez une interface système bash dans le conteneur etcd.

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

À partir de l'interface système du conteneur etcd, utilisez etcdctl (version 3 de l'API) pour enregistrer un instantané (snapshot.db) du magasin 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

Remplacez DATESTAMP par la date actuelle pour éviter d'écraser les instantanés suivants.

Quittez le shell du conteneur et exécutez la commande suivante pour copier le fichier d'instantané sur le poste de travail administrateur.
```
kubectl --kubeconfig CLUSTER_KUBECONFIG cp \
    kube-system/ETCD_POD_NAME:/tmp/snapshot.db \
    --container etcd snapshot.db
```

Copiez le binaire etcdctl à partir du pod etcd afin de pouvoir l'utiliser pendant le processus de restauration.

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

Stockez le fichier d'instantané et le binaire etcdctl dans un emplacement hors du cluster et indépendant du fonctionnement du cluster.

Archiver les certificats PKI

Les certificats à sauvegarder se trouvent dans le répertoire /etc/kubernetes/pki du plan de contrôle. Les certificats PKI et le fichier de magasin snapshot.db etcd sont nécessaires pour récupérer un cluster si le plan de contrôle s'arrête complètement. Les étapes suivantes permettent de créer un fichier tar contenant les certificats PKI.

Utilisez ssh pour vous connecter au plan de contrôle du cluster en mode root.
```
ssh root@CONTROL_PLANE_NAME
```
Depuis le plan de contrôle, créez un fichier tar (certs_backup.tar.gz) incluant le contenu du répertoire /etc/kubernetes/pki.
```
tar -czvf certs_backup.tar.gz -C /etc/kubernetes/pki .
```
La création de ce fichier à partir du plan de contrôle permet de conserver toutes les autorisations du fichier de certificat.
Quittez le plan de contrôle. À partir du poste de travail, copiez le fichier tar contenant les certificats vers l'emplacement de votre choix sur le poste de travail.
```
sudo scp root@CONTROL_PLANE_NAME:certs_backup.tar.gz BACKUP_PATH
```

Restaurer un cluster

La restauration d'un cluster à partir d'une sauvegarde est une opération à n'effectuer qu'en dernier recours, uniquement si le cluster subit une grave défaillance et qu'il est impossible de le remettre en service par un autre moyen. Par exemple, une restauration est nécessaire si les données etcd sont corrompues ou si le pod etcd se retrouve bloqué dans une boucle de plantage.

Le processus de restauration de cluster s'effectue en deux étapes. Premièrement, les certificats PKI sont restaurés dans le plan de contrôle. Ensuite, les données du magasin etcd sont restaurées.

Restaurer des certificats PKI

Imaginons que vous avez sauvegardé les certificats PKI, comme décrit dans la section Archiver les certificats PKI. Les étapes suivantes expliquent comment restaurer les certificats du fichier tar dans un plan de contrôle.

Copiez le fichier tar contenant les certificats PKI (certs_backup.tar.gz) depuis le poste de travail vers le plan de contrôle du cluster.
```
sudo scp -r BACKUP_PATH/certs_backup.tar.gz root@CONTROL_PLANE_NAME:~/
```
Utilisez ssh pour vous connecter au plan de contrôle du cluster en mode root.
```
ssh root@CONTROL_PLANE_NAME
```
Depuis le plan de contrôle, extrayez le contenu du fichier tar vers le répertoire /etc/kubernetes/pki.
```
tar -xzvf certs_backup.tar.gz -C /etc/kubernetes/pki/
```
Quittez le plan de contrôle.

Restaurer le magasin etcd

Lors de la restauration du magasin etcd, le processus varie selon que le cluster s'exécute en mode haute disponibilité ou non. Si c'est le cas, il varie également selon que le quorum a été conservé ou non. Suivez les instructions ci-dessous pour restaurer le magasin etcd pour un cas de défaillance de cluster donné :

Si le cluster qui a échoué ne s'exécute pas en mode haute disponibilité, restaurez le magasin etcd sur le plan de contrôle en procédant comme suit :
Si le cluster s'exécute en mode haute disponibilité et le quorum a été conservé, ne faites rien. Tant que le quorum est conservé, vous n'avez pas besoin de restaurer les clusters défaillants.
Si le cluster est en mode haute disponibilité, mais que le quorum est perdu, répétez les étapes suivantes afin de restaurer le magasin etcd pour chaque membre défaillant.

Suivez ces étapes à partir du poste de travail pour supprimer et restaurer le magasin etcd dans un plan de contrôle en cas de cluster défaillant :

Créez un répertoire /backup dans le répertoire racine du plan de contrôle.
```
ssh root@CONTROL_PLANE_NAME "mkdir /backup"
```
Cette étape n'est pas obligatoire, mais nous vous la recommandons. Pour les étapes suivantes, nous partons du principe que vous avez créé un répertoire /backup.
Copiez le fichier d'instantané etcd, les binaires snapshot.db et etcdctl du poste de travail vers le répertoire backup du plan de contrôle du cluster.
```
sudo scp snapshot.db root@CONTROL_PLANE_NAME:/backup
sudo scp etcdctl root@CONTROL_PLANE_NAME:/backup
```
Utilisez SSH pour vous connecter au nœud du plan de contrôle d'administrateur :
```
ssh root@CONTROL_PLANE_NAME
```
Arrêtez les pods etcd et les pods statiques kube-apiserver en déplaçant leurs fichiers manifestes du répertoire /etc/kubernetes/manifests vers le répertoire /backup.
```
sudo mv /etc/kubernetes/manifests/etcd.yaml /backup/etcd.yaml
sudo mv /etc/kubernetes/manifests/kube-apiserver.yaml /backup/kube-apiserver.yaml
```
Supprimez le répertoire de données etcd.
```
rm -rf /var/lib/etcd/
```

Exécutez la restauration d'instantané etcdctl à l'aide du binaire enregistré.

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

Les entrées de --name, --initial-advertise-peer-urls et --initial-cluster sont disponibles dans le fichier manifeste etcd.yaml déplacé vers le répertoire /backup.

Assurez-vous que /var/lib/etcd a bien été recréé et qu'un nouveau membre est créé dans /var/lib/etcd/member.
Remplacez le propriétaire du répertoire /var/lib/etcd/member par 2003. À partir de la version 1.10.0 d'Anthos clusters on bare metal, le conteneur etcd s'exécute en tant qu'utilisateur non racine, avec l'UID et le GID de 2003.
```
sudo chown -R 2003:2003 /var/lib/etcd
```

Replacez les fichiers manifestes etcd et kube-apiserver dans le répertoire /manifests afin que les pods statiques puissent redémarrer.

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

Exécutez une interface système bash dans le conteneur etcd.

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

Utilisez etcdctl pour vérifier que le membre ajouté fonctionne correctement.

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

Pour restaurer plusieurs membres défaillants, attendez que tous les membres défaillants aient été restaurés, puis exécutez la commande avec les adresses IP du plan de contrôle de tous les membres restaurés dans le champ "--endpoints".

Exemple :

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

Si l'opération réussit pour chaque point de terminaison, votre cluster devrait fonctionner correctement.