Sauvegarder et restaurer des clusters

Cette page explique comment créer et restaurer manuellement des sauvegardes de clusters d'administrateur et d'utilisateur GKE On-Prem. Cette page fournit également un script que vous pouvez utiliser pour sauvegarder automatiquement vos clusters.

Nous vous conseillons de créer des sauvegardes pour la reprise en cas de sinistres prévus qui pourraient endommager les données etcd et les secrets. Assurez-vous de stocker les sauvegardes dans un emplacement hors du cluster et indépendant du fonctionnement du cluster. Pour plus de sécurité, vous pouvez également créer une copie de la sauvegarde.

Bien que le pod d'événements etcd qui s'exécute dans chaque cluster ne soit pas vital pour la restauration d'un cluster d'utilisateur, vous pouvez suivre un processus similaire pour le sauvegarder.

Restrictions

• La sauvegarde de données spécifiques à une application n'est pas prise en charge par cette fonctionnalité.
• Les secrets restent valides jusqu'à ce que vous en fassiez une rotation manuelle.
• Les charges de travail planifiées après la création d'une sauvegarde donnée ne sont pas restaurées avec cette sauvegarde.
• Actuellement, vous ne pouvez pas effectuer de restauration à partir d'échecs de mise à jour de cluster.
• Cette procédure n'a pas pour objectif de restaurer un cluster supprimé.

Problèmes connus

Lorsque vous exécutez des commandes sudo, vous pouvez rencontrer l'erreur suivante :

sudo: unable to resolve host gke-admin-master-[CLUSTER_ID]

Dans ce cas, ajoutez la ligne suivante au fichier /etc/hosts :

127.0.0.1 gke-admin-master-[CLUSTER_ID]

Sauvegardes de clusters d'utilisateur

Une sauvegarde de cluster d'utilisateur contient un instantané du magasin etcd du cluster. Le magasin etcd d'un cluster contient, entre autres, tous les objets Kubernetes et tous les objets personnalisés requis pour gérer l'état du cluster. Cet instantané contient les données requises pour recréer les composants et les charges de travail du cluster.

Sauvegarder un cluster d'utilisateur

Le magasin etcd d'un cluster d'utilisateur est stocké dans son nœud de plan de contrôle, auquel vous pouvez accéder à l'aide du fichier kubeconfig du cluster d'administrateur.

Pour créer un instantané du magasin etcd, exécutez la procédure suivante :

1. Obtenez une interface système dans le conteneur kube-etcd :

   kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] exec \
   -it -n [USER_CLUSTER_NAME] kube-etcd-0 -c \
   kube-etcd -- bin/sh

   où :

   • [ADMIN_CLUSTER_KUBECONFIG] est le fichier kubeconfig du cluster d'administrateur.
   • [USER_CLUSTER_NAME] est le nom du cluster d'utilisateur. Plus précisément, vous transmettez un espace de noms dans le cluster d'administrateur portant le nom du cluster d'utilisateur.

2. Depuis l'interface système, utilisez etcdctl pour créer une sauvegarde nommée snapshot.db dans le répertoire local :

   ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
   --cacert=/etcd.local.config/certificates/etcdCA.crt \
   --cert=/etcd.local.config/certificates/etcd.crt --key=/etcd.local.config/certificates/etcd.key \
   snapshot save snapshot.db

3. Quittez le conteneur :

   exit

4. Copiez la sauvegarde hors du conteneur kube-etcd à l'aide de kubectl cp :

   kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] cp \
   [USER_CLUSTER_NAME]/kube-etcd-0:snapshot.db [DIRECTORY] -c kube-etcd

   où [RELATIVE_DIRECTORY] est le chemin d'accès où vous souhaitez stocker votre sauvegarde.

Restaurer une sauvegarde de cluster d'utilisateur

• Avant de restaurer une sauvegarde, veillez à diagnostiquer votre cluster et à résoudre les problèmes existants. Restaurer une sauvegarde sur un cluster problématique peut recréer, voire exacerber les problèmes. Contactez l'équipe d'assistance GKE On-Prem pour obtenir de l'aide sur la restauration de vos clusters.

• Si vous avez créé un cluster d'utilisateur haute disponibilité, vous devez exécuter ces étapes une fois par membre de cluster etcd. Vous pouvez utiliser le même instantané lors de la restauration de chaque membre etcd. Ne suivez ces étapes que si tous les pods etcd subissent un plantage en boucle : cela signifie que les données sont corrompues.

Pod etcd avec plantage en boucle

Les instructions suivantes expliquent comment restaurer une sauvegarde lorsque les données etcd d'un cluster d'utilisateur sont endommagées et que leur pod etcd subit des plantages en boucle. Vous pouvez résoudre le problème en déployant un pod etcd sur les volumes du pod existant et en remplaçant les données endommagées par la sauvegarde, en supposant que le serveur d'API du cluster d'utilisateur est en cours d'exécution et puisse planifier de nouveaux pods.

1. Copiez la spécification de pod etcd ci-dessous dans un fichier restore-etcd.yaml, après avoir rempli les valeurs d'espace réservé suivantes :

   • [MEMBER_NUMBER] est le pod numéroté que vous restaurez.
   • [NODE_NAME] est le nœud sur lequel le pod [MEMBER_NUMBER[ est en cours d'exécution.
   • [ADMIN_CLUSTER_KUBECONFIG] est le fichier kubeconfig du cluster d'administrateur.
   • [USER_CLUSTER_NAME] est le nom du cluster d'utilisateur.

   • [DEFAULT_TOKEN] est utilisé pour l'authentification. Vous pouvez trouver cette valeur en exécutant la commande suivante :

     kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
     -n [USER_CLUSTER_NAME] get pods kube-etcd-0 \
     -o yaml | grep default-token

   Remarque : La valeur image ci-dessous part du principe que vous utilisez le registre gcr.io. Modifiez le nom de l'image si vous utilisez un registre privé.

   restore-etcd.yaml

   apiVersion: v1
   kind: Pod
   metadata:
     labels:
       Component: restore-etcd-[MEMBER_NUMBER]
     name: restore-etcd-0
     namespace: restore-etcd-[MEMBER_NUMBER]
   spec:
     restartPolicy: Never
     containers:
     - command: ["/bin/sh"]
       args: ["-ec", "while :; do echo '.'; sleep 5 ; done"]
       image: gcr.io/gke-on-prem-release/etcd:v3.2.24-1-gke.0
       imagePullPolicy: IfNotPresent
       name: restore-etcd
       terminationMessagePath: /dev/termination-log
       terminationMessagePolicy: File
       volumeMounts:
       - mountPath: /var/lib/etcd
         name: data
       - mountPath: /etcd.local.config/certificates
         name: etcd-certs
       - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
         name: [DEFAULT_TOKEN]
         readOnly: true
     dnsPolicy: ClusterFirst
     hostname: restore-etcd-0
     imagePullSecrets:
     - name: private-registry-creds
     nodeSelector:
       kubernetes.googleapis.com/cluster-name: [USER_CLUSTER_NAME]
       kubernetes.io.hostname: [NODE_NAME]
     priority: 0
     restartPolicy: Always
     schedulerName: default-scheduler
     securityContext: {}
     serviceAccount: default
     serviceAccountName: default
     subdomain: restore-etcd
     terminationGracePeriodSeconds: 30
     tolerations:
     - effect: NoExecute
       key: node.kubernetes.io/not-ready
       operator: Exists
       tolerationSeconds: 300
     - effect: NoExecute
       key: node.kubernetes.io/unreachable
       operator: Exists
       tolerationSeconds: 300
     volumes:
     - name: data
       persistentVolumeClaim:
         claimName: data-kube-etcd-[MEMBER_NUMBER]
     - name: etcd-certs
       secret:
         defaultMode: 420
         secretName: kube-etcd-certs
     - name: [DEFAULT_TOKEN]
       secret:
         defaultMode: 420
         secretName: [DEFAULT_TOKEN]

2. Déployez le pod :

   kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
   -n [USER_CLUSTER_NAME] create -f restore-etcd.yaml

3. Copiez le fichier de sauvegarde du magasin etcd (snapshot.db) vers le nouveau pod. snapshot.db se trouve dans le répertoire relatif où vous avez créé la sauvegarde :

   kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
   cp [RELATIVE_DIRECTORY]/snapshot.db \
   [USER_CLUSTER_NAME]/restore-etcd-0:snapshot.db

4. Obtenez une interface système dans le pod restore-etcd :

   kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
   -it -n [USER_CLUSTER_NAME] exec restore-etcd-0 -- bin/sh

5. Exécutez la commande suivante pour créer un nouveau dossier default.etcd contenant la sauvegarde :

   ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
   --cacert=/etcd.local.config/certificates/etcdCA.crt \
   --cert=/etcd.local.config/certificates/etcd.crt --key=/etcd.local.config/certificates/etcd.key \
   snapshot restore snapshot.db

6. Remplacez les données etcd endommagées par la sauvegarde :

   rm -r var/lib/etcd/*; cp -r default.etcd/* var/lib/etcd/

7. Quittez le conteneur :

   exit

8. Supprimez le pod etcd qui plante :

   kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
   -n [USER_CLUSTER_NAME] delete pod kube-etcd-0

9. Vérifiez que le pod etcd ne plante plus.

10. Supprimez restore-etcd.yaml et supprimez le pod restore-etcd :

    rm restore-etcd.yaml;
    kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
    -n [USER_CLUSTER_NAME] delete pod restore-etcd-0

Sauvegardes de clusters d'administrateur

Une sauvegarde de cluster d'administrateur contient les éléments suivants :

• Un instantané du magasin etcd du cluster d'administrateur.
• Les secrets du plan de contrôle d'administrateur, qui sont requis pour l'authentification dans les clusters d'administrateur et d'utilisateur.

Avant de créer une sauvegarde de cluster d'administrateur, procédez comme suit :

1. Recherchez l'adresse IP externe du cluster d'administrateur, qui est utilisée pour se connecter en SSH au plan de contrôle du cluster d'administrateur :

   kubectl --kubeconfig [ADMIN_KUBECONFIG] get nodes -n kube-system -o wide | grep gke-admin-master

   où [ADMIN_CLUSTER_KUBECONFIG] est le fichier kubeconfig du cluster d'administrateur.

2. Créez une clé SSH appelée vsphere_tmp à partir de la clé privée du cluster d'administrateur.

   Vous trouverez la clé privée dans les secrets du cluster d'administrateur :

   kubectl --kubeconfig [ADMIN_KUBECONFIG] get secrets sshkeys -n kube-system -o yaml

   Dans le résultat de la commande, vous trouverez la clé privée dans le champ vsphere_tmp.

   Copiez la clé privée dans vsphere_tmp :

   echo "[PRIVATE_KEY]" | base64 -d > vsphere_tmp; chmod 600 vsphere_tmp

3. Vérifiez que vous pouvez obtenir une interface système dans le plan de contrôle administrateur à l'aide de cette clé privée :

   ssh -i vsphere_tmp ubuntu@[EXTERNAL_IP]

4. Quittez le conteneur :

   exit

Sauvegarder un cluster d'administrateur

Vous pouvez sauvegarder le magasin etcd et les secrets du plan de contrôle du cluster d'administrateur.

etcd

Pour sauvegarder le magasin etcd du cluster d'administrateur :

1. Obtenez le nom du pod etcd :

   kubectl --kubeconfig [ADMIN_KUBECONFIG] get pods \
   -n kube-system | grep etcd-gke-admin-master

2. Obtenez une interface système dans le conteneur kube-etcd du pod :

   kubectl --kubeconfig [ADMIN_KUBECONFIG]  exec -it \
   -n kube-system [ADMIN_ETCD_POD] -- bin/sh

   où [ADMIN_ETCD_POD] est le nom du pod etcd.

3. Depuis l'interface système, utilisez etcdctl pour créer une sauvegarde nommée snapshot.db dans le répertoire local :

   ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt \
   --cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt \
   --key=/etc/kubernetes/pki/etcd/healthcheck-client.key snapshot save snapshot.db

4. Quittez le conteneur :

   exit

5. Copiez la sauvegarde hors du conteneur kube-etcd à l'aide de kubectl cp :

   kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] cp \
   kube-system/[ADMIN_ETCD_POD]:snapshot.db [RELATIVE_DIRECTORY]

   où [RELATIVE_DIRECTORY] est le chemin d'accès où vous souhaitez stocker votre sauvegarde.

Secrets

Pour sauvegarder les secrets du plan de contrôle administrateur :

1. Obtenez une interface système dans le nœud du plan de contrôle administrateur :

   ssh -i vsphere_tmp ubuntu@[EXTERNAL_IP]

   où [EXTERNAL_IP] est l'adresse IP externe du plan de contrôle administrateur, que vous avez collectée précédemment.

2. Créez un répertoire de sauvegarde local. Cette phase est facultative, mais vivement recommandée. Vous devez modifier les autorisations des secrets de sauvegarde pour les copier hors du nœud) :

   mkdir backup

3. Copiez localement les secrets vers le répertoire de sauvegarde local :

   sudo cp -r /etc/kubernetes/pki/* backup/

4. Modifiez les autorisations des secrets de sauvegarde :

   sudo chmod -R +rw backup/

5. Quittez le conteneur :

   exit

6. Exécutez scp pour copier le dossier de sauvegarde hors du nœud de plan de contrôle administrateur :

   sudo scp -r -i vsphere_tmp  ubuntu@[EXTERNAL_IP]:backup/ [RELATIVE_DIRECTORY]

   où [RELATIVE_DIRECTORY] est le chemin d'accès où vous souhaitez stocker votre sauvegarde.

Restaurer un cluster d'administrateur

La procédure suivante recrée un cluster d'administrateur sauvegardé et tous les plans de contrôle utilisateur qu'il gérait au moment de la création de son instantané etcd.

Remarque : Le cluster d'utilisateur peut encore continuer à exécuter ses charges de travail même si le plan de contrôle utilisateur est hors service. Toutefois, si un plan de contrôle utilisateur est hors service, il ne peut pas planifier de charges de travail nouvelles ou mises à jour ou gérer d'autres défaillances de cluster.

1. Exécutez scp pour copier snapshot.db dans le plan de contrôle administrateur :

   sudo scp -i vsphere_tmp snapshot.db ubuntu@[EXTERNAL_IP]:

   où [EXTERNAL_IP] est l'adresse IP externe du plan de contrôle administrateur, que vous avez collectée précédemment.

2. Obtenez une interface système dans le plan de contrôle administrateur :

   sudo ssh -i vsphere_tmp ubuntu@[EXTERNAL_IP]

3. Copiez snapshot.db/ vers /mnt :

   sudo cp snapshot.db /mnt/

4. Créez un répertoire temporaire, tel que backup :

   Remarque : Vous n'avez pas besoin de le faire s'il existe déjà un dossier de sauvegarde contenant les secrets.

   mkdir backup

5. Quittez le plan de contrôle administrateur :

   exit

6. Copiez les certificats dans backup/ :

   sudo scp -r -i vsphere_tmp [BACKUP_CERT_FILE] ubuntu@[EXTERNAL_IP]:backup/

7. Obtenez une interface système dans le nœud du plan de contrôle administrateur :

   ssh -i vsphere_tmp ubuntu@[EXTERNAL_IP]

   où [EXTERNAL_IP] est l'adresse IP externe du plan de contrôle administrateur, que vous avez collectée précédemment.

8. Exécutez kubeadm reset. Cela interrompt tout ce qui est en cours d'exécution dans le cluster d'administrateur, supprime toutes les données etcd, ainsi que les secrets dans /etc/kubernetes/pki/ :

   sudo kubeadm reset --ignore-preflight-errors=all

9. Copiez les secrets de sauvegarde dans /etc/kubernetes/pki/ :

   sudo cp -r backup/* /etc/kubernetes/pki/

10. Exécutez etcdctl restore avec Docker :

    sudo docker run --rm \
    -v '/mnt:/backup' \
    -v '/var/lib/etcd:/var/lib/etcd' --env ETCDCTL_API=3 'k8s.gcr.io/etcd-amd64:3.1.12' /bin/sh -c "etcdctl snapshot restore '/backup/snapshot.db'; mv /default.etcd/member/ /var/lib/etcd/"

11. Exécutez kubeadm init. Cette opération réutilise tous les secrets de sauvegarde et redémarre etcd avec l'instantané restauré :

    sudo kubeadm init --config /etc/kubernetes/kubeadm_config.yaml --ignore-preflight-errors=DirAvailable--var-lib-etcd

12. Quittez le plan de contrôle administrateur :

    exit

13. Copiez le fichier kubeconfig nouvellement généré hors du nœud administrateur :

    sudo scp -i vsphere_tmp ubuntu@[EXTERNAL_IP]:[HOME]/.kube/config kubeconfig

    où :

    • [EXTERNAL_IP] est l'adresse IP externe du plan de contrôle administrateur ;
    • [HOME] est le répertoire d'accueil du nœud d'administrateur.

    Vous pouvez maintenant utiliser ce nouveau fichier kubeconfig pour accéder au cluster restauré.

Script de sauvegarde

Vous pouvez utiliser le script fourni ici pour sauvegarder automatiquement vos clusters. Avant d'exécuter le script, renseignez les valeurs des cinq variables figurant au début du script.

Définissez USER_CLUSTER_NAMESPACE sur le nom de votre cluster d'utilisateur. Le nom de votre cluster d'utilisateur est un espace de noms du cluster d'administrateur.

Définissez EXTERNAL_IP sur l'adresse IP virtuelle que vous avez réservée pour le service de plan de contrôle administrateur.

Définissez SSH_PRIVATE_KEY sur le chemin d'accès de la clé SSH que vous avez créée lors de la configuration de votre poste de travail administrateur.

#!/usr/bin/env bash

# Automates manual steps for taking backups of user and admin clusters.
# Fill in the variables below before running the script.

BACKUP_DIR=""                       # path to store user and admin cluster backups
ADMIN_CLUSTER_KUBECONFIG=""         # path to admin cluster kubeconfig
USER_CLUSTER_NAMESPACE=""           # user cluster namespace
EXTERNAL_IP=""                      # admin control plane node external ip - follow steps in documentation
SSH_PRIVATE_KEY=""                  # path to vsphere ssh private key - follow steps in documentation

mkdir -p $BACKUP_DIR
mkdir $BACKUP_DIR/pki

# USER CLUSTER BACKUP

# Snapshot user cluster etcd
kubectl --kubeconfig=${ADMIN_CLUSTER_KUBECONFIG}  exec -it -n ${USER_CLUSTER_NAMESPACE} kube-etcd-0 -c kube-etcd -- /bin/sh -ec "export ETCDCTL_API=3; etcdctl --endpoints=https://127.0.0.1:2379 --cacert=/etcd.local.config/certificates/etcdCA.crt --cert=/etcd.local.config/certificates/etcd.crt --key=/etcd.local.config/certificates/etcd.key snapshot save ${USER_CLUSTER_NAMESPACE}_snapshot.db"
kubectl --kubeconfig=${ADMIN_CLUSTER_KUBECONFIG} cp ${USER_CLUSTER_NAMESPACE}/kube-etcd-0:user_snapshot.db $BACKUP_DIR/

# ADMIN CLUSTER BACKUP

# Copy admin certs
ssh -o StrictHostKeyChecking=no -i vsphere_tmp ubuntu@${EXTERNAL_IP} 'sudo chmod -R +rw /etc/kubernetes/pki/*'
scp -o StrictHostKeyChecking=no -r -i vsphere_tmp ubuntu@${EXTERNAL_IP}:/etc/kubernetes/pki/* ${BACKUP_DIR}/pki/

# Snapshot admin cluster etcd
admin_etcd=$(kubectl --kubeconfig=${ADMIN_CLUSTER_KUBECONFIG} get pods -n kube-system -o=name | grep etcd | cut -c 5-)
kubectl --kubeconfig=${ADMIN_CLUSTER_KUBECONFIG}  exec -it -n kube-system ${admin_etcd} -- /bin/sh -ec "export ETCDCTL_API=3; etcdctl --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt --key=/etc/kubernetes/pki/etcd/healthcheck-client.key snapshot save admin_snapshot.db"

Dépannage

Pour en savoir plus, consultez la section Dépannage.

Diagnostiquer des problèmes de cluster à l'aide de gkectl

Utilisez les commandes gkectl diagnose pour identifier les problèmes de cluster et partager des informations de cluster avec Google. Consultez la page Diagnostiquer les problèmes de cluster.

Comportement de journalisation par défaut

Pour gkectl et gkeadm, l'utilisation des paramètres de journalisation par défaut est suffisante :

• Par défaut, les entrées de journal sont enregistrées comme suit :

  • Pour gkectl, le fichier journal par défaut est /home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log, et le fichier est lié symboliquement au fichier logs/gkectl-$(date).log dans le répertoire local où vous exécutez gkectl.
  • Pour gkeadm, le fichier journal par défaut est logs/gkeadm-$(date).log dans le répertoire local où vous exécutez gkeadm.
• Toutes les entrées de journal sont enregistrées dans le fichier journal, même si elles ne sont pas affichées sur le terminal (lorsque --alsologtostderr a la valeur false).
• Le niveau de verbosité -v5 (par défaut) couvre toutes les entrées de journal requises par l'équipe d'assistance.
• Le fichier journal contient également la commande exécutée et le message d'échec.

Nous vous recommandons d'envoyer le fichier journal à l'équipe d'assistance lorsque vous avez besoin d'aide.

Spécifier un emplacement autre que celui par défaut pour le fichier journal

Pour spécifier un emplacement autre que celui par défaut pour le fichier journal gkectl, utilisez l'option --log_file. Le fichier journal que vous spécifiez ne sera pas lié symboliquement au répertoire local.

Pour spécifier un emplacement autre que celui par défaut pour le fichier journal gkeadm, utilisez l'option --log_file.

Localiser des journaux de l'API Cluster dans le cluster d'administrateur

Si une VM ne démarre pas après le démarrage du plan de contrôle d'administrateur, vous pouvez essayer de la déboguer en inspectant les journaux des contrôleurs de l'API Cluster dans le cluster d'administrateur :

1. Recherchez le nom du pod des contrôleurs d'API Cluster dans l'espace de noms kube-system, où [ADMIN_CLUSTER_KUBECONFIG] est le chemin d'accès au fichier kubeconfig du cluster d'administrateur :

   kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system get pods | grep clusterapi-controllers

2. Ouvrez les journaux du pod, où [POD_NAME] correspond au nom du pod. Vous pouvez éventuellement utiliser grep ou un outil similaire pour rechercher les erreurs :

   kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system logs [POD_NAME] vsphere-controller-manager

Étapes suivantes

• Découvrez comment diagnostiquer les problèmes de cluster.
• Découvrez augur, un outil Open Source permettant de restaurer des objets individuels à partir de sauvegardes etcd.