Testando o Veeam Kasten com K3s e Longhorn – Parte 3
A ideia desse artigo é mostrar passo a passo uma forma simplificada e rápida de fazer deploy do K3s com Longhorn e usar o Veeam Kasten para proteger a carga de trabalho que está sendo executada no Kubernetes. É importante frisar que todas as escolhas de design e arquitetura aqui descritas foram pensadas para ser o mais simples possível, com o objetivo bem claro de ter um ambiente funcional para testes da solução de proteção de dados para Kubernetes da Veeam. Não recomendo repetir esses passos para ambientes produtivos.
Para facilitar a leitura, separei o artigo em três partes.
Parte 1 – Instalação e configuração do K3s e Longhorn
Parte 2 – Instalação e configuração básica do Veeam Kasten
Parte 3 – Configuração de politicas de backup no Veeam Kasten (você está aqui)
Agora que já temos o básico para que o Veeam Kasten funciona corretamente, vamos criar uma aplicação para efetuar os testes de backup e restore. A ideia é manter o mesmo padrão e criar um deploy de apache bem simples. Quero proteger o artefato de forma completa, desde o deployment e serviço, até o volume persistente, ingress, secrets, namespace etc. Basta executar o comando abaixo para fazer deploy desse apache. Lembre-se de ajustar com os detalhes pertinentes ao seu ambiente.
kubectl create namespace apache-test cat <<EOF | kubectl apply -f - apiVersion: v1 kind: PersistentVolumeClaim metadata: name: apache-html-pvc namespace: apache-test spec: accessModes: - ReadWriteOnce resources: requests: storage: 200Mi storageClassName: longhorn-single-replica --- apiVersion: apps/v1 kind: Deployment metadata: name: apache-test namespace: apache-test spec: selector: matchLabels: app: apache-test template: metadata: labels: app: apache-test spec: containers: - name: apache image: httpd:2.4 ports: - containerPort: 80 volumeMounts: - name: apache-html mountPath: /usr/local/apache2/htdocs volumes: - name: apache-html persistentVolumeClaim: claimName: apache-html-pvc --- apiVersion: v1 kind: Service metadata: name: apache-test namespace: apache-test spec: selector: app: apache-test ports: - protocol: TCP port: 80 targetPort: 80 --- apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: apache-test-ingress namespace: apache-test spec: ingressClassName: traefik rules: - host: test1.caverna.local http: paths: - path: / pathType: Prefix backend: service: name: apache-test port: number: 80 EOF
Só para enfeitar um pouco, vamos personalizar a página inicial do apache com o comando abaixo:
kubectl exec -n apache-test -it deploy/apache-test -- bash -c 'echo "<h1>Veeam Kasten</h1>" > /usr/local/apache2/htdocs/index.html'
Se tudo foi criado corretamente, então basta abrir o endereço no navegador.
Se navegar no menu esquerdo Application no Veeam Kasten, provavelmente verá o apache-test, default e longhorn-system, todos com a coluna compliance Unmaneged. Ou seja, não está sendo protegido pelo Kasten. No apache-test, clique no três pontos e Create a Policy.
Para testar, vamos manter quase tudo no padrão. Vamos alterar apenas a opção Enable Backups via Snapshot Exports, onde o objetivo é que todos os snapshots sejam enviados para o repositório NFS e use a mesma retenção aplicada ao snapshot.
Esse é um ponto interessante, pois existem configurações de retenção para o snapshot e para os backups que vão para o repositório em si. Sem marcar essa opção e selecionar o repositório, como resultado você teria apenas snapshots e não backups. Após criar a politica ela fica disponível no menu Policies. É esperado que você veja Valid no campo Validation, que o recurso protegido esteja correto e que a ação (Snapshot + Export) esteja correta também.
Agora navegando no menu Applications é possível observar que o apache-test está Compliant, ou seja, está sendo protegido pelo Veeam Kasten.
Perfeito, agora temos uma politica que protege o apache-test. Podemos restaurar a partir do snapshot ou a partir do backup que está armazenado no NFS. Como mostra a imagem abaixo, já concluimos com sucesso o primeiro backup.
Muito bonito, tudo verdinho 🙂 mas eu quero validar se consigo restaurar tudo no caso de perder a minha aplicação inteira. Afinal de contas, é isso que a Veeam faz de melhor. Então, vamos destruir o apache-test por completo: deployment, services, namespace, tudo. Basta executar o código apocalíptico abaixo:
kubectl delete all --all -n apache-test kubectl delete ingress apache-test-ingress -n apache-test kubectl delete pvc apache-html-pvc -n apache-test kubectl delete namespace apache-test
Se eu navegar até Applications não consigo mais ver o apache-test, mas se for até Restore Points, é possível ver dois tipos: Exported e Snapshot. Adivinha qual dos dois vai me salvar agora?
Se você falou exported, acertou em cheio! É esse o ponto de restauração que está armazenado no NFS e que não foi removido junto com a aplicação. Então vamos iniciar o processo de restauração. Obs: o cadeado aberto ao lado do nome do repositório serve para nos lembrar que o repositório não é imutável, ou seja, não recomendado para ambientes produtivos (sim, vou repetir isso mais mil vezes se for preciso).
Ao iniciar o restore, a primeira coisa que vemos é uma caixa verde informando que o restore point em questão está fora do cluster (ufaaa) e que a restauração pode precisar de mais tempo para trazer os dados, importar e fazer a restauração em si.
O que importa mesmo está aqui. Eu posso escolher exatamente o que eu quero restaurar. No meu caso não tenho muita escolha porque eu removi TUDO. Então eu seleciono todos os itens e restauro. Mas em outra situação, eu poderia selecionar granularmente apenas um volume, service, ingress etc.
E é isso, restauração concluida com sucesso. Minha aplicação foi restaurada exatamente como estava anteriormente. Com isso temos um ambiente completamente funcional para testar o Veeam Kasten, fazer backups e restaurações e ter a possibilidade de conhecer um pouco mais sobre esta fantastica solução de proteção para ambientes Kubernetes.
É isso aí, pessoal. O artigo ficou longo, mas o objetivo era fazer algo bem completo. Até a próxima!