Cette page explique comment utiliser bmctl
pour sauvegarder et restaurer des clusters créés avec GDCV pour Bare Metal. Ces instructions s'appliquent à tous les types de clusters compatibles
avec GKE sur une solution Bare Metal.
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.
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 involontaire des fichiers, le processus de sauvegarde de GKE sur Bare Metal 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_KUBEONFIG
Remplacez les éléments suivants :
CLUSTER_NAME
: nom du cluster que vous prévoyez de sauvegarder.ADMIN_KUBEONFIG
: chemin d'accès au fichier kubeconfig pour le 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_KUBEONFIG
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 de cluster pour GKE sur une solution Bare Metal sont le nom du cluster, précédé decluster-
. Par exemple, si vous nommez votre clustertest
, l'espace de noms porte un nom tel quecluster-test
.ADMIN_KUBEONFIG
: chemin d'accès au fichier kubeconfig pour le cluster d'administrateur.
Consultez la section
Status
dans le résultat de la commande pourConditions
de typeReconciling
.Comme le montre l'exemple suivant, l'état
False
de cesConditions
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_KUBEONFIG
Remplacez les éléments suivants :
CLUSTER_NAME
: nom du cluster à sauvegarder.ADMIN_KUBEONFIG
: 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 etTIMESTAMP
est la date et l'heure de la sauvegarde. Par exemple, si le nom du cluster esttestuser
, le fichier de sauvegarde porte un nom tel quetestuser_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 involontaire des fichiers, le processus de restauration GKE sur solution Bare Metal 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 restaurer un cluster d'utilisateur, exécutez la commande suivante:
bmctl restore cluster -c CLUSTER_NAME --backup-file BACKUP_FILE \ --kubeconfig ADMIN_KUBEONFIG
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_KUBEONFIG
: 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 avec le processus de sauvegarde ou de restauration, les sections suivantes peuvent vous aider à les résoudre.
Si vous avez besoin d'une aide supplémentaire, contactez l'assistance Google.
Mémoire insuffisante lors d'une sauvegarde ou d'une restauration
Pendant le processus de sauvegarde ou de restauration, vous pouvez recevoir des messages d'erreur qui ne sont pas très explicites ou ne sont pas clairs pour les étapes suivantes. Si le poste de travail sur lequel 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 le processus de sauvegarde ou de restauration.
GDCV pour Bare Metal version 1.13 ou ultérieure peut utiliser le paramètre --use-disk
dans la commande de sauvegarde. Pour conserver les autorisations de fichiers, ce paramètre modifie les autorisations des fichiers. Par conséquent, l'utilisateur qui exécute la commande doit ê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.
La GDCV pour Bare Metal version 1.14 et ultérieures affiche des messages d'erreur plus clairs indiquant quels répertoires 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.
Actualiser la clé SSH après qu'une sauvegarde interrompt le processus de restauration
Les opérations liées à SSH pendant le 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 rajouter temporairement la clé SSH d'origine, puis effectuer la restauration. Une fois le processus de restauration terminé, vous pouvez effectuer une rotation de la clé SSH.