Backup e ripristino dei carichi di lavoro del cluster mediante Velero e Restic autonomi

È possibile eseguire il backup e il ripristino dei carichi di lavoro in esecuzione nei cluster TKG utilizzando Velero e Restic autonomi. Questo metodo è un'alternativa all'utilizzo di Plug-in Velero per vSphere. Il motivo principale per cui si utilizza Velero autonomo è la necessità della portabilità. Per i carichi di lavoro stateful, è necessario Restic.

Prerequisiti

Per eseguire il backup e il ripristino dei carichi di lavoro su un cluster TKG utilizzando Velero e Restic autonomi, è necessario installare la versione autonoma di Velero e Restic nel cluster di destinazione. Se il ripristino deve essere eseguito in un cluster di destinazione separato, nel cluster di destinazione devono essere installati anche Velero e Restic. Vedere Installazione e configurazione di Restic e Velero in modalità autonoma in cluster TKG.

Backup di un'applicazione stateless in esecuzione in un cluster TKG

Il backup di un'applicazione stateless in esecuzione in un cluster TKG richiede l'uso di Velero.

In questo esempio viene illustrata la procedura di backup e ripristino di un'applicazione stateless di esempio tramite il tag --include namespaces in cui tutti i componenti dell'applicazione si trovano in tale spazio dei nomi.

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

Si dovrebbe vedere quanto segue:

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

Verificare che il backup sia stato creato.

velero backup get

velero backup describe example-backup

Controllare il bucket Velero nell'archivio di oggetti compatibile con S3, ad esempio il server MinIO.

Velero scrive alcuni metadati nelle definizioni delle risorse personalizzate di Kubernetes (CRD).

kubectl get crd

I CRD di Velero consentono di eseguire determinati comandi, come i seguenti:

kubectl get backups.velero.io -n velero

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

Ripristino di un'applicazione stateless in esecuzione in un cluster TKG

Il ripristino di un'applicazione stateless in esecuzione in un cluster TKG richiede l'uso di Velero.

Per provare il ripristino di un'applicazione di esempio, eliminarla.

Eliminare lo spazio dei nomi:

kubectl delete ns guestbook
namespace "guestbook" deleted

Ripristinare l'app:

velero restore create --from-backup example-backup

Si dovrebbe vedere quanto segue:

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

Verificare che l'app sia ripristinata:

velero restore describe example-backup-20200721145620

Eseguire i comandi seguenti per verificare:

velero restore get

kubectl get ns

kubectl get pod -n example

kubectl get svc -n example

Backup di un'applicazione stateful in esecuzione in un cluster TKG

Il backup di un'applicazione stateful in esecuzione in un cluster TKG implica il backup dei metadati dell'applicazione e dei dati dell'applicazione archiviati in un volume persistente. A tale scopo, sono necessari Velero e Restic.

Per questo esempio verrà utilizzata l'applicazione Guestbook. Si presuppone che l'applicazione Guestbook sia stata distribuita in un cluster TKG. Vedere Distribuzione dell'applicazione guestbook in un cluster TKG.

Affinché sia possibile dimostrare il backup e il ripristino stateful, inviare un messaggio all'applicazione Guestbook utilizzando la pagina Web front-end in modo che i messaggi siano persistenti. Ad esempio:

I messaggi inviati vengono visualizzati nell'elenco dei messaggi da rendere persistenti.

In questo esempio viene illustrata la procedura di backup e ripristino dell'app Guestbook mediante il tag --include namespace, nonché le annotazioni del pod.

Nota: In questo esempio vengono utilizzate annotazioni. Tuttavia, le annotazioni non sono più necessarie per Velero versione 1.5 e successive. Per non utilizzare le annotazioni, è possibile utilizzare l'opzione --default-volumes-to-restic durante la creazione del backup. Questa opzione eseguirà automaticamente il backup di tutti i PV mediante Restic. Per ulteriori informazioni, vedere https://velero.io/docs/v1.5/restic/.

Per iniziare la procedura di backup, recuperare i nomi dei pod:

kubectl get pod -n guestbook

Ad esempio:

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

I volumi persistenti sono collegati ai pod Redis. Poiché si sta eseguendo il backup di questi pod stateful con Restic, è necessario aggiungere annotazioni ai pod stateful con il nome volumeMount.

È necessario conoscere volumeMount per aggiungere annotazioni ai pod stateful. Per ottenere il valore di mountName, eseguire il comando seguente.

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

Nei risultati sono disponibili Containers.leader.Mounts: /data di redis-leader-data. Questo ultimo token è il nome di volumeMount da utilizzare per aggiungere annotazioni nel pod leader. Per il follower sarà redis-follower-data. È inoltre possibile recuperare il nome di volumeMount dal codice YAML di origine.

Aggiungere annotazioni in ciascuno dei pod Redis, ad esempio:

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

Si dovrebbe vedere quanto segue:

pod/redis-leader-64fb8775bf-kbs6s annotated

Verificare le annotazioni:

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

Eseguire il backup di Velero:

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

Si dovrebbe vedere quanto segue:

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

Verificare che il backup sia stato creato.

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>

Verificare i dettagli del backup.

velero backup describe guestbook-backup --details

Si tenga presente che Velero consente di eseguire altri comandi, come ad esempio:

kubectl get backups.velero.io -n velero

NAME               AGE
guestbook-backup   4m58s

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

Ripristino di un'applicazione stateful in esecuzione in un cluster TKG 2.0

Il ripristino di un'applicazione stateful in esecuzione in un cluster TKG implica il ripristino dei metadati dell'applicazione e dei dati dell'applicazione archiviati in un volume persistente. A tale scopo, sono necessari Velero e Restic.

In questo esempio si presuppone che sia stato eseguito il backup dell'applicazione Guestbook stateful come descritto nella sezione precedente.

Per verificare il ripristino dell'applicazione stateful, eliminare lo spazio dei nomi:

kubectl delete ns guestbook
namespace "guestbook" deleted

Verificare l'eliminazione dell'applicazione:

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

Per ripristinare un'applicazione dal backup, utilizzare la seguente sintassi di comando.

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

Ad esempio:

velero restore create --from-backup guestbook-backup

Vengono visualizzati messaggi simili ai seguenti:

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

Verificare che l'applicazione Guestbook stateful venga ripristinata:

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

Eseguire il seguente comando aggiuntivo per verificare il ripristino:

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>

Verificare che lo spazio dei nomi sia ripristinato:

kubectl get ns

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

Verificare che l'applicazione sia ripristinata:

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

Verificare che i volumi persistenti siano ripristinati:

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

Infine, accedere al front-end Guestbook utilizzando l'IP esterno del servizio guestbook-frontend e verificare che i messaggi inviati all'inizio del tutorial vengano ripristinati. Ad esempio:

L'elenco dei messaggi ripristinati.