Faça backup de Kubernetes de verdade: snapshots do etcd do k3s enviados para S3, Velero para namespaces e volumes, e como testar a restauração.

Para que serve

Um backup de Kubernetes completo tem duas partes: o estado do cluster (todos os objetos guardados no etcd: deployments, secrets, certificados, configurações) e os dados dos volumes (bancos, uploads). Este artigo mostra como proteger as duas no k3s: snapshots do etcd, automáticos e enviados para um armazenamento S3, e o Velero, que faz backup e restauração por namespace, inclusive do conteúdo dos PVCs. Lembre-se: sem o serviço de Gerenciamento contratado, o backup do que roda no servidor é responsabilidade sua.

Para a política geral (regra 3-2-1, retenção e testes), veja Como montar a política de backup do seu servidor dedicado. Se o cluster roda em VMs no Proxmox, o backup das VMs (veja Backup das VMs no Proxmox com vzdump e Proxmox Backup Server) é uma camada extra, mas não substitui o que está aqui: restaurar uma única VM de um cluster etcd pode trazê-la com dados divergentes das outras.

Pré-requisitos

  • Cluster k3s com etcd embutido (instalado com cluster-init; veja Como instalar o k3s em servidor dedicado).
  • Um bucket S3 fora deste servidor: outro servidor com MinIO/Garage ou um provedor compatível com S3. Tenha endpoint, bucket, access key e secret key.
  • Cópia do token do cluster: /var/lib/rancher/k3s/server/token. Sem ele, um snapshot não pode ser restaurado em máquinas novas. Guarde-o no seu cofre de senhas.
Nó único com SQLite: se você instalou o k3s sem cluster-init, o banco é SQLite e os comandos de etcd-snapshot não se aplicam. Nesse caso, copie /var/lib/rancher/k3s/server/db/ e o token com o k3s parado, ou migre para etcd reiniciando o servidor com cluster-init: true no config.yaml.

Etapa 1: snapshots automáticos do etcd para S3

Por padrão o k3s já tira snapshots às 00h e 12h e mantém 5 por servidor, em /var/lib/rancher/k3s/server/db/snapshots. O problema: ficam no mesmo disco. Acrescente ao /etc/rancher/k3s/config.yaml de cada servidor:

etcd-snapshot-schedule-cron: "0 */6 * * *"
etcd-snapshot-retention: 12
etcd-s3: true
etcd-s3-endpoint: s3.seuprovedor.com
etcd-s3-bucket: k3s-backup
etcd-s3-folder: cluster-producao
etcd-s3-access-key: SUA_ACCESS_KEY
etcd-s3-secret-key: SUA_SECRET_KEY

Reinicie um servidor por vez (systemctl restart k3s). Proteja o arquivo com chmod 600, pois ele tem credenciais. Tire um snapshot manual para validar:

k3s etcd-snapshot save --name antes-da-mudanca
k3s etcd-snapshot ls

A lista deve mostrar o snapshot local e a cópia no S3. Faça um snapshot manual antes de cada atualização do k3s.

Etapa 2: restaurar o etcd (desastre ou erro grave)

Atenção: a restauração volta o cluster inteiro ao momento do snapshot; tudo o que foi criado depois some. Use para desastres, não para recuperar um único objeto (para isso use o Velero). Faça com acesso pelo console IPMI/iLO ou console do Proxmox, caso algo dê errado com a rede.
  1. Pare o k3s em todos os servidores: systemctl stop k3s.
  2. No primeiro servidor, restaure (com o token original, se for uma máquina nova): 
    k3s server --cluster-reset \
  --cluster-reset-restore-path=/var/lib/rancher/k3s/server/db/snapshots/NOME-DO-SNAPSHOT \
  --token=TOKEN_ORIGINAL
    Para baixar direto do S3, acrescente as mesmas opções --etcd-s3... e informe só o nome do snapshot. Quando o comando terminar, inicie: systemctl start k3s.
  3. Nos demais servidores, apague o banco antigo e inicie, para que entrem de novo no cluster restaurado: 
    rm -rf /var/lib/rancher/k3s/server/db/
systemctl start k3s

Etapa 3: instalar o Velero

O Velero 1.18 usa o plugin AWS 1.14 para qualquer armazenamento compatível com S3. Na máquina de administração:

# CLI (confira a versão mais recente em github.com/velero-io/velero/releases)
wget https://github.com/velero-io/velero/releases/download/v1.18.2/velero-v1.18.2-linux-amd64.tar.gz
tar xzf velero-v1.18.2-linux-amd64.tar.gz
install velero-v1.18.2-linux-amd64/velero /usr/local/bin/

cat > credentials-velero <<'EOF'
[default]
aws_access_key_id=SUA_ACCESS_KEY
aws_secret_access_key=SUA_SECRET_KEY
EOF

velero install \
  --provider aws \
  --plugins velero/velero-plugin-for-aws:v1.14.4 \
  --bucket velero-backup \
  --secret-file ./credentials-velero \
  --backup-location-config region=us-east-1,s3ForcePathStyle="true",s3Url=https://s3.seuprovedor.com \
  --use-volume-snapshots=false \
  --use-node-agent \
  --default-volumes-to-fs-backup

rm credentials-velero

O --use-node-agent com --default-volumes-to-fs-backup faz o Velero copiar o conteúdo de todos os volumes montados nos pods, com o Kopia (deduplicado e incremental). Alguns provedores S3 exigem também checksumAlgorithm="" na lista de --backup-location-config.

Volumes do local-path: por padrão o local-path do k3s cria volumes do tipo hostPath, que o backup de sistema de arquivos do Velero ignora. Para PVCs novos, adicione a anotação volumeType: local no PVC; volumes do Longhorn são suportados normalmente. Confirme sempre no relatório do backup que os volumes foram incluídos.

Etapa 4: criar backups e agendamentos

# backup avulso de um namespace
velero backup create site-manual --include-namespaces site --wait

# agendamento diário às 3h, guardando por 14 dias, de todos os namespaces
velero schedule create diario --schedule="0 3 * * *" --ttl 336h0m0s \
  --exclude-namespaces kube-system,velero

velero backup get

Bancos de dados gravando durante a cópia podem gerar backup inconsistente. Para eles, use também o dump nativo (pg_dump, mysqldump) ou os hooks de pré-backup do Velero para congelar a escrita.

Como saber se funcionou

Backup só vale se a restauração foi testada. Restaure em outro namespace, sem afetar o original:

velero backup describe site-manual --details
velero restore create teste-restore --from-backup site-manual \
  --namespace-mappings site:site-teste --wait
kubectl -n site-teste get pods,pvc

O describe deve mostrar Phase: Completed e a lista de volumes copiados; no namespace site-teste, os pods devem subir com os dados. Apague depois com kubectl delete ns site-teste. Repita o teste periodicamente e anote o tempo que leva.

Problemas comuns

Backup em PartiallyFailed

Veja velero backup logs NOME | grep -i error. Causas comuns: pod sem node-agent no nó (confira kubectl -n velero get pods -o wide) ou volume em estado inválido.

BackupStorageLocation Unavailable

Credenciais, endpoint ou bucket errados, ou o servidor não alcança o S3. Teste com velero backup-location get e revise o s3Url e o s3ForcePathStyle.

Snapshot do etcd não aparece no S3

Confira journalctl -u k3s | grep -i s3. Relógio fora de sincronia também causa erro de assinatura no S3.

Perguntas frequentes

Preciso do Velero se já tenho snapshot do etcd?

Sim, para os dados. O snapshot do etcd guarda apenas os objetos do Kubernetes, não o conteúdo dos volumes, e só restaura o cluster inteiro.

Posso usar o Velero para migrar para outro cluster?

Pode. Instale o Velero no cluster novo apontando para o mesmo bucket e rode o restore. É uma forma comum de migrar entre versões ou provedores.

Onde deixar o bucket S3?

Fora do servidor e, de preferência, em outro datacenter ou provedor, com versionamento ou bloqueio de objetos para resistir a ransomware.

Leitura complementar

Precisa de ajuda?

Se precisar de acesso ao console IPMI/iLO para uma restauração de emergência, abra um ticket ou chame o suporte 24/7.

Esta resposta lhe foi útil? 0 Usuários acharam útil (0 Votos)

Leia também