Hoje vamos falar um pouco sobre um assunto que eu escuto praticamente toda semana em conversas com clientes: “meu Kubernetes é efêmero, se cair eu subo tudo de novo em 10 minutos”. Já ouviu isso? Eu já. Mais vezes do que gostaria.

A intenção deste artigo não é vender o Veeam Kasten, a melhor solução de proteção de Kubernetes do mercado, mas sim mostrar de verdade o que acontece dentro de um cluster e quais os dados que não voltam sozinhos. Se você acompanhou a série do Veeam Kasten com K3s e Longhorn, esse aqui é meio que o artigo teórico que eu deveria ter escrito antes (pois é).

Mas vamos por partes, como diria Jack 🙂

De onde vem esse mito

Lá no começo, container era coisa de aplicação stateless: sobe, processa, morre, ninguém chora. O estado morava fora, geralmente em um banco de dados tradicional rodando em uma máquina virtual ou servidor físico bem cuidado, com backup rodando todo santo dia. Nesse cenário o raciocínio até fazia sentido. O cluster era só o lugar onde a aplicação rodava, o dado importante estava em outro lugar. Acontece que o mundo mudou e hoje temos banco de dados, sistema de mensageria, ferramenta de CI, registry, monitoramento e um monte de coisa com estado rodando dentro do Kubernetes. Segundo a pesquisa anual da CNCF, 82% de quem usa contêineres já roda Kubernetes em produção. E o discurso do “é tudo efêmero” continuou igual.

O que realmente existe dentro de um cluster

Eu gosto de separar em três camadas para facilitar a conversa.

1. A infraestrutura do cluster. Nodes, control plane, etcd, versão do Kubernetes, CNI, CSI. Isso normalmente é recriado por automação e realmente tende a ser efêmero. Inclusive altamente recomendo que seja criado de forma automatizada/padronizada.

2. As definições da aplicação. Deployments, StatefulSets, Services, ConfigMaps, Secrets, CRDs, RBAC, Ingress, tudo o que está no etcd. Em teoria isso está no Git. Pelo menos deveria estar.

3. Os dados persistentes. PVs, PVCs, o conteúdo dos volumes. Aqui não tem milagre, se perdeu, perdeu.

O que eu vejo na prática é que a camada 1 está muito bem coberta, a camada 3 quase nunca está e a camada 2 é onde mora a maior ilusão de todas. Vamos detalhar um pouco mais.

“Mas está tudo no Git”

Essa é a resposta padrão e ela merece respeito, porque quem trabalha com GitOps de verdade está muito mais protegido do que a média. Mas vamos fazer um teste rápido.

Conecte no seu cluster e rode:

kubectl get all --all-namespaces
kubectl get pvc --all-namespaces
kubectl get secrets --all-namespaces

Agora responda com honestidade: tudo o que apareceu ali está versionado em algum repositório? E se estiver, esse repositório é seguro?

Na maioria dos ambientes que eu vi, a resposta é não. Sempre tem aquele namespace que alguém criou na mão pra testar uma coisa e virou produção. Sempre tem um Secret que foi aplicado direto no cluster porque não podia ir pro Git. Sempre tem um Helm chart instalado manualmente por alguém que nem está mais na firma. E tem outro detalhe que muitas vezes passa batido: o Git guarda o estado desejado, não o estado real/atual. Se alguém criou objetos dinamicamente, ajustou réplicas, se um CRD foi modificado, nada disso volta do Git. Ou seja, o Git te devolve a receita do bolo. Ele não te devolve o bolo.

E o dado persistente?

Aqui a conversa é rápida e bem autoexplicativa. Um PVC com o banco de dados da aplicação não é reconstruído por pipeline nenhum. Não existe kubectl apply que traga de volta um volume que foi deletado. E deletar é fácil demais, esse é o ponto. Um kubectl delete namespace no contexto errado leva tudo junto, dependendo da sua reclaim policy até os PVCs. E não adianta contar só com o backup do etcd, que a própria documentação do Kubernetes recomenda: ele guarda os objetos do cluster, não o conteúdo dos volumes.

Os cenários que ninguém coloca na conta

Quando o pessoal pensa em backup, geralmente pensa em desastre: datacenter caiu ou cluster morreu. Mas na minha experiência esse é justamente o cenário menos comum. O que acontece de verdade é bem mais banal, como por exemplo o erro humano. Comando errado ou o clássico do kubectl config use-context esquecido. Isso sem falar no upgrade que deu errado, atualização de versão do Kubernetes, de operator, de CRD. Nem sempre o rollback é tão simples. Nem vou entrar nos detalhes do ransomware (sim, o Kubernetes não está imune) ou mobilidade da aplicação (sair de um cluster para outro, mudar de cloud, mudar de distribuição). Teve um caso recente onde alguém perguntou para restaurar o estado da aplicação de três meses atrás. E “está tudo no Git” não é a resposta que a auditoria estava esperando.

Snapshot não é backup (precisamos mesmo falar sobre isso?)

Aparentemente sim! O snapshot do storage é rápido, é barato e é ótimo para recuperar de um erro imediato. Mas ele normalmente vive no mesmo storage do dado original. Se o storage se foi, o snapshot foi junto. Se o cluster se foi, o objeto VolumeSnapshot que referenciava aquilo se foi também. Backup de verdade tem cópia em local separado, tem retenção, tem imutabilidade, tem restore testado. Mas calma, snapshot é uma peça da solução. Ele apenas não é A solução.

O que uma proteção decente precisa cobrir

Se o que você leu até aqui fez algum sentido, então a pergunta natural é: o que eu preciso proteger na prática? Eu costumo usar essa lista como checklist mínimo/básico:

• Consistência de aplicação, ou seja, o objeto do Kubernetes e o volume dele capturados juntos, no mesmo ponto no tempo
• Granularidade por namespace, porque restaurar cluster inteiro pra recuperar uma aplicação é desnecessário
• Cópia externa ao cluster, tipicamente um object storage (S3, NFS, o que fizer sentido no seu ambiente)
• Imutabilidade, para o backup não virar alvo
• Restore em cluster diferente, que é o teste que separa quem tem backup de quem tem esperança (um freguês me falou essa e eu estava ansioso para usa-la haha)
• Política automatizada, porque backup manual sempre é esquecido

E o mais importante de todos, que vale para Kubernetes, VMware, físico ou o que vier depois: restore testado. Backup que nunca foi restaurado é uma suposição, não uma proteção.

Se quiser ver esse checklist funcionando, o Veeam Kasten, que apresentei em Conhecendo o Veeam Kasten, cobre todos esses pontos, e no teste de Disaster Recovery eu mostrei o restore em outro cluster na prática. Para começar no seu ambiente, a versão gratuita atende até cinco worker nodes.

O cluster é efêmero, o dado não. Essas duas coisas convivem no mesmo lugar e é justamente aí que mora a confusão. Lembre-se: o negócio quer o bolo pronto com cobertura e tudo que tiver direito e pode não ter paciência para esperar o tempo do forno.

É isso aí, pessoal. Até a próxima 😀