Puede realizar copias de seguridad y restaurar cargas de trabajo de clúster de Tanzu Kubernetes mediante Restic y Velero independientes. Este método es una alternativa al uso de un complemento complemento de Velero para vSphere. La razón principal para usar Velero independiente en lugar del complemento complemento de Velero para vSphere es si se requiere portabilidad. Se requiere Restic para las cargas de trabajo con estado.

Requisitos previos

Para realizar copias de seguridad y restaurar cargas de trabajo de clúster de Tanzu Kubernetes mediante Restic y Velero independientes, debe instalar la versión independiente de estos en el clúster de destino. Consulte Instalar y configurar Velero y Restic independientes en un clúster de Tanzu Kubernetes.
Nota: La copia de seguridad y la restauración de un clúster de Kubernetes mediante Velero independiente con Restic le ofrece portabilidad. Esto significa que si desea poder restaurar las cargas de trabajo del clúster en un clúster de Kubernetes no aprovisionado por servicio Tanzu Kubernetes Grid, debe utilizar Velero independiente.

Realizar una copia de seguridad de una aplicación sin estado que se ejecuta en un clúster de Tanzu Kubernetes

La copia de seguridad de una aplicación sin estado que se ejecuta en un clúster de Tanzu Kubernetes requiere el uso de Velero.

En este ejemplo se muestra cómo realizar una copia de seguridad y restaurar una aplicación sin estado de ejemplo mediante la etiqueta --include namespaces en la que todos los componentes de la aplicación se encuentran en ese espacio de nombres.
velero backup create example-backup --include-namespaces example-backup
Debería ver el siguiente mensaje:
Backup request "example-backup" submitted successfully.
Run `velero backup describe example-backup` or `velero backup logs example-backup` for more details.
Compruebe la copia de seguridad que se creó.
velero backup get
velero backup describe example-backup

Compruebe el depósito Velero en el almacén de objetos compatible con S3, como el servidor MinIO.

Velero escribe algunos metadatos en definiciones de recursos personalizados (Custom Resource Definitions, CRD) de Kubernetes.
kubectl get crd
Las CRD de Velero permiten ejecutar ciertos comandos, como los siguientes:
kubectl get backups.velero.io -n velero
kubectl describe backups.velero.io guestbook-backup -n velero

Restaurar una aplicación sin estado en ejecución en un clúster de Tanzu Kubernetes

La restauración de una aplicación sin estado que se ejecuta en un clúster de Tanzu Kubernetes requiere el uso de Velero.

Para probar la restauración de una aplicación de ejemplo, elimínela.

Elimine el espacio de nombres:
kubectl delete ns guestbook
namespace "guestbook" deleted
Restaure la aplicación:
velero restore create --from-backup example-backup
Debería ver el siguiente mensaje:
Restore request "example-backup-20200721145620" submitted successfully.
Run `velero restore describe example-backup-20200721145620` or `velero restore logs example-backup-20200721145620` for more details.
Compruebe que la aplicación se restauró:
velero restore describe example-backup-20200721145620
Ejecute los siguientes comandos para comprobar:
velero restore get
kubectl get ns
kubectl get pod -n example
kubectl get svc -n example

Realizar una copia de seguridad de una aplicación con estado que se ejecuta en un clúster de Tanzu Kubernetes

Realizar una copia de seguridad de una aplicación con estado que se ejecuta en un clúster de Tanzu Kubernetes implica realizar una copia de seguridad de los metadatos de la aplicación y los datos de la aplicación almacenados en un volumen persistente. Para ello, necesita Velero y Restic.

En este ejemplo, utilizaremos la aplicación del libro de visitas. Si se supone que implementó la aplicación del libro de visitas en un clúster de Tanzu Kubernetes. Consulte Tutorial del libro de visitas de Tanzu Kubernetes para obtener instrucciones.

Para que podamos demostrar una copia de seguridad y una restauración con estado, envíe un mensaje a la aplicación del libro de visitas mediante la página web de front-end para que los mensajes persistan. Por ejemplo:

Los mensajes que envía aparecen en la lista de mensajes que se conservarán.

En este ejemplo se muestra cómo realizar una copia de seguridad y restaurar la aplicación del libro de visitas mediante la etiqueta --include namespace, así como las anotaciones del pod.
Nota: En este ejemplo, se utilizan anotaciones. Sin embargo, ya no se necesitan anotaciones para Velero 1.5 y versiones posteriores. Para no utilizar anotaciones, puede usar la opción --default-volumes-to-restic al crear la copia de seguridad. Esto hará una copia de seguridad automática de todos los VA mediante Restic. Consulte https://velero.io/docs/v1.5/restic/ para obtener más información.
Para comenzar el procedimiento de copia de seguridad, obtenga los nombres de los pods:
kubectl get pod -n guestbook
Por ejemplo:
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

Los volúmenes persistentes se asocian a los pods de Redis. Debido a que estamos realizando una copia de seguridad de estos pods con estado con Restic, es necesario agregar anotaciones a los pods con estado con el nombre volumeMount.

Debe conocer volumeMount para anotar el pod con estado. Para obtener mountName, ejecute el siguiente comando.
kubectl describe pod redis-leader-deployment-64fb8775bf-kbs6s -n guestbook

En los resultados, verá Containers.leader.Mounts: /data de redis-leader-data. Este último token es el nombre volumeMount que se utilizará para la anotación del pod principal. Para el seguidor, será redis-follower-data. También puede obtener el nombre de volumeMount del YAML de origen.

Anote cada uno de los pods de Redis, por ejemplo:
kubectl -n guestbook annotate pod redis-leader-64fb8775bf-kbs6s backup.velero.io/backup-volumes=redis-leader-data
Debería ver el siguiente mensaje:
pod/redis-leader-64fb8775bf-kbs6s annotated
Verifique las anotaciones:
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
Realice la copia de seguridad de Velero:
velero backup create guestbook-backup --include-namespaces guestbook
Debería ver el siguiente mensaje:
Backup request "guestbook-backup" submitted successfully.
Run `velero backup describe guestbook-pv-backup` or `velero backup logs guestbook-pv-backup` for more details.
Compruebe la copia de seguridad que se creó.
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>
Compruebe los detalles de la copia de seguridad.
velero backup describe guestbook-backup --details
Tenga en cuenta que Velero permite ejecutar otros comandos, como:
kubectl get backups.velero.io -n velero

NAME               AGE
guestbook-backup   4m58s
Y:
kubectl describe backups.velero.io guestbook-backup -n velero

Restaurar una aplicación con estado en ejecución en un clúster de Tanzu Kubernetes

La restauración de una aplicación con estado que se ejecuta en un clúster de Tanzu Kubernetes implica restaurar tanto los metadatos de la aplicación como los datos de la aplicación almacenados en un volumen persistente. Para ello, necesita Velero y Restic.

En este ejemplo, se supone que se realizó una copia de seguridad de la aplicación de libro de visitas con estado, como se describe en la sección anterior.

Para probar la restauración de la aplicación con estado, elimine su espacio de nombres:
kubectl delete ns guestbook
namespace "guestbook" deleted
Verifique la eliminación de la aplicación:
kubectl get ns
kubectl get pvc,pv --all-namespaces
Restaure la aplicación:
Restore request "guestbook-backup-20200723161841" submitted successfully.
Run `velero restore describe guestbook-backup-20200723161841` or `velero restore logs guestbook-backup-20200723161841` for more details.
Compruebe que se restauró la aplicación del libro de visitas con estado:
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
Ejecute el siguiente comando adicional para verificar la restauración:
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>
Compruebe que se restauró el espacio de nombres:
kubectl get ns

NAME              STATUS   AGE
default           Active   16d
guestbook         Active   76s
...
velero            Active   2d2h
Compruebe que la aplicación se restauró:
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
Compruebe que se restauren los volúmenes persistentes:
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

Por último, acceda al front-end del libro de visitas mediante la dirección IP externa del servicio de front-end del libro de visitas y compruebe que se restauren los mensajes que envió al principio del tutorial. Por ejemplo:

La lista de mensajes restaurados.