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
E:
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.