Sauvegarder et restaurer un cluster d'utilisateur

Version 1.16 

• Dernière version
• Version 1.16
• Versions antérieures (non compatibles)

Ce document explique comment sauvegarder et restaurer le magasin etcd pour un cluster d'utilisateur. Elle fournit également un script que vous pouvez utiliser pour sauvegarder automatiquement le magasin etcd d'un cluster.

Vous pouvez créer un fichier de sauvegarde pour la reprise en cas de sinistre imprévu susceptible d'endommager les données etcd de votre cluster. Stockez le fichier de sauvegarde dans un emplacement hors du cluster et indépendant du fonctionnement du cluster.

Avertissement : L'utilisation d'un fichier de sauvegarde pour restaurer vos données etcd est un dernier recours. Nous vous déconseillons d'effectuer une restauration à partir d'un fichier de sauvegarde, sauf si le cluster est complètement endommagé. Contactez l'assistance Google si vous avez besoin d'aide pour choisir la meilleure solution.

Limites

• Cette procédure ne sauvegarde pas les données spécifiques à l'application.

• Cette procédure ne sauvegarde pas vos objets PersistentVolume.

• Les charges de travail planifiées après la création d'une sauvegarde donnée ne sont pas restaurées avec cette sauvegarde.

• Vous ne pouvez pas restaurer un cluster après une mise à niveau échouée.

• Cette procédure n'a pas pour objectif de restaurer un cluster supprimé.

Sauvegarder un cluster d'utilisateur

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

La procédure de sauvegarde à suivre varie selon que le plan de contrôle V2 est activé ou non sur le cluster d'utilisateur. Lorsque le plan de contrôle V2 est activé, le plan de contrôle du cluster d'utilisateur s'exécute sur le cluster d'utilisateur lui-même. Lorsque le plan de contrôle V2 n'est pas activé, le plan de contrôle du cluster d'utilisateur s'exécute sur un ou plusieurs nœuds du cluster d'administrateur, appelé "kubeception".

Exécutez la commande suivante pour déterminer si le plan de contrôle V2 est activé sur le cluster:

kubectl get onpremuserclusters --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system -o jsonpath='{.items[0].spec.enableControlplaneV2}' && echo

Si la sortie est true, suivez les étapes du plan de contrôle V2 pour sauvegarder le cluster. Sinon, suivez les étapes de Kubeception. Les étapes de sauvegarde sont les mêmes, à l'exception de l'emplacement des clés, des certificats et du nom du pod etcd.

kubeception

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

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

   où :

   • ADMIN_CLUSTER_KUBECONFIG est le fichier kubeconfig du cluster d'administrateur.
   • USER_CLUSTER_NAME est le nom du cluster d'utilisateur.

2. Dans votre shell, dans le répertoire /tmp, créez une sauvegarde nommée snapshot.db:

   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 /tmp/snapshot.db
   

3. Dans votre interface système, saisissez exit pour quitter l'interface système.

4. Copiez /tmp/snapshot.db du conteneur kube-etcd vers le répertoire actuel :

   kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG cp \
     USER_CLUSTER_NAME/kube-etcd-0:/tmp/snapshot.db \
     --container kube-etcd snapshot.db
   

Plan de contrôle V2

1. Obtenez le nom du pod etcd :

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pods \
    -n kube-system -l component=etcd,tier=control-plane -ojsonpath='{$.items[*].metadata.name}{"\n"}'
   

   où :

   • USER_CLUSTER_KUBECONFIG est le fichier kubeconfig du cluster d'utilisateur.

   Exemple :

   NAME           READY   STATUS    RESTARTS   AGE
   etcd-uc1-cp1   1/1     Running   0          38m
   etcd-uc1-cp2   1/1     Running   0          37m
   etcd-uc1-cp3   1/1     Running   0          38m
   

   Notez qu'il peut y avoir plusieurs pods etcd (trois pour les clusters à haute disponibilité, par exemple). Pour la sauvegarde, n'importe quel pod etcd devrait fonctionner.

2. Obtenez une interface système dans le conteneur etcd :

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG exec -it \
    POD_NAME -c etcd -n kube-system -- /bin/sh
   
   

   où :

   • POD_NAME est le nom du pod etcd issu de l'étape précédente.

3. Dans votre shell, créez un fichier de sauvegarde nommé snapshot.db:

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

4. Dans votre interface système, saisissez exit pour quitter l'interface système.

5. Copiez snapshot.db du conteneur etcd dans le répertoire d'accueil de la station de travail:

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    cp POD_NAME:/tmp/snapshot.db ~/snapshot.db \
    -c etcd -n kube-system
   

6. Copiez les secrets à partir du répertoire PKI:

   ssh -i NODE_NAME.key ubuntu@NODE_EXTERNAL_IP
   sudo chmod -R 0644 /etc/kubernetes/pki/*
   sudo chmod 0755 /etc/kubernetes/pki/etcd
   exit
   scp -ri NODE_NAME.key ubuntu@NODE_EXTERNAL_IP:/etc/kubernetes/pki ~/pki_NODE_NAME
   

   où :

   • NODE_NAME est le fichier contenant la clé SSH pour le nœud de plan de contrôle ;
   • NODE_EXTERNAL_IP est l'adresse IP du nœud de plan de contrôle d'utilisateur à partir duquel vous souhaitez copier les secrets.

Restaurer un cluster d'utilisateur à partir d'une sauvegarde (standard)

Avant d'utiliser un fichier de sauvegarde pour restaurer le magasin etcd de votre cluster d'utilisateur, diagnostiquez votre cluster et résolvez les problèmes existants. Utiliser une sauvegarde pour restaurer un cluster problématique peut recréer, voire exacerber les problèmes. Contactez l'équipe d'assistance GKE sur VMware pour obtenir de l'aide concernant la restauration de vos clusters.

Les instructions suivantes expliquent comment utiliser un fichier de sauvegarde pour restaurer un cluster d'utilisateur si les données etcd du cluster sont endommagées et que le pod etcd du cluster d'utilisateur tourne en boucle.

kubeception

Vous pouvez restaurer les données etcd en déployant un pod utilitaire qui écrase les données endommagées avec la sauvegarde. Le serveur d'API du cluster d'administrateur doit être en cours d'exécution et le planificateur du cluster doit pouvoir planifier de nouveaux pods.

1. Recherchez le nom du secret utilisé par etcd dans le cluster d'utilisateur :

   kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME \
      get secrets | grep kube-etcd-certs
   

2. Copiez le fichier manifeste de pod suivant dans un fichier nommé etcd-utility.yaml. Remplacez les éléments suivants :

   • NODE_NAME : nœud sur lequel le pod kube-etcd-0 est exécuté.

   • ADMIN_CLUSTER_KUBECONFIG : fichier kubeconfig du cluster d'administrateur.

   • USER_CLUSTER_NAME : nom du cluster d'utilisateur.

   • GKE_ON_PREM_VERSION : version du cluster dans lequel vous souhaitez effectuer la restauration etcd (par exemple 1.5.0-gke.0).

   • KUBE_ETCD_SECRET_NAME : nom du secret utilisé par etcd dans le cluster d'utilisateur, commençant par kube-etcd-certs.

   apiVersion: v1
   kind: Pod
   metadata:
    name: etcd-utility-0
    namespace: USER_CLUSTER_NAME
   spec:
    containers:
    - command: ["/bin/sh"]
      args: ["-ec", "while :; do echo '.'; sleep 5 ; done"]
      image: gcr.io/gke-on-prem-release/etcd-util:GKE_ON_PREM_VERSION
      name: etcd-utility
      volumeMounts:
      - mountPath: /var/lib/etcd
        name: data
      - mountPath: /etcd.local.config/certificates
        name: etcd-certs
    nodeSelector:
      kubernetes.googleapis.com/cluster-name: USER_CLUSTER_NAME
      kubernetes.io/hostname: NODE_NAME
    tolerations:
    - effect: NoExecute
      key: node.kubernetes.io/not-ready
      operator: Exists
      tolerationSeconds: 300
    - effect: NoExecute
      key: node.kubernetes.io/unreachable
      operator: Exists
      tolerationSeconds: 300
    - effect: NoSchedule
      key: node.kubernetes.io/unschedulable
      operator: Exists
    volumes:
    - name: data
      persistentVolumeClaim:
        claimName: data-kube-etcd-0
    - name: etcd-certs
      secret:
        defaultMode: 420
        secretName: KUBE_ETCD_SECRET_NAME
   

3. Déployez le pod utilitaire :

   kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
     create -f etcd-utility.yaml --namespace USER_CLUSTER_NAME
   

4. Copiez snapshot.db du répertoire actuel vers le répertoire racine du pod utilitaire :

   kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG cp snapshot.db \
     USER_CLUSTER_NAME/etcd-utility-0:snapshot.db --container etcd-utility
   

5. Obtenez une interface système dans le conteneur etcd-utility :

   kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG exec it \
     etcd-utility-0 --container etcd-utility --namespace USER_CLUSTER_NAME \
     -- bin/sh
   

6. Dans votre interface système, dans le répertoire racine, exécutez la commande suivante pour créer un dossier 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
   

7. Dans votre interface système, supprimez les anciennes données etcd :

   rm -r var/lib/etcd/*
   

8. Dans votre interface système, copiez les données etcd restaurées vers leur emplacement permanent :

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

9. Dans votre interface système, saisissez exit pour quitter l'interface système.

10. Supprimez le pod etcd qui plante :

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
      delete pod kube-etcd-0 --namespace USER_CLUSTER_NAME
    

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

12. Supprimez le pod utilitaire :

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
      delete pod etcd-utility-0 --namespace USER_CLUSTER_NAME

13. Supprimez etcd-utility.yaml du répertoire actuel :

    rm etcd-utility.yaml
    

Plan de contrôle V2

Vous pouvez restaurer les données etcd une par une en déployant un conteneur etcd temporaire qui écrase les données endommagées avec la sauvegarde.

1. Ouvrez une interface système dans le nœud du plan de contrôle de l'utilisateur:

   ssh -i NODE_NAME.key ubuntu@NODE_EXTERNAL_IP
   

2. Dans le shell, arrêtez le serveur d'API Kubernetes et le serveur etcd:

   sudo mv /etc/kubernetes/manifests/kube-apiserver.yaml /etc/kubernetes/manifests/etcd.yaml ~
   

3. Dans le shell, saisissez exit pour le quitter.

4. Exécutez scp pour copier le fichier de sauvegarde snapshot.db et les secrets sur le nœud du plan de contrôle de l'utilisateur:

   scp -i NODE_NAME.key ~/snapshot.db ubuntu@NODE_EXTERNAL_IP:/tmp/
   

   chmod a+rw pki/
   scp -ri NODE_NAME.key ~/pki_NODE_NAME ubuntu@NODE_EXTERNAL_IP:/etc/kubernetes/pki
   

5. Dans le shell, utilisez snapshot.db pour restaurer les données etcd:

   sudo docker run --rm -t \
   -v /opt/data/var/lib:/var/lib \
   -v /etc/kubernetes/pki/etcd:/etc/kubernetes/pki/etcd \
   -v /tmp:/tmp \
   --env ETCDCTL_API=3 \
   gcr.io/gke-on-prem-release/etcd-util:GKE_ON_PREM_VERSION etcdctl \
   --cacert=/etc/kubernetes/pki/etcd/ca.crt \
   --cert=/etc/kubernetes/pki/etcd/server.crt \
   --key=/etc/kubernetes/pki/etcd/server.key \
   --data-dir=/opt/data/var/lib/etcd \
   --name=NODE_NAME \
   --initial-advertise-peer-urls=https://NODE_IP_ADDRESS:2380 \
   --initial-cluster=NODE_NAME=https://NODE_IP_ADDRESS:2380 \
   snapshot restore /tmp/snapshot.db
   

   où :

   • GKE_ON_PREM_VERSION est la version de GKE Enterprise utilisée comme tag d'image.
   • NODE_NAME est le nom du nœud sur lequel la restauration est effectuée.
   • NODE_IP_ADDRESS est l'adresse IP de ce nœud.

6. Ajoutez l'indicateur - --initial-cluster-state=new dans le fichier manifeste etcd sous la commande du conteneur.

   Exemple :

   containers:
         - command:
           - etcd
           ...
           - --initial-cluster-state=new
           ...

7. Dans le shell, démarrez les serveurs kube-apiserver et etcd:

   sudo ~/mv etcd.yaml ~/kube-apiserver.yaml /etc/kubernetes/manifests/
   

8. Dans le shell, saisissez exit pour le quitter.

Remarque :Si les pods events-etcd sont à l'état CrashLoopBackOff, ajoutez l'indicateur - --initial-cluster-state=new et redémarrez les pods. Les événements ne seront pas synchronisés et vous perdrez ceux stockés précédemment.

Restaurer un cluster d'utilisateur à partir d'une sauvegarde (haute disponibilité)

kubeception

Cette section explique comment restaurer les données etcd pour un cluster d'utilisateur haute disponibilité.

Pour un cluster d'utilisateur haute disponibilité, trois nœuds du cluster d'administrateur servent de plans de contrôle pour le cluster d'utilisateur. Chacun de ces nœuds exécute un pod etcd qui gère les données etcd sur un volume de stockage.

Si deux des pods etcd sont opérationnels et que les données sur les volumes de stockage associés sont intactes, il n'est pas nécessaire d'utiliser un fichier de sauvegarde. En effet, vous aurez toujours un quorum etcd.

Dans les rares cas où deux des volumes de stockage etcd contiennent des données corrompues, vous devez utiliser un fichier de sauvegarde pour les restaurer.

Pour effectuer les étapes de cette section, vous devez déjà avoir créé un fichier snapshot.db, comme décrit dans la section Sauvegarder un cluster d'utilisateur.

Répertorier les pods etcd et les nœuds

1. Répertoriez les pods etcd qui gèrent le magasin etcd pour votre cluster d'utilisateur. Ces pods s'exécutent dans le cluster d'administrateur :

   kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get pods --namespace USER_CLUSTER_NAME \
   --output wide | grep kube-etcd
   

   Le résultat affiche les pods etcd et les nœuds sur lesquels ils s'exécutent. Les nœuds affichés dans le résultat sont des nœuds du cluster d'administrateur servant de plans de contrôle pour votre cluster d'utilisateur :

   NAME              ...   NODE
   kube-etcd-0       ...   xxx
   kube-etcd-1       ...   yyy
   kube-etcd-2       ...   zzz
   

2. Notez les noms des pods et des nœuds du plan de contrôle pour les utiliser plus tard.

   Notez que chaque pod etcd est nommé kube-etcd et est accompagné d'un numéro. Ce numéro est appelé numéro de membre du pod. Il identifie le pod comme étant un membre particulier du cluster etcd qui contient les données d'objet de votre cluster d'utilisateur. Ce guide utilise l'espace réservé MEMBER_NUMBER pour faire référence au numéro de membre du pod etcd.

   Notez également que chaque pod de votre cluster etcd s'exécute sur son propre nœud.

Préparer le déploiement des pods utilitaires

1. Enregistrez un fichier manifeste pour le PodDisruptionBudget (PDB) du serveur d'API Kubernetes du cluster d'utilisateur. Supprimez ensuite le PDB.

   kubectl --kubeconfig ADMIN_CLUSTER_KUBECONIFG get pdb --namespace USER_CLUSTER_NAME \
   kube-apiserver-pdb --output yaml > kube-apiserver-pdb.yaml
   
   kubectl --kubeconfig ADMIN_CLUSTER_KUBECONIFG delete pdb --namespace USER_CLUSTER_NAME \
   kube-apiserver-pdb
   

2. Arrêtez le serveur d'API Kubernetes et le déploiement de maintenance etcd. Cela garantit qu'aucun composant n'utilisera etcd lors de la restauration :

   kubectl --kubeconfig ADMIN_CLUSTER_KUBECONIFG --namespace USER_CLUSTER_NAME \
   scale --replicas 0 statefulset kube-apiserver
   
   kubectl --kubeconfig ADMIN_CLUSTER_KUBECONIFG --namespace USER_CLUSTER_NAME \
   scale --replicas 0 deployment gke-master-etcd-maintenance
   

3. Rappelez le nom de l'image de conteneur pour vos pods etcd.

Déployer les pods de l'utilitaire

Important :Procédez comme indiqué dans cette section pour chacun de vos pods etcd.

1. Rappelez le nom du pod etcd et le nom du nœud sur lequel le pod s'exécute.

2. Enregistrez le fichier manifeste de pod suivant dans le répertoire actuel dans un fichier nommé etcd-utility-MEMBER_NUMBER.yaml :

 apiVersion: v1
 kind: Pod
 metadata:
   name: etcd-utility-MEMBER_NUMBER
   namespace: USER_CLUSTER_NAME
 spec:
   containers:
   - command: ["/bin/sh"]
     args: ["-ec", "while :; do echo '.'; sleep 5 ; done"]
     image: gcr.io/gke-on-prem-release/etcd-util:GKE_ON_PREM_VERSION
     name: etcd-utility
     volumeMounts:
     - mountPath: /var/lib/etcd
       name: data
     - mountPath: /etcd.local.config/certificates
       name: etcd-certs
   nodeSelector:
     kubernetes.googleapis.com/cluster-name: USER_CLUSTER_NAME
     kubernetes.io/hostname: NODE_NAME
   tolerations:
   - effect: NoExecute
     key: node.kubernetes.io/not-ready
     operator: Exists
     tolerationSeconds: 300
   - effect: NoExecute
     key: node.kubernetes.io/unreachable
     operator: Exists
     tolerationSeconds: 300
   - effect: NoSchedule
     key: node.kubernetes.io/unschedulable
     operator: Exists
   volumes:
   - name: data
     persistentVolumeClaim:
       claimName: data-kube-etcd-MEMBER_NUMBER
   - name: etcd-certs
     secret:
       defaultMode: 420
       secretName: KUBE_ETCD_SECRET_NAME

Le fichier manifeste précédent décrit un pod utilitaire que vous exécutez temporairement pour restaurer les données etcd.

1. Créez le pod utilitaire dans votre cluster d'administrateur :

   kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG apply -f etcd-utility-MEMBER_NUMBER.yaml
   

2. Copiez votre fichier de sauvegarde snapshot.db dans le répertoire racine de votre pod utilitaire :

   kubectl --kubeconfig ADMIN_CLUSTER_KUBECONIFG cp snapshot.db \
   USER_CLUSTER_NAME/etcd-utility-MEMBER_NUMBER:snapshot.db
   

3. Ajoutez une interface système dans le conteneur etcd-utility du pod utilitaire :

   kubectl --kubeconfig ADMIN_CLUSTER_KUBECONIFG exec -it --namespace USER_CLUSTER_NAME \
   etcd-utility-MEMBER_NUMBER --container etcd-utility -- bin/sh
   

4. Dans votre interface système, dans le répertoire racine, utilisez snapshot.db pour restaurer les données etcd :

   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 \
   --name=kube-etcd-MEMBER_NUMBER \
   --initial-cluster=kube-etcd-0=https://kube-etcd-0.kube-etcd:2380,kube-etcd-1=https://kube-etcd-1.kube-etcd:2380,kube-etcd-2=https://kube-etcd-2.kube-etcd:2380 \
   --initial-cluster-token=etcd-cluster-1 \
   --initial-advertise-peer-urls=https://kube-etcd-MEMBER_NUMBER.kube-etcd:2380 \
   snapshot restore snapshot.db
   

   La commande précédente a stocké des données etcd dans le répertoire /kube-etcd-MEMBER_NUMBER.etcd.

5. Dans votre interface système, supprimez les anciennes données etcd :

   rm -r var/lib/etcd/*
   

6. Dans votre interface système, copiez les données etcd restaurées vers leur emplacement permanent :

   cp -r kube-etcd-MEMBER_NUMBER.etcd/* var/lib/etcd/
   

7. Dans votre interface système, supprimez le répertoire temporaire etcd et le fichier de sauvegarde :

   rm -R kube-etcd-MEMBER_NUMBER.etcd/
   rm snapshot.db
   

8. Dans votre interface système, saisissez exit pour quitter l'interface système.

9. Supprimez le pod utilitaire :

   kubectl --kubeconfig ADMIN_CLUSTER_KUBECONIFG delete pod \
   --namespace USER_CLUSTER_NAME etcd-utility-MEMBER_NUMBER
   

Redémarrer des composants

Maintenant que vous avez déployé et supprimé vos pods utilitaires, vous devez redémarrer certains composants du cluster.

1. Redémarrez les pods dans le StatefulSet kube-etcd :

   kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG rollout restart statefulset \
   --namespace USER_CLUSTER_NAME kube-etcd
   

2. Démarrez les serveurs d'API Kubernetes pour votre cluster d'utilisateur :

   kubectl --kubeconfig ADMIN_CLUSTER_KUBECONIFG scale statefulset --replicas 3 \
   --namespace USER_CLUSTER_NAME kube-apiserver
   

3. Démarrez le déploiement de maintenance etcd pour votre cluster d'utilisateur :

   kubectl --kubeconfig ADMIN_CLUSTER_KUBECONIFG scale deployment --replicas 1 \
   --namespace=USER_CLUSTER_NAME  gke-master-etcd-maintenance
   

4. Restaurez le PDB du serveur d'API Kubernetes :

   kubectl --kubeconfig ADMIN_CLUSTER_KUBECONIFG apply -f kube-apiserver-pdb.yaml
   

Plan de contrôle V2

Cette section explique comment restaurer les données etcd pour un cluster d'utilisateur haute disponibilité.

Pour un cluster d'utilisateur à haute disponibilité, le cluster d'utilisateur contient trois nœuds qui servent de plan de contrôle pour le cluster d'utilisateur. Chacun de ces nœuds exécute un pod etcd qui gère les données etcd sur un volume de stockage.

Si deux des pods etcd sont opérationnels et que les données sur les volumes de stockage associés sont intactes, il n'est pas nécessaire d'utiliser un fichier de sauvegarde. En effet, vous auriez toujours un quorum etcd.

Dans les rares cas où deux des volumes de stockage etcd contiennent des données corrompues, vous devez utiliser un fichier de sauvegarde pour les restaurer.

Pour suivre les étapes de cette section, vous devez déjà avoir créé un fichier snapshot.db, comme décrit dans Sauvegarder un cluster d'utilisateur.

Répertorier les pods etcd et les nœuds

Important :Suivez la procédure décrite dans les sections suivantes pour chacun des nœuds CP de votre cluster d'utilisateur.

1. Listez les pods etcd et leurs nœuds respectifs:

   kubectl get pod --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n kube-system -l component=etcd,tier=control-plane -o wide
   

   Le résultat affiche les pods etcd et les nœuds sur lesquels ils s'exécutent. Les nœuds affichés dans le résultat sont des nœuds du cluster d'administrateur servant de plans de contrôle pour votre cluster d'utilisateur :

   NAME           ...   NODE
   etcd-xxx       ...   xxx
   etcd-yyy       ...   yyy
   etcd-zzz       ...   zzz
   

2. Notez les noms des pods et des nœuds du plan de contrôle pour les utiliser plus tard.

   Notez que chaque pod etcd est nommé etcd-xxx, suivi d'un nom de nœud. En effet, dans la version 2 du plan de contrôle, les pods etcd s'exécutent en tant que pod statique.

Préparation de la restauration...

1. Exécutez scp pour copier le fichier de sauvegarde snapshot.db sur tous les nœuds du plan de contrôle de l'utilisateur:

   scp ~/snapshot.db -i NODE_NAME.key ubuntu@NODE_EXTERNAL_IP:/tmp/
   

2. Copiez les secrets sur le nœud de plan de contrôle d'utilisateur correspondant:

   chmod a+rw ~/pki_*
   scp -ri NODE_NAME.key ~/pki_NODE_NAME/* ubuntu@NODE_EXTERNAL_IP:/opt/data/etc/kubernetes/pki/
   

3. Ouvrez une interface système dans le nœud du plan de contrôle de l'utilisateur:

   ssh -i NODE_NAME.key ubuntu@NODE_EXTERNAL_IP
   

Effectuer la restauration

1. Rappelez le nom du pod etcd et le nom du nœud sur lequel le pod s'exécute.

2. Dans le shell, arrêtez le serveur d'API Kubernetes et le serveur etcd sur tous les nœuds du plan de contrôle d'utilisateur:

   sudo mv /etc/kubernetes/manifests/kube-apiserver.yaml /etc/kubernetes/manifests/etcd.yaml ~
   

3. Dans le shell, utilisez snapshot.db pour restaurer les données etcd sur tous les nœuds du plan de contrôle de l'utilisateur:

   sudo docker run --rm -t \
   -v /opt/data/var/lib:/var/lib \
   -v /etc/kubernetes/pki/etcd:/etc/kubernetes/pki/etcd \
   -v /tmp:/tmp \
   --env ETCDCTL_API=3 \
   gcr.io/gke-on-prem-release/etcd-util:GKE_ON_PREM_VERSION etcdctl \
   --cacert=/etc/kubernetes/pki/etcd/ca.crt \
   --cert=/etc/kubernetes/pki/etcd/server.crt \
   --key=/etc/kubernetes/pki/etcd/server.key \
   --data-dir=/opt/data/var/lib/etcd \
   --name=NODE_NAME \
   --initial-advertise-peer-urls=https://NODE_IP_ADDRESS:2380 \
   --initial-cluster=NODE1=https://NODE1_IP:2380,NODE2=https://NODE2_IP:2380,NODE3=https://NODE3_IP:2380 \
   snapshot restore /tmp/snapshot.db
   

   où :

   • GKE_ON_PREM_VERSION est la version de GKE Enterprise utilisée comme tag d'image.
   • NODE_NAME est le nom du nœud sur lequel la restauration est effectuée.
   • NODE_IP_ADDRESS est l'adresse IP de ce nœud.
   • Renseignez les champs NODE1, NODE2, NODE3 et IP de leur nœud respectif pour l'option --initial-cluster. Vous pouvez également l'obtenir à partir du fichier manifeste etcd.

4. Ajoutez l'indicateur - --initial-cluster-state=existing dans le fichier manifeste etcd sous la commande du conteneur.

   Exemple :

   containers:
         - command:
           - etcd
           ...
           - --initial-cluster-state=existing
           ...

Redémarrer des composants

1. Dans l'interface système, démarrez les serveurs kube-apiserver et etcd sur tous les nœuds du plan de contrôle d'utilisateur:

   sudo mv ~/etcd.yaml ~/kube-apiserver.yaml /etc/kubernetes/manifests/
   

2. Dans le shell, saisissez exit pour le quitter.

3. Vérifiez que kube-apiserver et etcd s'exécutent sur tous les nœuds du plan de contrôle d'utilisateur:

   kubectl get pod --kubeconfig USER_CLUSTER_KUBECONFIG \
   -n kube-system -l tier=control-plane
   

Remarque :Si les pods events-etcd sont à l'état CrashLoopBackOff, ajoutez l'indicateur - --initial-cluster-state=new et redémarrez les pods. Les événements ne seront pas synchronisés et vous perdrez ceux stockés précédemment.

Sauvegarde automatique des clusters

Vous pouvez utiliser le script fourni ici comme exemple pour la sauvegarde automatique des clusters. Notez toutefois que le script suivant n'est pas compatible et ne doit être utilisé qu'à titre de référence pour écrire un script avancé qui soit plus fiable et plus complet. Avant d'exécuter le script, renseignez les valeurs des cinq variables figurant au début du script:

kubeception

• Définissez BACKUP_DIR sur le chemin d'accès où vous souhaitez stocker les sauvegardes de cluster d'administrateur et d'utilisateur. Ce chemin d'accès ne doit pas exister.
• Définissez ADMIN_CLUSTER_KUBECONFIG sur le chemin d'accès du fichier kubeconfig du cluster d'administrateur.
• 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 dans le 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 votre clé SSH.
• Si vous utilisez un réseau privé, définissez JUMP_IP sur l'adresse IP du serveur intermédiaire de votre réseau.

#!/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_tmp ssh private key - follow steps in documentation
JUMP_IP=""                          # network jump server IP - leave empty string if not using private network.

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_CLUSTER_NAMESPACE}_snapshot.db $BACKUP_DIR/user-cluster_${USER_CLUSTER_NAMESPACE}_snapshot.db

# ADMIN CLUSTER BACKUP

# Set up ssh options
SSH_OPTS=(-oStrictHostKeyChecking=no -i ${SSH_PRIVATE_KEY})
if [ "${JUMP_IP}" != "" ]; then
  SSH_OPTS+=(-oProxyCommand="ssh -oStrictHostKeyChecking=no -i ${SSH_PRIVATE_KEY} -W %h:%p ubuntu@${JUMP_IP}")
fi

# Copy admin certs
ssh "${SSH_OPTS[@]}" ubuntu@${EXTERNAL_IP} 'sudo chmod -R +rw /etc/kubernetes/pki/*'
scp -r "${SSH_OPTS[@]}" 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 -l component=etcd,tier=control-plane -ojsonpath='{$.items[*].metadata.name}{"\n"}')
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"
kubectl --kubeconfig=${ADMIN_CLUSTER_KUBECONFIG} cp -n kube-system ${admin_etcd}:admin_snapshot.db $BACKUP_DIR/admin-cluster_snapshot.db

Plan de contrôle V2

• Définissez BACKUP_DIR sur le chemin d'accès où vous souhaitez stocker les sauvegardes de cluster d'administrateur et d'utilisateur. Ce chemin d'accès ne doit pas exister.
• Définissez ADMIN_CLUSTER_KUBECONFIG sur le chemin d'accès du fichier kubeconfig du cluster d'administrateur.
• Définissez USER_CLUSTER_KUBECONFIG sur le chemin d'accès de votre cluster d'utilisateur kubeconfig.
• 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 votre clé SSH.
• Si vous utilisez un réseau privé, définissez JUMP_IP sur l'adresse IP du serveur intermédiaire de votre réseau.

#!/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_KUBECONFIG=""          # path to user cluster kubeconfig
EXTERNAL_IP=""                      # admin control plane node external ip - follow steps in documentation
SSH_PRIVATE_KEY=""                  # path to ssh private key - follow steps in documentation
JUMP_IP=""                          # network jump server IP - leave empty string if not using private network

mkdir -p $BACKUP_DIR
mkdir $BACKUP_DIR/pki

# USER CLUSTER BACKUP
user_etcd=$(kubectl --kubeconfig=${USER_CLUSTER_KUBECONFIG} get pods -n kube-system -l component=etcd,tier=control-plane -ojsonpath='{$.items[0].metadata.name}{"\n"}')
kubectl --kubeconfig=${USER_CLUSTER_KUBECONFIG} exec -it -n kube-system ${user_etcd} -c 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/server.crt --key=/etc/kubernetes/pki/etcd/server.key snapshot save /tmp/${user_etcd}_snapshot.db"
kubectl --kubeconfig=${USER_CLUSTER_KUBECONFIG} cp kube-system/${user_etcd}:/tmp/${user_etcd}_snapshot.db $BACKUP_DIR/${user_etcd}_snapshot.db

# ADMIN CLUSTER BACKUP

# Set up ssh options
SSH_OPTS=(-oStrictHostKeyChecking=no -i ${SSH_PRIVATE_KEY})
if [ "${JUMP_IP}" != "" ]; then
  SSH_OPTS+=(-oProxyCommand="ssh -oStrictHostKeyChecking=no -i ${SSH_PRIVATE_KEY} -W %h:%p ubuntu@${JUMP_IP}")
fi

# Copy admin certs
ssh "${SSH_OPTS[@]}" ubuntu@${EXTERNAL_IP} 'sudo chmod -R +rw /etc/kubernetes/pki/*'
scp -r "${SSH_OPTS[@]}" 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 -l component=etcd,tier=control-plane -ojsonpath='{$.items[*].metadata.name}{"\n"}')
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 /tmp/${admin_etcd}_snapshot.db"
kubectl --kubeconfig=${ADMIN_CLUSTER_KUBECONFIG} cp -n kube-system ${admin_etcd}:/tmp/${admin_etcd}_snapshot.db $BACKUP_DIR/${admin_etcd}_snapshot.db

Vérifier la restauration

Pour vérifier que votre cluster a bien été restauré, exécutez la commande gkectl diagnose cluster.

Étapes suivantes

• Sauvegarder et restaurer un cluster d'administrateur
• 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.