Backup e restauração de cargas de trabalho no TKG 2 Cluster Workloads em Supervisor usando o Velero autônomo e o Restic

Você pode fazer backup e restaurar cargas de trabalho em execução em clusters TKG 2 em Supervisor usando o Velero e o Restic autônomos. Esse método é uma alternativa ao uso do Velero Plugin for vSphere. O principal motivo para usar o Velero autônomo é se você precisar de portabilidade. O Restic é necessário para cargas de trabalho com estado.

Pré-requisitos

Para fazer backup e restaurar cargas de trabalho em clusters TKG 2 em Supervisor usando o Velero e o Restic autônomos, você deve instalar a versão autônoma do Velero e do Restic no cluster de destino.

Observação: Fazer backup e restaurar um cluster Kubernetes usando o Velero autônomo com Restic oferece portabilidade. Isso significa que, se você quiser restaurar cargas de trabalho de cluster para um cluster Kubernetes não provisionado pelo TKG, precisará usar o Velero autônomo.

Fazer backup de um aplicativo sem estado em execução em um cluster do TKG 2

O backup de um aplicativo sem estado em execução em um cluster TKG requer o uso do Velero.

Este exemplo mostra como fazer backup e restaurar um aplicativo sem estado de exemplo usando a tag --include namespaces em que todos os componentes do aplicativo estão nesse namespace.

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

Você deve ver o seguinte:

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

Verifique o backup que foi criado.

velero backup get

velero backup describe example-backup

Verifique o bucket do Velero no armazenamento de objetos compatível com S3, como o servidor MinIO.

O Velero grava alguns metadados nas definições de recursos personalizados (CRDs) do Kubernetes.

kubectl get crd

Os CRDs do Velero permitem que você execute determinados comandos, como os seguintes:

kubectl get backups.velero.io -n velero

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

Restaurar um aplicativo sem estado em execução em um cluster TKG

A restauração de um aplicativo sem estado em execução em um cluster TKG requer o uso do Velero.

Para testar a restauração de um aplicativo de exemplo, exclua-o.

Exclua o namespace:

kubectl delete ns guestbook
namespace "guestbook" deleted

Restaure o aplicativo:

velero restore create --from-backup example-backup

Você deve ver o seguinte:

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

Verifique se o aplicativo foi restaurado:

velero restore describe example-backup-20200721145620

Execute os seguintes comandos para verificar:

velero restore get

kubectl get ns

kubectl get pod -n example

kubectl get svc -n example

Fazer backup de um aplicativo com monitoramento de estado em execução em um cluster TKG

O backup de um aplicativo com monitoramento de estado em execução em um cluster TKG envolve o backup dos metadados do aplicativo e dos dados do aplicativo armazenados em um volume persistente. Para fazer isso, você precisa do Velero e do Restic.

Para este exemplo, vamos usar o aplicativo Guestbook. Se for assumido que você implantou o aplicativo Guestbook em um cluster TKG. Consulte Implantar o aplicativo Guestbook em um cluster TKG 2.

Para que possamos demonstrar o backup e a restauração com estado, envie alguma mensagem para o aplicativo Guestbook usando a página da Web de front-end para que as mensagens sejam persistidas. Por exemplo:

As mensagens que você envia aparecem na lista de mensagens a serem persistidas.

Este exemplo mostra como fazer backup e restaurar o aplicativo Guestbook usando a tag --include namespace, bem como as anotações do pod.

Observação: Este exemplo usa anotações. No entanto, as anotações não são mais necessárias para o Velero versão 1.5 e posteriores. Para não usar anotações, você pode usar a opção --default-volumes-to-restic ao criar o backup. Isso fará o backup automático de todos os PVs usando o Restic. Consulte https://velero.io/docs/v1.5/restic/ para obter mais informações.

Para iniciar o procedimento de backup, obtenha os nomes dos pods:

kubectl get pod -n guestbook

Por exemplo:

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

Os volumes persistentes são anexados aos pods do Redis. Como estamos fazendo backup desses pods com estado com o Restic, precisamos adicionar anotações aos pods com estado com o nome volumeMount.

Você precisa conhecer o volumeMount para anotar o pod com estado. Para obter o mountName, execute o seguinte comando.

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

Nos resultados, você vê Containers.leader.Mounts: /data de redis-leader-data. Esse último token é o nome volumeMount a ser usado para a anotação do pod líder. Para o seguidor, será redis-follower-data. Você também pode obter o nome volumeMount do YAML de origem.

Anote cada um dos pods do Redis, por exemplo:

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

Você deve ver o seguinte:

pod/redis-leader-64fb8775bf-kbs6s annotated

Verifique as anotações:

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

Execute o backup do Velero:

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

Você deve ver o seguinte:

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

Verifique o backup que foi criado.

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>

Verifique os detalhes do backup.

velero backup describe guestbook-backup --details

Observe que o Velero permite executar outros comandos, como:

kubectl get backups.velero.io -n velero

NAME               AGE
guestbook-backup   4m58s

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

Restaurar um aplicativo com monitoramento de estado em execução em um cluster TKG

A restauração de um aplicativo com monitoramento de estado em execução em um cluster TKG envolve a restauração dos metadados do aplicativo e dos dados do aplicativo armazenados em um volume persistente. Para fazer isso, você precisa do Velero e do Restic.

Este exemplo pressupõe que você tenha feito backup do aplicativo de livro de visitas com estado, conforme descrito na seção anterior.

Para testar a restauração do aplicativo com monitoramento de estado, exclua seu namespace:

kubectl delete ns guestbook
namespace "guestbook" deleted

Verificar a exclusão do aplicativo:

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

Para restaurar um aplicativo do backup, use a seguinte sintaxe de comando.

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

Por exemplo:

velero restore create --from-backup guestbook-backup

Você deve ver mensagens semelhantes às seguintes:

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

Verifique se o aplicativo de livro de visitas com estado foi restaurado:

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

Execute o seguinte comando adicional para verificar a restauração:

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>

Verifique se o namespace foi restaurado:

kubectl get ns

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

Verifique se o aplicativo foi restaurado:

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

Verifique se os volumes persistentes foram restaurados:

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 fim, acesse o front-end do livro de visitas usando o IP externo do serviço de front-end do livro de visitas e verifique se as mensagens que você enviou no início do tutorial foram restauradas. Por exemplo:

A lista de mensagens que são restauradas.