Sauvegarder et restaurer des clusters avec bmctl

Ce document explique comment utiliser bmctl pour sauvegarder et restaurer des clusters créés avec Google Distributed Cloud (logiciel uniquement) sur Bare Metal. Ces instructions s'appliquent à tous les types de clusters.

**Avertissement** : L'utilisation d'un fichier de sauvegarde pour restaurer votre cluster est un dernier recours. Le processus de restauration réinitialise le cluster existant et écrase les informations du cluster. Nous vous déconseillons d'effectuer une restauration à partir d'un fichier de sauvegarde, sauf en cas de défaillance catastrophique du cluster. Contactez Cloud Customer Care pour obtenir de l'aide afin de choisir la meilleure solution.

Éléments sauvegardés et non sauvegardés

Le processus de sauvegarde et de restauration bmctl fonctionne au niveau de la couche du plan de contrôle Kubernetes et diffère des autres solutions de sauvegarde. Les solutions de sauvegarde non Kubernetes capturent les données de charge de travail, le stockage persistant et les systèmes d'exploitation hôtes des machines physiques. Le processus de sauvegarde et de restauration bmctl restaure vos clusters Kubernetes sans sauvegarder aucun de ces autres composants.

État du plan de contrôle (sauvegardé par le processus de sauvegarde bmctl)

bmctl sauvegarde les objets suivants :

• Magasin etcd. Toutes les ressources Kubernetes et tous les objets personnalisés qui définissent la configuration et l'état choisi du cluster (par exemple, les spécifications de pod, les déploiements, les ConfigMaps et les secrets).
• Certificats PKI. Certificats utilisés pour sécuriser la communication au sein du cluster.
• Fichiers de configuration et manifestes des nœuds. Configurations liées aux nœuds du cluster.

Stockage de l'environnement d'exécution de la charge de travail et de la VM (non sauvegardé par le processus de sauvegarde bmctl)

bmctl ne sauvegarde pas les données suivantes :

• État de l'environnement d'exécution du conteneur et du pod en direct. bmctl n'enregistre pas les processus actifs ni les données d'application en mémoire. Après une restauration, Kubernetes redémarre les pods à partir des spécifications etcd. Tout état en mémoire non enregistré est perdu.
• Stockage de volumes persistants. bmctl ne sauvegarde pas les données stockées dans des volumes persistants, des volumes créés par l'approvisionneur de volumes locaux (LVP) ni des pilotes de stockage externes.
• Disques de machine virtuelle. bmctl ne sauvegarde pas le contenu du disque dur virtuel de la VM, comme les bases de données, les fichiers ou l'état du système d'exploitation à l'intérieur de la VM.

Vous devez utiliser des mécanismes de sauvegarde natifs de Kubernetes ou invités pour protéger les données d'application et l'état de la machine virtuelle. Si votre pilote de stockage sous-jacent est compatible avec les instantanés de volume CSI, utilisez les instantanés de volume Kubernetes standards pour créer des copies ponctuelles de volumes persistants. Pour en savoir plus sur la configuration du stockage, consultez la présentation du stockage.

Exécutez des agents de sauvegarde dans le système d'exploitation invité des machines virtuelles de l'environnement d'exécution de VM ou déployez des outils de sauvegarde natifs de l'application dans les charges de travail Kubernetes.

Systèmes d'exploitation hôtes physiques (non compatibles)

Traitez les systèmes d'exploitation Linux physiques sur les nœuds Google Distributed Cloud comme une infrastructure jetable. L'architecture réseau Kubernetes n'est pas compatible avec la restauration d'images de système d'exploitation au niveau de l'hôte. Par conséquent, Google n'est pas compatible avec l'installation d'agents de sauvegarde tiers au niveau de l'hôte directement sur le système d'exploitation hôte ni avec la restauration de nœuds physiques à partir de sauvegardes d'images au niveau du système d'exploitation ou d'instantanés de disque.

Si vous installez des agents de sauvegarde physiques tiers directement sur le système d'exploitation Linux hôte, vous pouvez introduire des risques importants.

De nombreux agents de sauvegarde installent des modules de noyau propriétaires ou des pilotes de filtre au niveau des blocs pour suivre les modifications et verrouiller les blocs de disque locaux lors des opérations d'instantané, ce qui peut entraîner les problèmes suivants :

• La base de données etcd ne peut pas être ajoutée à ses journaux d'écriture anticipée, les pulsations des nœuds expirent, le consensus Raft échoue et les clusters deviennent instables.
• Les pilotes de noyau tiers non compatibles entrent en conflit avec les routines de noyau de bas niveau et l'environnement d'exécution du conteneur, ce qui entraîne l'échec des mises à niveau du cluster.
• La restauration d'un nœud physique à partir d'une sauvegarde d'image ou d'un instantané de disque enfreint le protocole de consensus Raft. La base de données etcd n'est plus synchronisée avec les journaux des nœuds du plan de contrôle et l'état du cluster est gravement corrompu.
• Les nœuds de calcul ne sont plus synchronisés avec la source de référence du serveur d'API, les adresses IP Dataplane V2 (Cilium) entrent en conflit et le trafic est abandonné.

Pour récupérer un nœud physique qui a subi une défaillance du système d'exploitation ou du matériel, ne restaurez pas d'image de système d'exploitation. Supprimez plutôt le nœud du cluster, réinstallez un système d'exploitation de base propre, puis ajoutez à nouveau le nœud au pool de nœuds. Pour obtenir des instructions de récupération détaillées, consultez Réinitialiser un nœud défaillant.

Si vous avez besoin d'une aide supplémentaire, contactez Cloud Customer Care. Vous pouvez également consulter Obtenir de l'aide pour en savoir plus sur les ressources d'assistance, y compris en ce qui concerne les thématiques suivantes :

• Conditions requises pour ouvrir une demande d'assistance
• Outils pour vous aider à résoudre les problèmes liés à la configuration de votre environnement, les journaux et les métriques
• Composants acceptés.

Sauvegarder un cluster

La commande bmctl backup cluster regroupe les données etcd et les certificats PKI du cluster dans un fichier tar. La base de données etcd est le magasin de données central pour toutes les données de cluster. Elle contient tous les objets Kubernetes et toutes les ressources personnalisées nécessaires pour gérer l'état du cluster. Les certificats PKI s'authentifient 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 pour un déploiement à haute disponibilité (HA).

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.

Si vous avez installé l'agent de nœud sur vos clusters, le répertoire /tmp du nœud d'administrateur et de tous les nœuds cibles doit disposer de 12 Go d'espace libre. Si vous ne pouvez pas modifier la taille du répertoire /tmp pour vos nœuds cibles, consultez Modifier la capacité de stockage local pour les nœuds cibles. Si vous ne pouvez pas modifier la taille du répertoire /tmp pour le nœud d’administrateur, consultez Modifier la capacité de stockage local pour un nœud d’administrateur.

Pour sauvegarder un cluster :

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

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

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

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

Remarque : Pour améliorer les performances du cluster, Google Distributed Cloud utilise une instance etcd distincte pour stocker les objets Événement. Ces objets d'événement ont une durée de vie d'une heure. L'opération de restauration du cluster crée une instance etcd-events vide. Vous perdez donc les objets Événement existants. Toutefois, la perte d'objets Événement n'a aucune incidence sur le fonctionnement du cluster. Les Événements doivent être traités uniquement comme des données informatives, de substitution et de qualité optimale.

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 :

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

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

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

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

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

Une fois la restauration terminée, procédez comme suit pour vérifier qu'elle a réussi :

1. Exécutez les commandes suivantes pour vérifier l'état de préparation des nœuds et les pods système en cours d'exécution avec le fichier kubeconfig généré :

   Il existe deux types de pods etcd :

   • etcd-HOST_NAME, qui correspond au pod principal etcd
   • etcd-events-HOST_NAME, qui correspond au pod etcd-events

   kubectl get pods -n kube-system --kubeconfig GENERATED_KUBECONFIG
   kubectl get nodes --kubeconfig GENERATED_KUBECONFIG
   

2. Pour chaque pod etcd, exécutez la commande suivante pour vérifier l'état de santé d'etcd :

   kubectl exec ETCD_POD_NAME -n kube-system \
       --kubeconfig GENERATED_KUBECONFIG \
       -- /bin/sh -c 'ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
       --cacert=/etc/kubernetes/pki/etcd/ca.crt --key=/etc/kubernetes/pki/etcd/peer.key \
       --cert=/etc/kubernetes/pki/etcd/peer.crt endpoint health'
   

   Pour un membre etcd sain, la réponse doit se présenter comme suit :

   https://127.0.0.1:2379 is healthy: successfully committed proposal: took = 11.514177ms
   

3. Pour chaque pod etcd-events, exécutez la commande suivante pour vérifier l'état de santé d'etcd-events :

   kubectl exec ETCD_EVENTS_POD_NAME -n kube-system \
       --kubeconfig GENERATED_KUBECONFIG \
       -- /bin/sh -c 'ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2382 \
       --cacert=/etc/kubernetes/pki/etcd/ca.crt --key=/etc/kubernetes/pki/etcd/peer.key \
       --cert=/etc/kubernetes/pki/etcd/peer.crt endpoint health'
   

   Pour un membre etcd-events sain, la réponse doit se présenter comme suit :

   https://127.0.0.1:2382 is healthy: successfully committed proposal: took = 14.308148ms
   

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.

Impossible de créer une sauvegarde pour un nœud d'agent de nœud

Si vous utilisez l'agent de nœud et que vous recevez une erreur indiquant que la création de la sauvegarde n'a pas pu créer de fichier d'archive, comme suit :

  I0508 15:29:36.831790  657351 backup_cluster.go:255] Retrying backup node: 128.187.102.133, due to error: failed receive chunk data: rpc error: code = Unknown desc = archiver.CreateArchiveWithList
  failed: failed to create archive file: failed to copy data from file: var/lib/etcd-events/member/snap/db, file size: 26136576, copy bytes: 12478464,
  error: write /tmp/uploadFileTemp1561164777: no space left on device

Vérifiez que le répertoire /tmp du nœud d'administrateur et de tous les nœuds cibles dispose de 12 Go d'espace libre. Si vous ne pouvez pas modifier la taille du répertoire /tmp pour vos nœuds cibles, consultez Augmenter la capacité de stockage local pour les sauvegardes de l'agent de nœud.

Une fois que vous avez confirmé que le répertoire /tmp du nœud d'administrateur et de tous les nœuds cibles dispose de 12 Go d'espace libre, réessayez d'effectuer la sauvegarde.