Copia de seguridad y restauración de cargas de trabajo de clúster mediante Restic y Velero independientes

Puede realizar operaciones de copia de seguridad y restauración de las cargas de trabajo que se ejecutan en los clústeres de TKG mediante Velero y Restic 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 es la necesidad de portabilidad. Se requiere Restic para las cargas de trabajo con estado.

Requisitos previos

Para realizar copias de seguridad y restaurar cargas de trabajo en clústeres de TKG mediante Restic y Velero independientes, debe instalar la versión independiente de estos en el clúster de destino. Si la restauración se va a realizar en un clúster de destino independiente, Velero y Restic también deben estar instalados en el clúster de destino. Consulte Instalar y configurar Velero y Restic independientes en clústeres de TKG.

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

La copia de seguridad de una aplicación sin estado que se ejecuta en un clúster de TKG 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 TKG

La restauración de una aplicación sin estado que se ejecuta en un clúster de TKG 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 TKG

Realizar una copia de seguridad de una aplicación con estado que se ejecuta en un clúster de TKG 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 TKG. Consulte Implementar la aplicación del libro de visitas en un clúster de TKG.

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

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

Restaurar una aplicación con estado que se ejecuta en un clúster de TKG 2.0

La restauración de una aplicación con estado que se ejecuta en un clúster de TKG 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

Para restaurar una aplicación desde una copia de seguridad, utilice la siguiente sintaxis de comandos.

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

Por ejemplo:

velero restore create --from-backup guestbook-backup

Deben aparecer mensajes similares al siguiente:

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.