Introdução
Assim como em qualquer outro ambiente, 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 pontualmente 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 criar snapshots do estado de sua aplicação antes de realizar operações no sistema de 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 opcionalmente 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 completar 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 releases 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 DO Spaces criado anteriormente na seção Pré-requisitos.
Primeiro, clone o repositório Git do Starter Kit e altere o diretório para sua cópia local:
Em seguida, adicione o repositório Helm e liste os charts disponíveis:
A saída se parecerá com o seguinte:
NAME CHART VERSION APP VERSION DESCRIPTION
vmware-tanzu/velero 2.29.7 1.8.1 A Helm chart for velero
O chart de interesse é vmware-tanzu/velero, que instalará o Velero no cluster. Por favor, visite a página do chart Velero para mais detalhes sobre este chart.
Em seguida, abra e inspecione o arquivo de valores do Helm do Velero fornecido no repositório do Starter Kit usando um editor de sua escolha (de preferência com suporte a lint YAML).
Depois, substitua os espaços reservados <> de acordo com o seu bucket Velero do DO Spaces (como nome, região e segredos). Certifique-se de fornecer também seu token da API DigitalOcean (chave DIGITALOCEAN_TOKEN).
Por fim, instale o Velero usando 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 será semelhante ao 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 se parece com o seguinte (os pods de implantação devem estar no estado Ready):
Se você estiver interessado em explorar mais, pode visualizar os componentes do servidor do Velero:
- Explore as páginas de ajuda do 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 o
Velero:
Liste as opções de comando backup para o Velero:
O Velero usa várias CRDs (Definições de Recursos Personalizados) para representar seus recursos como backups, agendamentos de backups, 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 se nenhum erro é relatado também.
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"
...
Finalmente, dê uma olhada no bucket do DO Spaces e verifique se há uma nova pasta chamada backups que contenha os ativos criados para o seu ambassador-backup:
Excluindo o Namespace e Recursos do Ambassador
Primeiro, simule um desastre deletando 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 do Ambassador Edge Stack sobre as aplicações de backend usadas no tutorial do Starter Kit. Você pode usar o curl para testar (ou pode usar o seu navegador da web):
Restaurando o Backup do Namespace do Ambassador
Restaure o ambassador-backup:
Importante: Ao excluir o namespace ambassador, o recurso balanceador de carga associado ao serviço do embaixador também será excluído. Portanto, ao restaurar o serviço ambassador, o balanceador de carga será recriado pela DigitalOcean. O problema aqui é que você obterá um endereço IP NOVO 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 ambassador-backup restore. Deverá 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:
Obtenha 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 do host totalmente qualificado.
Obtenha 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 se parece com (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 Como Criar os Serviços de Backend da Pilha de Borda do Ambassador.
Na próxima etapa, você simulará um desastre deletando intencionalmente seu cluster DOKS.
Etapa 3 – Exemplo de Backup e Restauração do Cluster Inteiro
Nesta etapa, você 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:
Finalmente, inspecione o estado e os logs do backup (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 em seguida restaurá-lo, o mesmo balanceador de carga com o mesmo IP é 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 o seu controlador de ingresso. Portanto, certifique-se de atualizar seus registros A do DNS da DigitalOcean conforme necessário.
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 junto com o balanceador de carga associado:
Em seguida, recrie o cluster, conforme descrito em Configurar o Kubernetes da DigitalOcean. É importante garantir que a contagem de nós do novo cluster DOKS seja igual ou maior à original.
Em seguida, instale o CLI e o servidor do Velero, conforme descrito na seção de Pré-requisitos e no Passo 1 – Instalando o Velero usando o 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 marcadores <> conforme necessário). Deve dizer 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 Starter Kit.
Na próxima etapa, você aprenderá como realizar backups programados (ou automáticos) para as aplicações do seu cluster DOKS.
Fazer backups automaticamente com base em um cronograma é uma característica realmente útil. Isso permite que você retroceda no tempo e restaure o sistema para um estado de funcionamento anterior se algo der errado.
A criação de um backup programado é um processo muito simples. Um exemplo é fornecido abaixo para um intervalo de 1 minuto (o namespace kube-system foi escolhido).
Primeiro, crie o cronograma:
schedule="*/1 * * * *"
O formato do cronjob do Linux também é suportado:
Em seguida, verifique se o cronograma 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:
Então, inspecione todos os backups após um minuto mais ou menos:
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 Programado
Primeiro, verifique a linha Fase de um dos backups (substitua os espaços reservados <> conforme necessário). Deve dizer Concluído.
Por fim, 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.
Na próxima etapa, você aprenderá como excluir manualmente ou automaticamente backups específicos que você criou ao longo do tempo.
Se você não precisa mais dos backups antigos, pode liberar alguns recursos tanto no cluster Kubernetes quanto no bucket do Velero DO Spaces.
Excluindo um Backup Manualmente
Primeiro, escolha um backup de um minuto, por exemplo, e emita o seguinte comando (substitua os espaços reservados <> de acordo):
Agora, verifique se foi removido 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 selector. 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, bem como do bucket DO Spaces.
Exclusão Automática de Backup via TTL
- Quando você cria um backup, pode especificar um TTL (Tempo de Vida), usando a flag
--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 na nuvem
storage - Todas as capturas de
PersistentVolume
Todos os Restores associados
A flag TTL permite que o usuário especifique 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 do ambassador, usando um valor TTL de 3 minutos:
Em seguida, inspecione o backup do 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 parece semelhante a isto (observe a seção Namespaces -> Included – ela deve exibir ambassador, e o campo TTL está definido para 3ms0):
Finalmente, após cerca de três minutos, 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. Deverá falhar com um erro indicando que o backup não existe mais. A pasta correspondente ambassador-backup-3min-ttl do bucket Velero do DO Spaces também será excluída.