Sichern und Wiederherstellen von Clusterarbeitslasten mit eigenständigem Velero und Restic

Sie können Arbeitslasten, die in TKG-Clustern ausgeführt werden, mithilfe von eigenständigem Velero und Restic sichern und wiederherstellen. Dieses Verfahren ist eine Alternative zur Verwendung des eingebetteten Velero-Plug-In für vSphere. Eigenständiges Velero wird hauptsächlich verwendet, wenn Sie Portabilität benötigen. Restic ist für statusbehaftete Arbeitslasten erforderlich.

Voraussetzungen

Zum Sichern und Wiederherstellen von Arbeitslasten in einem TKG-Cluster mit eigenständigem Velero und Restic müssen Sie die eigenständige Version von Velero und Restic im Zielcluster installieren. Wenn die Wiederherstellung in einem separaten Zielcluster durchgeführt werden soll, müssen Velero und Restic ebenfalls im Zielcluster installiert sein. Weitere Informationen finden Sie unter Installieren und Konfigurieren von eigenständigem Velero und Restic in TKG-Clustern.

Sichern einer statusfreien Anwendung, die auf einem TKG-Cluster ausgeführt wird

Zum Sichern einer statusfreien Anwendung, die auf einem TKG-Cluster ausgeführt wird, müssen Sie Velero verwenden.

Dieses Beispiel zeigt, wie Sie eine statusfreie Beispielanwendung mit dem --include namespaces-Tag sichern und wiederherstellen, wobei sich alle Anwendungskomponenten in diesem Namespace befinden.

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

Sie sollten folgende Meldung sehen:

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

Überprüfen Sie die erstellte Sicherung.

velero backup get

velero backup describe example-backup

Überprüfen Sie den Velero-Bucket im S3-kompatiblen Objektspeicher, z. B. auf dem MinIO-Server.

Velero schreibt einige Metadaten in benutzerdefinierte Kubernetes-Ressourcendefinitionen (Custom Resource Definitions, CRDs).

kubectl get crd

Mit den Velero-CRDs können Sie bestimmte Befehle ausführen, wie z. B.:

kubectl get backups.velero.io -n velero

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

Wiederherstellen einer statusfreien Anwendung, die auf einem TKG-Cluster ausgeführt wird

Zum Wiederherstellen einer statusfreien Anwendung, die auf einem TKG-Cluster ausgeführt wird, müssen Sie Velero verwenden.

Um die Wiederherstellung einer Beispielanwendung zu testen, löschen Sie sie.

Löschen Sie den Namespace:

kubectl delete ns guestbook
namespace "guestbook" deleted

Stellen Sie die App wieder her:

velero restore create --from-backup example-backup

Sie sollten folgende Meldung sehen:

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

Überprüfen Sie, ob die App wiederhergestellt wurde:

velero restore describe example-backup-20200721145620

Führen Sie zur Überprüfung die folgenden Befehle aus:

velero restore get

kubectl get ns

kubectl get pod -n example

kubectl get svc -n example

Sichern einer statusbehafteten Anwendung, die auf einem TKG-Cluster ausgeführt wird

Zum Sichern einer statusbehafteten Anwendung, die auf einem TKG-Cluster ausgeführt wird, müssen sowohl die Metadaten als auch die Daten der Anwendung gesichert werden, die auf einem persistenten Volume gespeichert sind. Dazu benötigen Sie Velero und Restic.

Für dieses Beispiel verwenden wir die Guestbook-Anwendung. Dabei wird davon ausgegangen, dass Sie die Guestbook-Anwendung in einem TKG-Cluster bereitgestellt haben. Weitere Informationen finden Sie unter Bereitstellen der Guestbook-Anwendung in einem TKG-Cluster.

Zur Veranschaulichung der statusbehafteten Sicherung und Wiederherstellung senden Sie irgendeine Nachricht über die Frontend-Seite an die Guestbook-Anwendung, damit die Nachrichten dauerhaft gespeichert werden. Beispiel:

Die von Ihnen gesendeten Mails werden in der Liste der dauerhaft beizubehaltenden Nachrichten angezeigt.

Dieses Beispiel zeigt, wie Sie die Guestbook-App mit dem --include namespace-Tag und Pod-Anmerkungen sichern und wiederherstellen.

Hinweis: In diesem Beispiel werden Anmerkungen verwendet. Für Velero Version 1.5 und höher sind jedoch keine Anmerkungen mehr erforderlich. Um keine Anmerkungen zu verwenden, können Sie beim Erstellen der Sicherung die Option --default-volumes-to-restic verwenden. Dadurch werden automatisch alle PVs mit Restic gesichert. Weitere Informationen hierzu finden Sie unter https://velero.io/docs/v1.5/restic/.

Um den Sicherungsvorgang zu starten, rufen Sie die Namen der Pods ab:

kubectl get pod -n guestbook

Beispiel:

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

Die persistenten Volumes werden an die Redis-Pods angehängt. Da wir diese statusbehafteten Pods mit Restic sichern, müssen wir den statusbehafteten Pods mit dem Namen volumeMount Anmerkungen hinzufügen.

Sie müssen den volumeMount kennen, um den statusbehafteten Pod mit Anmerkungen zu versehen. Führen Sie folgenden Befehl aus, um den mountName abzurufen.

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

In den Ergebnissen sehen Sie Containers.leader.Mounts: /data aus redis-leader-data. Dieses letzte Token ist der volumeMount-Name, der für die Annotation des Leader-Pods verwendet werden soll. Für den Follower ist dies redis-follower-data. Sie können den volumeMount-Namen auch aus der Quell-YAML abrufen.

Versehen Sie jeden Redis-Pod mit Anmerkungen, z. B.:

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

Sie sollten folgende Meldung sehen:

pod/redis-leader-64fb8775bf-kbs6s annotated

Überprüfen Sie die Anmerkungen:

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

Führen Sie die Velero-Sicherung durch:

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

Sie sollten folgende Meldung sehen:

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

Überprüfen Sie die erstellte Sicherung.

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>

Überprüfen Sie die Sicherungsdetails.

velero backup describe guestbook-backup --details

Beachten Sie, dass Sie mit Velero andere Befehle ausführen können, wie z. B.:

kubectl get backups.velero.io -n velero

NAME               AGE
guestbook-backup   4m58s

Und:

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

Wiederherstellen einer statusbehafteten Anwendung, die auf einem TKG 2.0-Cluster ausgeführt wird

Zum Wiederherstellen einer statusbehafteten Anwendung, die auf einem TKG-Cluster ausgeführt wird, müssen sowohl die Metadaten als auch die Daten der Anwendung wiederhergestellt werden, die auf einem persistenten Volume gespeichert sind. Dazu benötigen Sie Velero und Restic.

In diesem Beispiel wird davon ausgegangen, dass Sie die statusbehaftete Guestbook-Anwendung wie im vorherigen Abschnitt beschrieben gesichert haben.

Um die Wiederherstellung der statusbehafteten Anwendung zu testen, löschen Sie ihren Namespace:

kubectl delete ns guestbook
namespace "guestbook" deleted

Überprüfen Sie, ob die Anwendung gelöscht wurde:

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

Verwenden Sie die folgende Befehlssyntax, um eine Anwendung von der Sicherung wiederherzustellen.

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

Beispiel:

velero restore create --from-backup guestbook-backup

Sinngemäß sollten Meldungen wie die folgenden angezeigt werden:

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

Überprüfen Sie, ob die statusbehaftete Guestbook-Anwendung wiederhergestellt wurde:

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

Führen Sie den folgenden zusätzlichen Befehl aus, um die Wiederherstellung zu überprüfen:

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>

Überprüfen Sie, ob der Namespace wiederhergestellt wurde:

kubectl get ns

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

Überprüfen Sie, ob die Anwendung wiederhergestellt wurde:

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

Überprüfen Sie, ob die persistenten Volumes wiederhergestellt wurden:

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

Öffnen Sie zum Schluss das Guestbook-Frontend über die externe IP des Guestbook-Frontend-Diensts und überprüfen Sie, ob die Nachrichten, die Sie zu Beginn des Lernprogramms gesendet haben, wiederhergestellt wurden. Beispiel:

Die Liste der wiederhergestellten Nachrichten.