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.3/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:

Além da versão mínima do kubernetes e capacidade computacional para subir os pods, o teste mais importante aqui é sobre as capacidades do driver CSI. 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.