Testando o Veeam Kasten com K3s e Longhorn – Parte 2
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 (você está aqui)
Parte 3 – Configuração de politicas de backup no Veeam Kasten
Sem mais delongas, vamos iniciar a instalação do Veeam Kasten.
helm repo add kasten https://charts.kasten.io/ helm repo update
Na verdade, antes de instalar o Kasten vamos rodar o pre-flight para validar se está tudo OK. Para isso, adicione o repositório do Kasten (comandos helm acima) e vamos executar o pre-flight.
curl https://docs.kasten.io/downloads/8.0.2/tools/k10_primer.sh | bash
Essa é uma forma bem inteligente que a Veeam faz para validar o ambiente antes da instação do Kasten. São realizados diversos testes para garantir que os pré-requisitos foram atendidos, como validações das permissões, versão mínima de kubernetes, capacidade do CSI, classes de storage e até o deploy dos pods visando entender se existiria algum problema para subir tudo. Após concluir, tudo é desfeito e um relatório é exibido. Abaixo compartilho uma parte desse relatório:
Perfeito, agora sim podemos seguir para a instalação do Veeam Kasten. Lembre-se que o Veeam Kasten é gratuito para até 5 nodes. De qualquer forma, uma licença trial de 30 dias incluida, assim é possível testar todas as funcionalidades avançadas do Kasten 🙂
helm install k10 kasten/k10 \ --namespace kasten-io \ --create-namespace \ --set prometheus.server.persistentVolume.size=4Gi \ --set global.persistence.size=8Gi \ --set limiter.executorReplicas=1 \ --kubeconfig /etc/rancher/k3s/k3s.yaml
O deploy padrão poderia ser algo como helm install k10 kasten/k10 –namespace=kasten-io, mas aqui estamos reduzindo o tamanho do volume dos containers, criando o namespace kasten-io, apontando para o kubeconfig do k3s e limitando em uma réplica (a storage class que definimos como padrão já possui essa configuração, mas quis reforçar aqui de qualquer forma).
Se você executou kubectl get pods -n kasten-io e todos os pods estão rodando, então podemos configurar o ingress para ter o acesso a interface gráfica do Kasten.
cat <<EOF | kubectl apply -f - apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: kasten-traefik-ingress namespace: kasten-io annotations: traefik.ingress.kubernetes.io/router.entrypoints: web spec: ingressClassName: traefik rules: - host: kasten.caverna.local http: paths: - path: / pathType: Prefix backend: service: name: gateway port: number: 80 EOF
A URL de acesso é o hostname que você definiu no yaml + /k10/#. No meu caso, ficou http://kasten.caverna.local/k10/#. Ao acessar pela primeira vez será necessário digitar o e-mail, nome da empresa e aceitar os termos.
A primeira coisa que eu recomendo fazer é navegar até Settings > System Information e na parte de Storage Classes selecionar longhorn-single-replica e validar (botão no canto direito superior). É esperado que após alguns segundos o status fique como Valid. Se isso acontecer, então estamos prontos para começar as configurações para proteger o ambiente Kubernetes com Veeam Kasten 🙂
Sem nenhuma configuração adicional, eu poderia navegar até Applications e começar a fazer snapshots da aplicações, mas sabemos que isso não é backup. Na prática, o snapshot fica junto com o volume e no momento que o volume é removido, o snapshot também é removido.
Então, para ficarmos protegidos, é necessário fornecer um local externo para o Kasten armazenar esses snapshots. Se navegarmos até Profiles > Location > Create New Profile veremos que existem muitas opções.
Seguindo o padrão de escolhas simplificadas, vamos selecionar NFS/SMB. Lembre-se que isso não é recomendado para ambientes produtivos devido a impossibilidade de ter imutabilidade, algo que é fundamental para termos a verdadeira proteção do ambiente. Altamente recomendo usar o Veeam Data Cloud Vault ou apontar para os seus repositórios no Veeam Backup & Replication.
O que precisamos fazer aqui é criar um PersistentVolume (PV) e um PersistenteVolumeClaim (PVC). Ok, mas o que isso significa? Pensa que o Kasten precisa guardar os backups em algum lugar e no nosso caso, esse lugar é um servidor de arquivos NFS. O fato é que o Kubernetes não entende o compartilhamento NFS direto, ele só consegue entender isso por meio de recursos e é exatamente aí que o PV e PVC entram. O PV vai basicamente fazer um mapa fixo dizendo “isso aqui é um pedaço de NFS que você pode usar” e o Kasten se beneficia do PVC para de fato “usar aquele pedaço”. Em resumo, são peças fundamentais para que o Kasten consiga ler e gravar os dados no NFS. Basta rodar esse comando para criar os recursos. Lembre-se de ajustar o yaml com os detalhes do seu ambiente.
cat <<EOF | kubectl apply -f - apiVersion: v1 kind: PersistentVolume metadata: name: truenas-nfs spec: capacity: storage: 100Gi volumeMode: Filesystem accessModes: - ReadWriteMany persistentVolumeReclaimPolicy: Retain mountOptions: - hard - nfsvers=4.1 nfs: server: 192.168.10.3 path: /mnt/Caverna_Pool_01/shares/lab-kubernetes --- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: truenas-nfs namespace: kasten-io spec: volumeName: truenas-nfs accessModes: - ReadWriteMany resources: requests: storage: 100Gi storageClassName: "" EOF
Valide se o PV e PVC foram criados corretamente usando os comandos abaixo para listar. É esperado que o status seja Bound e o access mode seja RWX.
kubectl get pvc -n kasten-io kubectl get pv truenas-nfs
Após o sucesso na criação dos recursos, vamos criar um novo location profile.
Informe o nome do recurso e o caminho, exatamente como foi criado anteriormente no PV e PVC.
Se os recursos foram criados e informados corretamente, então o Kasten conseguirá usar e para finalizar basta clicar em Submit.
Por fim, importante garantir que a coluna esteja com sucesso. E veja como a coluna imutabilidade deixa claro que não existe imutabilidade nesse repositório, ou seja, pode ser usado para testes e laboratório, mas jamais em ambientes produtivos.
Pronto. Agora podemos começar criar as politicas para proteger o ambiente Kubernetes. Faremos isso na parte 3 deste artigo. Até mais.