Introdução
Assim como em qualquer outra configuração, os dados em um cluster Kubernetes podem estar em risco de serem perdidos. Para evitar problemas graves, é essencial ter um plano de recuperação de dados em mãos. Uma maneira simples e eficaz de fazer isso é fazendo backups, garantindo que seus dados estejam seguros em caso de eventos inesperados. Os backups podem ser executados uma vez ou agendados. É uma boa ideia ter backups agendados para garantir que você tenha um backup recente para recorrer facilmente.
O Velero – uma ferramenta de código aberto projetada para ajudar nas operações de backup e restauração para clusters Kubernetes. É ideal para o caso de recuperação de desastres, bem como para tirar snapshots do estado de sua aplicação antes de realizar operações no sistema do seu cluster, como atualizações. Para mais detalhes sobre este tópico, por favor, visite a página oficial Como Funciona o Velero.
Neste tutorial, você aprenderá como implantar o Velero em seu cluster Kubernetes, criar backups e recuperar um backup se algo der errado. Você pode fazer backup de todo o seu cluster ou optar por escolher um namespace ou seletor de rótulo para fazer backup do seu cluster.
Tabela de Conteúdos
- Pré-requisitos
- Passo 1 – Instalando Velero usando Helm
- Passo 2 – Exemplo de Backup e Restauração de Namespace
- Passo 3 – Exemplo de Backup e Restauração de Cluster Inteiro
- Passo 4 – Backups Agendados
- Passo 5 – Excluindo Backups
Pré-requisitos
Para concluir este tutorial, você precisa do seguinte:
- A DO Spaces Bucket and access keys. Save the access and secret keys in a safe place for later use.
- A DigitalOcean API token for Velero to use.
- A Git client, to clone the Starter Kit repository.
- Helm para gerenciar lançamentos e atualizações do Velero.
- Doctl para interação com a API da DigitalOcean.
- Kubectl para interação com o Kubernetes.
- Cliente Velero para gerenciar backups do Velero.
Passo 1 – Instalando Velero usando Helm
Nesta etapa, você implantará o Velero e todos os componentes necessários, para que ele possa realizar backups dos recursos do seu cluster Kubernetes (incluindo PVs). Os dados de backup serão armazenados no bucket DO Spaces criado anteriormente na seção Pré-requisitos.
Primeiro, clone o repositório Git do Starter Kit e mude para o diretório da sua cópia local:
Em seguida, adicione o repositório Helm e liste os gráficos disponíveis:
A saída se parece com o seguinte:
NAME CHART VERSION APP VERSION DESCRIPTION
vmware-tanzu/velero 2.29.7 1.8.1 A Helm chart for velero
O gráfico de interesse é vmware-tanzu/velero, que instalará o Velero no cluster. Por favor, visite a página do velero-chart para mais detalhes sobre este gráfico.
Em seguida, abra e inspecione o arquivo de valores Helm do Velero fornecido no repositório Starter Kit usando um editor de sua escolha (preferencialmente com suporte a lint YAML).
Depois, substitua os espaços reservados <> de acordo com o seu bucket Velero DO Spaces (como nome, região e segredos). Certifique-se de fornecer também seu token de API DigitalOcean (chave DIGITALOCEAN_TOKEN).
Por fim, instale o Velero usando o helm:
A specific version of the Velero Helm chart is used. In this case 2.29.7 is picked, which maps to the 1.8.1 version of the application (see the output from Step 2.). It’s a good practice in general to lock on a specific version. This helps to have predictable results and allows versioning control via Git.
–create-namespace \
Agora, verifique sua implantação do Velero executando:
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
velero velero 1 2022-06-09 08:38:24.868664 +0300 EEST deployed velero-2.29.7 1.8.1
A saída se parece com o seguinte (a coluna STATUS deve exibir deployed):
Em seguida, verifique se o Velero está funcionando:
NAME READY UP-TO-DATE AVAILABLE AGE
velero 1/1 1 1 67s
A saída parece semelhante ao seguinte (os pods de implantação devem estar no estado Ready):
Se estiver interessado em investigar mais, pode visualizar os componentes do servidor do Velero:
- Explore as páginas de ajuda da CLI do Velero para ver quais comandos e subcomandos estão disponíveis. Você pode obter ajuda para cada um usando a flag
--help: - Liste todos os comandos disponíveis para
Velero:
Liste as opções do comando backup para Velero:
O Velero usa vários CRDs (Definições de Recursos Personalizadas) para representar seus recursos como backups, programações de backup, etc. Você descobrirá cada um nos próximos passos do tutorial, juntamente com alguns exemplos básicos.
Passo 2 – Exemplo de Backup e Restauração de Namespace
Nesta etapa, você aprenderá como realizar um backup único de um namespace inteiro do seu cluster DOKS e restaurá-lo posteriormente, garantindo que todos os recursos sejam recriados. O namespace em questão é ambassador.
Criando o Backup do Namespace Ambassador
Primeiro, inicie o backup:
Em seguida, verifique se o backup foi criado:
NAME STATUS ERRORS WARNINGS CREATED EXPIRES STORAGE LOCATION SELECTOR
ambassador-backup Completed 0 0 2021-08-25 19:33:03 +0300 EEST 29d default <none>
A saída se parece com:
Depois, após alguns momentos, você pode inspecioná-lo:
Name: ambassador-backup
Namespace: velero
Labels: velero.io/storage-location=default
Annotations: velero.io/source-cluster-k8s-gitversion=v1.21.2
velero.io/source-cluster-k8s-major-version=1
velero.io/source-cluster-k8s-minor-version=21
Phase: Completed
Errors: 0
Warnings: 0
Namespaces:
Included: ambassador
Excluded: <none>
...
- A saída se parece com:
- Procure pela linha
Fase. Deve dizerConcluído. - Verifique também se nenhum erro é relatado.
Um novo objeto de backup do Kubernetes é criado:
~ kubectl get backup/ambassador-backup -n velero -o yaml
apiVersion: velero.io/v1
kind: Backup
metadata:
annotations:
velero.io/source-cluster-k8s-gitversion: v1.21.2
velero.io/source-cluster-k8s-major-version: "1"
velero.io/source-cluster-k8s-minor-version: "21"
...
Por fim, dê uma olhada no bucket do DO Spaces e verifique se há uma nova pasta chamada backups, que contém os ativos criados para o seu ambassador-backup:
Excluindo o Namespace e Recursos do Ambassador
Primeiro, simule um desastre excluindo intencionalmente o namespace ambassador:
Em seguida, verifique se o namespace foi excluído (a listagem de namespaces não deve imprimir ambassador):
Por fim, verifique se o endpoint dos serviços de backend echo e quote está DOWN. Consulte Criando os Serviços de Backend da Pilha de Borda do Ambassador em relação às aplicações de backend usadas no tutorial do Kit Inicial. Você pode usar o curl para testar (ou pode usar seu navegador da web):
Restaurando o Backup do Namespace do Ambassador
Restaure o ambassador-backup:
Importante: Quando você deleta o namespace ambassador, o recurso do balanceador de carga associado ao serviço de embaixador também será deletado. Então, quando você restaurar o serviço ambassador, o balanceador de carga será recriado pela DigitalOcean. O problema aqui é que você obterá um NOVO endereço IP para o seu balanceador de carga, então você precisará ajustar os registros A para direcionar o tráfego para seus domínios hospedados no cluster.
Verificando a Restauração do Namespace do Embaixador
Para verificar a restauração do namespace ambassador, verifique a linha Fase da saída do comando de restauração ambassador-backup. Deve dizer Concluído (também, por favor, observe a seção de Avisos – ela informa se algo deu errado):
Em seguida, verifique se todos os recursos foram restaurados para o namespace ambassador. Procure pelos pods ambassador, serviços e implantações.
NAME READY STATUS RESTARTS AGE
pod/ambassador-5bdc64f9f6-9qnz6 1/1 Running 0 18h
pod/ambassador-5bdc64f9f6-twgxb 1/1 Running 0 18h
pod/ambassador-agent-bcdd8ccc8-8pcwg 1/1 Running 0 18h
pod/ambassador-redis-64b7c668b9-jzxb5 1/1 Running 0 18h
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/ambassador LoadBalancer 10.245.74.214 159.89.215.200 80:32091/TCP,443:31423/TCP 18h
service/ambassador-admin ClusterIP 10.245.204.189 <none> 8877/TCP,8005/TCP 18h
service/ambassador-redis ClusterIP 10.245.180.25 <none> 6379/TCP 18h
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/ambassador 2/2 2 2 18h
deployment.apps/ambassador-agent 1/1 1 1 18h
deployment.apps/ambassador-redis 1/1 1 1 18h
NAME DESIRED CURRENT READY AGE
replicaset.apps/ambassador-5bdc64f9f6 2 2 2 18h
replicaset.apps/ambassador-agent-bcdd8ccc8 1 1 1 18h
replicaset.apps/ambassador-redis-64b7c668b9 1 1 1 18h
A saída se parece com:
Obter hosts do embaixador:
NAME HOSTNAME STATE PHASE COMPLETED PHASE PENDING AGE
echo-host echo.starter-kit.online Ready 11m
quote-host quote.starter-kit.online Ready 11m
A saída se parece com:
ESTADO deve ser Pronto e a coluna NOME DO HOST deve apontar para o nome de host totalmente qualificado.
Obter mapeamentos do embaixador:
NAME SOURCE HOST SOURCE PREFIX DEST SERVICE STATE REASON
ambassador-devportal /documentation/ 127.0.0.1:8500
ambassador-devportal-api /openapi/ 127.0.0.1:8500
ambassador-devportal-assets /documentation/(assets|styles)/(.*)(.css) 127.0.0.1:8500
ambassador-devportal-demo /docs/ 127.0.0.1:8500
echo-backend echo.starter-kit.online /echo/ echo.backend
quote-backend quote.starter-kit.online /quote/ quote.backend
A saída parece semelhante a (observe o echo-backend que está mapeado para o host echo.starter-kit.online e o prefixo de origem /echo/, o mesmo para quote-backend):
Finalmente, após reconfigurar seu balanceador de carga e as configurações de domínio do DigitalOcean, verifique se o endpoint dos serviços de backend echo e quote está UP. Consulte Criando os Serviços de Backend do Ambassador Edge Stack.
No próximo passo, você irá simular um desastre deletando intencionalmente o seu cluster DOKS.
Passo 3 – Exemplo de Backup e Restauração do Cluster Inteiro
Neste passo, você irá simular um cenário de recuperação de desastre. O cluster DOKS inteiro será deletado e então restaurado a partir de um backup anterior.
Criando o Backup do Cluster DOKS
Primeiro, crie um backup para o cluster DOKS inteiro:
Em seguida, verifique se o backup foi criado e não está relatando nenhum erro. O seguinte comando lista todos os backups disponíveis:
NAME STATUS ERRORS WARNINGS CREATED EXPIRES STORAGE LOCATION SELECTOR
all-cluster-backup Completed 0 0 2021-08-25 19:43:03 +0300 EEST 29d default <none>
A saída se parece com:
Por fim, inspecione o estado do backup e os logs (verifique se não há erros relatados):
Importante: Sempre que você destruir um cluster DOKS sem especificar a flag --dangerous para o comando doctl e depois restaurá-lo, o mesmo balanceador de carga com o mesmo IP será recriado. Isso significa que você não precisa atualizar seus registros A do DNS da DigitalOcean.
Mas quando a flag --dangerous é aplicada ao comando doctl, o balanceador de carga existente será destruído e um novo balanceador de carga com um novo IP externo será criado quando o Velero restaurar seu controlador de entrada. Portanto, certifique-se de atualizar seus registros A do DNS da DigitalOcean de acordo.
Primeiro, exclua todo o cluster DOKS (certifique-se de substituir os espaços reservados <> conforme necessário).
Para excluir o cluster Kubernetes sem destruir o balanceador de carga associado, execute:
Ou para excluir o cluster Kubernetes juntamente com o balanceador de carga associado:
Em seguida, recrie o cluster, conforme descrito em Configurar o Kubernetes da DigitalOcean. É importante garantir que o novo número de nós do cluster DOKS seja igual ou maior ao original.
Em seguida, instale o Velero CLI e o servidor, conforme descrito na seção de Pré-requisitos e no Passo 1 – Instalando o Velero usando Helm, respectivamente. É importante usar a mesma versão do Helm Chart.
Por fim, restaure tudo executando o seguinte comando:
Verificando o Estado das Aplicações do Cluster DOKS
Primeiro, verifique a linha Fase do comando de descrição de restauração do all-cluster-backup. (Substitua os espaços reservados <> conforme necessário). Deve mostrar Concluído.
Agora, verifique todos os recursos do cluster executando:
Agora, as aplicações de backend devem responder às solicitações HTTP também. Consulte Criando os Serviços de Backend da Pilha de Borda do Embaixador em relação às aplicações de backend usadas no tutorial do Kit Inicial.
Na próxima etapa, você aprenderá como realizar backups agendados (ou automáticos) para suas aplicações de cluster DOKS.
Fazer backups automaticamente com base em um cronograma é uma funcionalidade realmente útil. Isso permite que você volte no tempo e restaure o sistema para um estado de funcionamento anterior caso algo dê errado.
A criação de um backup agendado é um processo muito simples. Um exemplo é fornecido abaixo para um intervalo de 1 minuto (o namespace kube-system foi escolhido).
Primeiro, crie o agendamento:
schedule="*/1 * * * *"
O formato de cronjob do Linux também é suportado:
Em seguida, verifique se o agendamento foi criado:
NAME STATUS CREATED SCHEDULE BACKUP TTL LAST BACKUP SELECTOR
kube-system-minute-backup Enabled 2021-08-26 12:37:44 +0300 EEST @every 1m 720h0m0s 32s ago <none>
A saída se parece com:
Depois, inspecione todos os backups após cerca de um minuto:
NAME STATUS ERRORS WARNINGS CREATED EXPIRES STORAGE LOCATION SELECTOR
kube-system-minute-backup-20210826093916 Completed 0 0 2021-08-26 12:39:20 +0300 EEST 29d default <none>
kube-system-minute-backup-20210826093744 Completed 0 0 2021-08-26 12:37:44 +0300 EEST 29d default <none>
A saída se parece com:
Verificando o estado do Backup Agendado
Primeiro, verifique a linha Fase de um dos backups (por favor, substitua os espaços reservados <> conforme necessário). Deve mostrar Concluído.
Finalmente, tome nota de possíveis erros e avisos da saída acima também para verificar se algo deu errado.
Para restaurar backups de um minuto atrás, siga os mesmos passos que você aprendeu nas etapas anteriores deste tutorial. Esta é uma boa maneira de exercitar e testar sua experiência acumulada até agora.
No próximo passo, você aprenderá como excluir manualmente ou automaticamente backups específicos que você criou ao longo do tempo.
Se você não precisa de backups mais antigos, você pode liberar alguns recursos tanto no cluster Kubernetes quanto no bucket Velero DO Spaces.
Excluindo um Backup Manualmente
Primeiro, escolha um backup de um minuto, por exemplo, e emita o seguinte comando (por favor, substitua os espaços reservados <> adequadamente):
Agora, verifique se desapareceu da saída do comando velero backup get. Deve ser excluído também do bucket DO Spaces.
Em seguida, você irá excluir vários backups de uma vez usando um seletor. O subcomando velero backup delete fornece uma flag chamada --selector. Isso permite que você exclua vários backups de uma vez com base em rótulos do Kubernetes. As mesmas regras se aplicam aos Seletores de Rótulos do Kubernetes.
Primeiro, liste os backups disponíveis:
NAME STATUS ERRORS WARNINGS CREATED EXPIRES STORAGE LOCATION SELECTOR
ambassador-backup Completed 0 0 2021-08-25 19:33:03 +0300 EEST 23d default <none>
backend-minute-backup-20210826094116 Completed 0 0 2021-08-26 12:41:16 +0300 EEST 24d default <none>
backend-minute-backup-20210826094016 Completed 0 0 2021-08-26 12:40:16 +0300 EEST 24d default <none>
backend-minute-backup-20210826093916 Completed 0 0 2021-08-26 12:39:16 +0300 EEST 24d default <none>
backend-minute-backup-20210826093816 Completed 0 0 2021-08-26 12:38:16 +0300 EEST 24d default <none>
backend-minute-backup-20210826093716 Completed 0 0 2021-08-26 12:37:16 +0300 EEST 24d default <none>
backend-minute-backup-20210826093616 Completed 0 0 2021-08-26 12:36:16 +0300 EEST 24d default <none>
backend-minute-backup-20210826093509 Completed 0 0 2021-08-26 12:35:09 +0300 EEST 24d default <none>
A saída se parece com:
Em seguida, diga que deseja excluir todos os ativos backend-minute-backup-*. Escolha um backup da lista e inspecione os Rótulos:
Name: backend-minute-backup-20210826094116
Namespace: velero
Labels: velero.io/schedule-name=backend-minute-backup
velero.io/storage-location=default
Annotations: velero.io/source-cluster-k8s-gitversion=v1.21.2
velero.io/source-cluster-k8s-major-version=1
velero.io/source-cluster-k8s-minor-version=21
Phase: Completed
Errors: 0
Warnings: 0
Namespaces:
Included: backend
Excluded: <none>
...
A saída se parece com (observe o valor do rótulo velero.io/schedule-name):
Em seguida, você pode excluir todos os backups que correspondem ao valor backend-minute-backup do rótulo velero.io/schedule-name:
Por fim, verifique se todos os ativos backend-minute-backup-* desapareceram da saída do comando velero backup get e também do bucket DO Spaces.
Exclusão Automática de Backup via TTL
- Quando você cria um backup, pode especificar um TTL (Tempo Para Viver), usando a opção
--ttl. Se o Velero perceber que um recurso de backup existente expirou, ele remove: - O recurso
Backup - O arquivo de backup do armazenamento de objeto em nuvem
storage - Todas as capturas de
PersistentVolume
Todas as Restores associadas
A opção TTL permite ao usuário especificar o período de retenção do backup com o valor especificado em horas, minutos e segundos no formato --ttl 24h0m0s. Se não especificado, um valor TTL padrão de 30 dias será aplicado.
Primeiro, crie o backup ambassador, usando um valor TTL de 3 minutos:
Em seguida, inspecione o backup ambassador:
Name: ambassador-backup-3min-ttl
Namespace: velero
Labels: velero.io/storage-location=default
Annotations: velero.io/source-cluster-k8s-gitversion=v1.21.2
velero.io/source-cluster-k8s-major-version=1
velero.io/source-cluster-k8s-minor-version=21
Phase: Completed
Errors: 0
Warnings: 0
Namespaces:
Included: ambassador
Excluded: <none>
Resources:
Included: *
Excluded: <none>
Cluster-scoped: auto
Label selector: <none>
Storage Location: default
Velero-Native Snapshot PVs: auto
TTL: 3m0s
...
A new folder should be created in the DO Spaces Velero bucket as well, named ambassador-backup-3min-ttl.
A saída se parece com isso (observe a seção Namespaces -> Incluído – ela deve exibir ambassador, e o campo TTL está definido para 3ms0):
Finalmente, após três minutos ou algo parecido, o backup e os recursos associados devem ser excluídos automaticamente. Você pode verificar que o objeto de backup foi destruído usando: velero backup describe ambassador-backup-3min-ttl. Deve falhar com um erro indicando que o backup não existe mais. A pasta correspondente ambassador-backup-3min-ttl do bucket Velero Spaces DO será excluída também.