Recentemente escrevi um artigo separado em três partes sobre como testar o Veeam Kasten com K3s e Longhorn, nesse caso, poderia existir a persistência dos dados dos pods, visto que o Longhorn seria o responsável por cuidar dos volumes dos pods. Entretanto, existem cenários onde o cliente não precisa de persistência no pod e por este motivo nem seria necessário configurar o Longhorn, vSphere CSI, Ceph ou qualquer outro provedor de volumes persistentes. O ambiente se torna muito mais simples e o Kasten garantiria a proteção dos dados sem nenhum tipo de snapshots. Então a ideia é explorar um pouco mais esse conceito aqui.

Vamos preparar o ambiente, instalar o nfs, kubectl, k3s e o helm.

swapoff -a sed -i '/ swap / s/^/#/' /etc/fstab

apt install -y nfs-common

snap install kubectl --classic

curl -sfL https://get.k3s.io | sh -

kubectl get nodes

cp /etc/rancher/k3s/k3s.yaml ~/.kube/config
chown $USER:$USER ~/.kube/config

k3s check-config

curl https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 | bash

Importante garantir que o K3s está operacional antes de seguir. Como vamos usar o disco local, então o local-path que é configurado junto com o K3s é suficiente e nenhuma ação adicional se faz necessária. Um teste que pode ser feito é executar o comando abaixo para validar que o local-path está como padrão. A resposta esperada é local-path (default).

kubectl get storageclass

Vamos partir para o pre-flight e depois a instalação do Kasten.

helm repo add kasten https://charts.kasten.io
helm repo update

curl https://docs.kasten.io/downloads/8.0.3/tools/k10_primer.sh | bash

E o resultado esperado é que o cluster não possui CSI implementado, mas os outros itens foram validados com sucesso. Tem um ponto importante aqui que vale a pena mencionar. O Generic Volume Backup (GVB) e o Generic Volume Snapshot (GVS) são suportados apenas em casos onde o ambiente está sendo migrado para usar um driver CSI, ou seja, é algo habilitado com a ajuda do suporte da Veeam e a ideia é que seja usado de forma temporária (mais detalhes aqui). No nosso exemplo aqui, os pods não tem persistência, então o GVB/GVS são irrelevantes.

Ok, então como que o Kasten protege os pods? É possível proteger a carga de trabalho com a ajuda de outros pods temporarios que o Kasten faz deploy (create-repo-*, repo-access-kopia-volumedata-repository-*, repo-access-kopia-metadata-repository-* e data-mover-svc-*) e com isso temos a proteção completa (deployment, configmaps, secrets, services, ingress, namespace etc). E como não temos volumes nos pods, é esperado que o data-mover-svc-* termine com erro. Vaaamos voltar ao deploy do Kasten.

Show, agora sim seguimos com a instalação do Kasten. Para o artigo não ficar repetitivo, recomendo a leitura desses dois artigos: Instalação e configuração básica do Veeam Kasten e Configuração de politicas de backup no Veeam Kasten (lembre-se de remover a parte de volume do apache-test no momento do deploy).

Você já sabe, mas não custa lembrar. Se os pods possuirem volumes, então você precisa instalar um driver CSI, caso contrário, o Kasten não conseguirá proteger o ambiente. É isso, até a próxima!