Sauvegarder et restaurer des clusters avec bmctl

Cette page explique comment utiliser bmctl pour sauvegarder et restaurer des clusters créés avec Google Distributed Cloud. Ces instructions s'appliquent à tous les types de clusters compatibles avec Google Distributed Cloud.

Le processus de sauvegarde et de restauration bmctl n'inclut pas les volumes persistants. Tous les volumes créés par l'approvisionneur de volumes locaux ne sont pas modifiés.

Si vous avez besoin d'aide supplémentaire, contactez l'assistance Cloud Customer Care.

Sauvegarder un cluster

La commande bmctl backup cluster ajoute les informations du cluster à partir du magasin etcd et les certificats PKI du cluster spécifié dans un fichier tar. Le magasin etcd est le magasin de sauvegarde Kubernetes pour toutes les données de cluster. Il contient tous les objets personnalisés et les objets Kubernetes 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é.

Le fichier tar de sauvegarde contient des identifiants sensibles, y compris vos clés de compte de service et la clé SSH. Stockez les fichiers de sauvegarde dans un emplacement sécurisé. Pour éviter toute exposition accidentelle des fichiers, le processus de sauvegarde Google Distributed Cloud n'utilise que des fichiers en mémoire.

Sauvegardez régulièrement vos clusters pour vous assurer que vos données d'instantané sont relativement à jour. Ajustez le taux de sauvegardes pour refléter la fréquence des modifications importantes apportées à vos clusters.

La version bmctl que vous utilisez pour sauvegarder un cluster doit correspondre à la version du cluster de gestion.

Pour sauvegarder un cluster :

Assurez-vous que votre cluster fonctionne correctement avec des identifiants fonctionnels et une connectivité SSH à tous les nœuds.

L'objectif du processus de sauvegarde est de capturer votre cluster dans un état correct connu, afin de pouvoir restaurer l'opération en cas de défaillance sérieuse.

Exécutez la commande suivante pour vérifier votre cluster :
```
bmctl check cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
```
Remplacez les éléments suivants :
- CLUSTER_NAME par le nom du cluster que vous prévoyez de sauvegarder ;
- ADMIN_KUBECONFIG par le chemin d'accès du fichier kubeconfig du cluster d'administrateur.
Exécutez la commande suivante pour vous assurer que le cluster cible n'est pas en état de rapprochement :
```
kubectl describe cluster CLUSTER_NAME -n CLUSTER_NAMESPACE --kubeconfig ADMIN_KUBECONFIG
```
Remplacez les éléments suivants :
- CLUSTER_NAME : nom du cluster à sauvegarder.
- CLUSTER_NAMESPACE : espace de noms du cluster. Par défaut, les espaces de noms des clusters Google Distributed Cloud sont le nom du cluster précédé de cluster-. Par exemple, si vous nommez votre cluster test, l'espace de noms porte un nom tel que cluster-test.
- ADMIN_KUBECONFIG : chemin du fichier kubeconfig du cluster d'administrateur.

Dans la section Status du résultat de la commande, recherchez Conditions de type Reconciling.

Comme illustré dans l'exemple suivant, l'état False pour ces Conditions signifie que le cluster est stable et prêt à être sauvegardé.

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

Exécutez la commande suivante pour sauvegarder le cluster :
```
bmctl backup cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
```
Remplacez les éléments suivants :
- CLUSTER_NAME : nom du cluster à sauvegarder.
- ADMIN_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur.
Par défaut, le fichier tar de sauvegarde est enregistré dans le répertoire de l'espace de travail (bmctl-workspace, par défaut) sur votre poste de travail administrateur. Le fichier tar est nommé CLUSTER_NAME_backup_TIMESTAMP.tar.gz, où CLUSTER_NAME est le nom du cluster en cours de sauvegarde et TIMESTAMP est la date et l'heure de la sauvegarde. Par exemple, si le nom du cluster est testuser, le fichier de sauvegarde porte un nom tel que testuser_backup_2006-01-02T150405Z0700.tar.gz.

Pour spécifier un nom et un emplacement différents pour votre fichier de sauvegarde, utilisez l'option --backup-file.

Le fichier de sauvegarde expire au bout d'un an et le processus de restauration du cluster ne fonctionne pas avec les fichiers de sauvegarde arrivés à expiration.

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 fichier tar de sauvegarde contient des identifiants sensibles, y compris vos clés de compte de service et la clé SSH. Pour éviter toute exposition accidentelle des fichiers, le processus de restauration de Google Distributed Cloud n'utilise que des fichiers en mémoire.

La version bmctl que vous utilisez pour restaurer un cluster doit correspondre à la version du cluster de gestion.

Pour restaurer un cluster, procédez comme suit :

Assurez-vous que toutes les machines de nœud qui étaient disponibles pour le cluster au moment de la sauvegarde fonctionnent correctement et sont accessibles.
Assurez-vous que la connectivité SSH entre les nœuds fonctionne avec les clés SSH qui ont été utilisées au moment de la sauvegarde.

Ces clés SSH sont rétablies dans le cadre du processus de restauration.
Assurez-vous que les clés de compte de service qui ont été utilisées au moment de la sauvegarde sont toujours actives.

Ces clés de compte de service sont rétablies pour le cluster restauré.
Pour restaurer un cluster d'administrateur, hybride ou autonome, exécutez la commande suivante :
```
bmctl restore cluster -c CLUSTER_NAME --backup-file BACKUP_FILE
```
Remplacez les éléments suivants :
- CLUSTER_NAME : nom du cluster à restaurer.
- BACKUP_FILE : chemin d'accès et nom du fichier de sauvegarde que vous utilisez.
Pour supprimer un cluster d'utilisateur, exécutez la commande suivante :
```
bmctl restore cluster -c CLUSTER_NAME --backup-file BACKUP_FILE \
    --kubeconfig ADMIN_KUBECONFIG
```
Remplacez les éléments suivants :
- CLUSTER_NAME : nom du cluster à restaurer.
- BACKUP_FILE : chemin d'accès et nom du fichier de sauvegarde que vous utilisez.
- ADMIN_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur.

À la fin du processus de restauration, un nouveau fichier kubeconfig est généré pour le cluster restauré.

Résoudre les problèmes

Si vous rencontrez des problèmes lors du processus de sauvegarde ou de restauration, les sections suivantes peuvent vous aider à les résoudre.

Si vous avez besoin d'aide supplémentaire, contactez l'Assistance Google.

Mémoire insuffisante lors d'une sauvegarde ou d'une restauration

Vous pouvez recevoir des messages d'erreur pendant le processus de sauvegarde ou de restauration qui ne sont pas très explicites ou qui ne sont pas clairs sur les étapes suivantes. Si la station de travail sur laquelle vous exécutez la commande bmctl ne dispose pas de beaucoup de RAM, vous ne disposez peut-être pas de suffisamment de mémoire pour effectuer la sauvegarde ou la restauration.

Google Distributed Cloud version 1.13 et versions ultérieures peuvent utiliser le paramètre --use-disk dans la commande de sauvegarde. Pour conserver les autorisations des fichiers, ce paramètre modifie les autorisations des fichiers. L'utilisateur qui exécute la commande doit donc être un utilisateur racine (ou utiliser sudo).

Autorisations manquantes pour les fichiers lors de la restauration

Après une tâche de restauration réussie, la suppression de l'amorçage peut échouer avec un message d'erreur semblable à l'exemple suivant :

Error: failed to restore node config files: sftp: "Failure" (SSH_FX_FAILURE)

Cette erreur peut signifier que certains répertoires requis par la restauration ne sont pas accessibles en écriture.

Google Distributed Cloud version 1.14 et versions ultérieures affichent des messages d'erreur plus clairs sur les répertoires qui doivent être accessibles en écriture. Assurez-vous que les répertoires signalés sont accessibles en écriture et mettez à jour les autorisations sur les répertoires si nécessaire.

L'actualisation de la clé SSH après une sauvegarde interrompt le processus de restauration

Les opérations liées à SSH au cours du processus de restauration peuvent échouer si la clé SSH est actualisée après la sauvegarde. Dans ce cas, la nouvelle clé SSH n'est plus valide pour le processus de restauration.

Pour résoudre ce problème, vous pouvez ajouter temporairement la clé SSH d'origine, puis effectuer la restauration. Une fois le processus de restauration terminé, vous pouvez effectuer la rotation de la clé SSH.