Sauvegarder et restaurer des charges de travail de cluster à l'aide d'une instance autonome de Velero et de Restic

Vous pouvez sauvegarder et restaurer des charges de travail s'exécutant sur des clusters TKG à l'aide d'une instance autonome de Velero et de Restic. Cette méthode constitue une alternative à l'utilisation du Plug-in Velero pour vSphere. L'utilisation d'une instance autonome de Velero est principalement justifiée par le besoin d'une portabilité. Restic est requis pour les charges de travail avec état.

Conditions requises

Pour sauvegarder et restaurer les charges de travail sur les clusters TKG à l'aide d'une instance autonome de Velero et de Restic, vous devez installer la version autonome de Velero et de Restic sur le cluster cible. Si la restauration doit être effectuée sur un cluster de destination distinct, Velero et Restic doivent également être installés sur le cluster de destination. Reportez-vous à la section Installer et configurer des instances autonomes de Velero et Restic sur des clusters TKG.

Sauvegarder une application sans état exécutée sur un cluster TKG

La sauvegarde d'une application sans état exécutée sur un cluster TKG nécessite l'utilisation de Velero.

Cet exemple montre comment sauvegarder et restaurer un exemple d'application sans état à l'aide de la balise --include namespaces où tous les composants de l'application se trouve dans cet espace de noms.

velero backup create example-backup --include-namespaces example-backup

Vous devriez constater les résultats suivant :

Backup request "example-backup" submitted successfully.
Run `velero backup describe example-backup` or `velero backup logs example-backup` for more details.

Vérifiez la sauvegarde qui a été créée.

velero backup get

velero backup describe example-backup

Vérifiez le compartiment Velero sur le magasin d'objets compatibles S3, tel que le serveur MinIO.

Velero écrit des métadonnées dans les définitions de ressources personnalisées (CRD, Custom Resource Definition) Kubernetes.

kubectl get crd

Les CRD Velero vous permettent d'exécuter certaines commandes, notamment :

kubectl get backups.velero.io -n velero

kubectl describe backups.velero.io guestbook-backup -n velero

Restaurer une application sans état exécutée sur un cluster TKG

La restauration d'une application sans état exécutée sur un cluster TKG nécessite l'utilisation de Velero.

Pour tester la restauration d'un exemple d'application, supprimez-la.

Supprimez l'espace de noms :

kubectl delete ns guestbook
namespace "guestbook" deleted

Restaurez l'application :

velero restore create --from-backup example-backup

Vous devriez constater les résultats suivant :

Restore request "example-backup-20200721145620" submitted successfully.
Run `velero restore describe example-backup-20200721145620` or `velero restore logs example-backup-20200721145620` for more details.

Vérifiez que l'application est restaurée :

velero restore describe example-backup-20200721145620

Exécutez les commandes suivantes pour vérifier :

velero restore get

kubectl get ns

kubectl get pod -n example

kubectl get svc -n example

Sauvegarder une application avec état exécutée sur un cluster TKG

La sauvegarde d'une application avec état exécutée sur un cluster TKG implique la sauvegarde des métadonnées de l'application et des données de l'application stockées sur un volume persistant. Pour cela, vous avez besoin de Velero et de Restic.

Pour cet exemple, nous allons utiliser l'application Guestbook. Nous partons du principe que vous avez déployé l'application Guestbook sur un cluster TKG. Reportez-vous à la section Déployer l'application Guestbook sur un cluster TKG.

Pour permettre la démonstration de l'exécution d'une sauvegarde et d'une restauration avec état, envoyez un message à l'application Guestbook à l'aide de la page Web frontale afin que les messages soient conservés. Par exemple :

Les messages que vous envoyez s'affichent dans la liste des messages à conserver.

Cet exemple montre comment sauvegarder et restaurer l'application Guestbook à l'aide de la balise --include namespace ainsi que d'annotations d'espace.

Note : Cet exemple utilise des annotations. Cependant, les annotations ne sont plus nécessaires pour Velero 1.5 et versions ultérieures. Pour ne pas utiliser d'annotations, vous pouvez utiliser l'option --default-volumes-to-restic lors de la création de la sauvegarde. Cela sauvegarde automatiquement tous les PV à l'aide de Restic. Consultez https://velero.io/docs/v1.5/restic/ pour plus d'informations.

Pour commencer la procédure de sauvegarde, obtenez les noms des espaces :

kubectl get pod -n guestbook

Par exemple :

kubectl get pod -n guestbook

NAME                                            READY   STATUS    RESTARTS   AGE
guestbook-frontend-deployment-85595f5bf9-h8cff  1/1     Running            0          55m
guestbook-frontend-deployment-85595f5bf9-lw6tg  1/1     Running            0          55m
guestbook-frontend-deployment-85595f5bf9-wpqc8  1/1     Running            0          55m
redis-leader-deployment-64fb8775bf-kbs6s        1/1     Running            0          55m
redis-follower-deployment-84cd76b975-jrn8v      1/1     Running            0          55m
redis-follower-deployment-69df9b5688-zml4f      1/1     Running            0          55m

Les volumes persistants sont attachés aux espaces Redis. Étant donné que nous sauvegardons ces espaces avec état avec Restic, nous devons ajouter des annotations aux espaces avec état avec le nom volumeMount.

Vous devez connaître le volumeMount pour annoter l'espace avec état. Pour obtenir le mountName, exécutez la commande suivante.

kubectl describe pod redis-leader-deployment-64fb8775bf-kbs6s -n guestbook

Dans les résultats, vous voyez Containers.leader.Mounts: /data de redis-leader-data. Ce dernier jeton est le nom volumeMount à utiliser pour l'annotation de l'espace leader. Pour l'instance de follower, il sera redis-follower-data. Vous pouvez également obtenir le nom volumeMount à partir du fichier YAML source.

Annotez chacun des espaces Redis, par exemple :

kubectl -n guestbook annotate pod redis-leader-64fb8775bf-kbs6s backup.velero.io/backup-volumes=redis-leader-data

Vous devriez constater les résultats suivant :

pod/redis-leader-64fb8775bf-kbs6s annotated

Vérifiez les annotations :

kubectl -n guestbook describe pod redis-leader-64fb8775bf-kbs6s | grep Annotations
Annotations:  backup.velero.io/backup-volumes: redis-leader-data

kubectl -n guestbook describe pod redis-follower-779b6d8f79-5dphr | grep Annotations
Annotations:  backup.velero.io/backup-volumes: redis-follower-data

Effectuez la sauvegarde Velero :

velero backup create guestbook-backup --include-namespaces guestbook

Vous devriez constater les résultats suivant :

Backup request "guestbook-backup" submitted successfully.
Run `velero backup describe guestbook-pv-backup` or `velero backup logs guestbook-pv-backup` for more details.

Vérifiez la sauvegarde qui a été créée.

velero backup get

NAME                  STATUS      ERRORS   WARNINGS   CREATED                         EXPIRES   STORAGE LOCATION   SELECTOR
guestbook-backup      Completed   0        0          2020-07-23 16:13:46 -0700 PDT   29d       default            <none>

Vérifiez les détails de la sauvegarde.

velero backup describe guestbook-backup --details

Notez que Velero vous permet d'exécuter d'autres commandes, telles que :

kubectl get backups.velero.io -n velero

NAME               AGE
guestbook-backup   4m58s

Et :

kubectl describe backups.velero.io guestbook-backup -n velero

Restaurer une application avec état exécutée sur un cluster TKG 2.0

La restauration d'une application avec état exécutée sur un cluster TKG implique la restauration des métadonnées d'application et des données d'application stockées sur un volume persistant. Pour cela, vous avez besoin de Velero et de Restic.

Cet exemple part du principe que vous avez sauvegardé l'application Guestbook avec état comme décrit dans la section précédente.

Pour tester la restauration de l'application avec état, supprimez son espace de noms :

kubectl delete ns guestbook
namespace "guestbook" deleted

Vérifiez la suppression de l'application :

kubectl get ns
kubectl get pvc,pv --all-namespaces

Pour restaurer une application à partir d'une sauvegarde et utilisez la syntaxe de commande suivante.

velero restore create --from-backup <velero-backup-name>

Par exemple :

velero restore create --from-backup guestbook-backup

Vous devriez voir des messages semblable au suivant :

Restore request "guestbook-backup-20200723161841" submitted successfully.
Run `velero restore describe guestbook-backup-20200723161841` or `velero restore logs guestbook-backup-20200723161841` for more details.

Vérifiez que l'application Guestbook avec état est restaurée :

velero restore describe guestbook-backup-20200723161841

Name:         guestbook-backup-20200723161841
Namespace:    velero
Labels:       <none>
Annotations:  <none>

Phase:  Completed

Backup:  guestbook-backup

Namespaces:
  Included:  all namespaces found in the backup
  Excluded:  <none>

Resources:
  Included:        *
  Excluded:        nodes, events, events.events.k8s.io, backups.velero.io, restores.velero.io, resticrepositories.velero.io
  Cluster-scoped:  auto

Namespace mappings:  <none>

Label selector:  <none>

Restore PVs:  auto

Restic Restores (specify --details for more information):
  Completed:  3

Exécutez la commande supplémentaire suivante pour vérifier la restauration :

velero restore get

NAME                                 BACKUP                STATUS      ERRORS   WARNINGS   CREATED                         SELECTOR
guestbook-backup-20200723161841      guestbook-backup      Completed   0        0          2021-08-11 16:18:41 -0700 PDT   <none>

Vérifiez que l'espace de noms est restauré :

kubectl get ns

NAME              STATUS   AGE
default           Active   16d
guestbook         Active   76s
...
velero            Active   2d2h

Vérifiez que l'application est restaurée :

vkubectl get all -n guestbook

NAME                                READY   STATUS    RESTARTS   AGE
pod/frontend-6cb7f8bd65-h2pnb       1/1     Running   0          6m27s
pod/frontend-6cb7f8bd65-kwlpr       1/1     Running   0          6m27s
pod/frontend-6cb7f8bd65-snwl4       1/1     Running   0          6m27s
pod/redis-leader-64fb8775bf-kbs6s   1/1     Running   0          6m28s
pod/redis-follower-779b6d8f79-5dphr 1/1     Running   0          6m28s
pod/redis-follower-899c7e2z65-8apnk 1/1     Running   0          6m28s

NAME                                 TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)        AGE
service/guestbook-frontend           LoadBalancer   10.10.89.59      10.19.15.99     80:31513/TCP   65s
service/redis-follower               ClusterIP      10.111.163.189   <none>          6379/TCP       65s
service/redis-leader                 ClusterIP      10.111.70.189    <none>          6379/TCP       65s

NAME                                            READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/guestbook-frontend-deployment   3/3     3            3           65s
deployment.apps/redis-follower-deployment       1/2     2            1           65s
deployment.apps/redis-leader-deployment         1/1     1            1           65s

NAME                                                       DESIRED   CURRENT   READY   AGE
replicaset.apps/guestbook-frontend-deployment-56fc5b6b47   3         3         3       65s
replicaset.apps/redis-follower-deployment-6fc9cf5759       2         2         1       65s
replicaset.apps/redis-leader-deployment-7d89bbdbcf         1         1         1       65s

Vérifiez que les volumes persistants sont restaurés :

kubectl get pvc,pv -n guestbook

NAME                                       STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
persistentvolumeclaim/redis-leader-claim   Bound    pvc-a2f6e6d4-42db-4fb8-a198-5379a2552509   2Gi        RWO            thin-disk      2m40s
persistentvolumeclaim/redis-follower-claim Bound    pvc-55591938-921f-452a-b418-2cc680c0560b   2Gi        RWO            thin-disk      2m40s

NAME                                                        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                             STORAGECLASS   REASON   AGE
persistentvolume/pvc-55591938-921f-452a-b418-2cc680c0560b   2Gi        RWO            Delete           Bound    guestbook/redis-follower-claim    thin-disk               2m40s
persistentvolume/pvc-a2f6e6d4-42db-4fb8-a198-5379a2552509   2Gi        RWO            Delete           Bound    guestbook/redis-leader-claim      thin-disk               2m40s

Enfin, accédez au serveur frontal Guestbook à l'aide de l'adresse IP externe du service guestbook-frontend et vérifiez que les messages que vous avez envoyés au début du didacticiel sont restaurés. Par exemple :

Liste des messages qui sont restaurés.