Sauvegarder et restaurer des clusters avancés avec gkectl

Ce document explique comment sauvegarder et restaurer les clusters d'administrateur et d'utilisateur Google Distributed Cloud version 1.32 et ultérieures pour lesquels l'option de cluster avancé est activée. La fonctionnalité de sauvegarde et de restauration est en preview dans la version 1.32 et en disponibilité générale dans la version 1.33 et ultérieures.

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.

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

Sauvegarder un cluster

La commande gkectl 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 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 (Transport Layer Security). 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é (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 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.

Avant de commencer, 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.

Pour sauvegarder un cluster :

1. Exécutez la commande suivante pour vérifier votre cluster :

   gkectl diagnose cluster --cluster-name CLUSTER_NAME \
       --kubeconfig ADMIN_KUBECONFIG
   

   Remplacez les éléments suivants :

   • CLUSTER_NAME : nom du cluster que vous prévoyez de sauvegarder.

   • ADMIN_KUBECONFIG : chemin du fichier kubeconfig du cluster d'administrateur.

2. Exécutez la commande applicable pour sauvegarder le cluster :

   Cluster d'administrateur

   gkectl backup admin --kubeconfig ADMIN_KUBECONFIG
   

   Cluster d'utilisateur

   gkectl backup cluster --cluster-name CLUSTER_NAME \
       --kubeconfig ADMIN_KUBECONFIG
   

Par défaut, le fichier tar de sauvegarde est enregistré dans le répertoire gkectl-workspace/backups 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_2025-08-23T150405Z0700.tar.gz.

Vous pouvez éventuellement spécifier un nom et un emplacement différents pour votre fichier de sauvegarde avec l'option --backup-file, par exemple :

gkectl backup cluster testuser \
    --kubeconfig admin-cluster/kubeconfig \
    --backup-file cluster-backups/testuser-backup-aug-23-2025.tar.gz

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.

Sauvegarder sur vSphere

Pour configurer les sauvegardes de sorte que le fichier de sauvegarde des clusters d'administrateur et d'utilisateur soit importé dans vSphere en plus d'être enregistré sur votre poste de travail administrateur, procédez comme suit :

1. Ajoutez le champ clusterBackup.datastore au fichier de configuration de votre cluster d'administrateur :

   clusterBackup:
       datastore: DATASTORE
   

   Remplacez DATASTORE par le datastore dans lequel vous souhaitez stocker la sauvegarde. Le datastore doit se trouver dans le même centre de données que le cluster d'administrateur. Les sauvegardes se trouvent dans le répertoire anthos/CLUSTER_NAME/backup du datastore spécifié.

2. Mettez à jour le cluster d'administrateur :

   gkectl update admin --kubeconfig ADMIN_KUBECONFIG \
       --config ADMIN_CONFIG
   

   Remplacez les éléments suivants :

   • ADMIN_KUBECONFIG : chemin du fichier kubeconfig du cluster d'administrateur.

   • ADMIN_CONFIG : chemin d'accès au fichier de configuration du cluster d'administrateur

Par défaut, la commande gkectl backup enregistre les trois fichiers de sauvegarde les plus récents dans vSphere et supprime les fichiers de sauvegarde plus anciens. Si vous souhaitez conserver les anciens fichiers de sauvegarde, ajoutez l'indicateur --keep-all-backups, disponible dans la version 1.32.100 et ultérieures.

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.

N'utilisez la commande gkectl restore que si les trois nœuds du plan de contrôle ont échoué.

• Si un seul nœud a échoué et que autoRepair.enabled est défini sur true dans le fichier de configuration du cluster d'administrateur, le nœud défaillant est automatiquement réparé. Si autoRepair.enabled n'est pas configuré, ajoutez-le au fichier de configuration du cluster d'administrateur et exécutez gkectl update admin. Une fois la mise à jour effectuée, le nœud est automatiquement recréé.

• Si deux nœuds du plan de contrôle ont échoué, consultez la section Rétablir le quorum sur cette page.

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 valeur TTL (Time To Live);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.

Avant de restaurer un cluster, assurez-vous que les conditions suivantes sont remplies :

• Toutes les machines de nœud du plan de contrôle qui étaient disponibles pour le cluster au moment de la sauvegarde fonctionnent correctement et sont accessibles.
• 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.
• 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, procédez comme suit :

1. Exécutez la commande applicable pour restaurer le cluster :

   Cluster d'administrateur

   gkectl restore admin --backup-file BACKUP_FILE \
       --config ADMIN_CONFIG
   

   Remplacez les éléments suivants :

   • BACKUP_FILE : chemin d'accès et nom du fichier de sauvegarde que vous utilisez.

   • ADMIN_CONFIG : chemin d'accès au fichier de configuration du cluster d'administrateur.

   Cluster d'utilisateur

   gkectl restore cluster --cluster-name 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é dans le répertoire de l'espace de travail gkectl-workspace.

2. Une fois la restauration terminée, exécutez la commande suivante pour vérifier qu'elle a réussi :

   gkectl diagnose cluster --cluster-name CLUSTER_NAME \
       --kubeconfig GENERATED_KUBECONFIG
   

   Remplacez GENERATED_KUBECONFIG par le fichier kubeconfig généré.

Restaurer le quorum

Lorsqu'un cluster comporte deux nœuds de plan de contrôle défaillants, vous pouvez utiliser la commande gkectl restore pour rétablir le quorum. Lorsque vous restaurez le quorum, au lieu de spécifier le fichier de sauvegarde dans la commande gkectl restore, vous spécifiez l'adresse IP du nœud de plan de contrôle fonctionnel.

Avant d'exécuter la commande, assurez-vous que les conditions suivantes sont remplies :

• Un seul nœud de plan de contrôle fonctionne.
• Le nœud du plan de contrôle fonctionnel est accessible avec la clé SSH. Pour en savoir plus, consultez Se connecter à un nœud de cluster via SSH.

Pour rétablir le quorum, exécutez la commande applicable à votre type de cluster :

Cluster d'administrateur

gkectl restore admin --kubeconfig ADMIN_KUBECONFIG \
    --config ADMIN_CONFIG \
    --control-plane-node WORKING_NODE_IP \
    --ssh-key ADMIN_SSH_KEY_PATH

Remplacez les éléments suivants :

• ADMIN_KUBECONFIG : chemin du fichier kubeconfig du cluster d'administrateur.

• ADMIN_CONFIG : chemin d'accès au fichier de configuration du cluster d'administrateur

• WORKING_NODE_IP : adresse IP du nœud de plan de contrôle fonctionnel.

• ADMIN_SSH_KEY_PATH : chemin d'accès à la clé SSH du cluster d'administrateur.

Cluster d'utilisateur

gkectl restore cluster --cluster-name CLUSTER_NAME \
    --kubeconfig ADMIN_KUBECONFIG \
    --control-plane-node WORKING_NODE_IP \
    --ssh-key USER_SSH_KEY_PATH

Remplacez les éléments suivants :

• CLUSTER_NAME : nom du cluster à restaurer.

• ADMIN_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur.

• WORKING_NODE_IP : adresse IP du nœud de plan de contrôle fonctionnel.

• USER_SSH_KEY_PATH : chemin d'accès à la clé SSH du cluster d'utilisateur.

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'équipe Cloud Customer Care.

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

Si la station de travail sur laquelle vous exécutez la commande gkectl 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. Si nécessaire, créez et utilisez un disque de travail temporaire pour traiter les opérations de sauvegarde ou de restauration à l'aide du paramètre --use-disk dans la commande de sauvegarde. Pour conserver les autorisations des fichiers, ce paramètre modifie les autorisations des fichiers. Vous devez donc exécuter la commande en tant qu'utilisateur racine (ou utiliser sudo).

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.