Aqui no blog eu já mostrei na prática como migrar aplicações entre clusters, como gerenciar vários clusters e como testar o DR com o Veeam Kasten. Hoje a ideia é falar sobre o motivo que isso é importante. Quando uma aplicação precisa mudar de casa, o backup deixa de ser apenas proteção e vira, basicamente, uma ferramenta de migração.

Uma aplicação pode precisar sair de um cluster por vários motivos e nenhum deles tem a ver com desastre. Alguns cenários bem comuns:

• Troca de distribuição: sair do K3s que nasceu no laboratório e ir para um OpenShift em produção ou o caminho contrário
• Entrar ou sair da nuvem: levar a aplicação para EKS, AKS ou GKE, ou trazer de volta para o datacenter (perdi a conta de quantos clientes tem voltado para dentro de casa)
• Atualização recriando o cluster: em vez de fazer o upgrade no próprio cluster, subir um cluster novo já na versão nova e mover as aplicações para ele
• Evitar ficar preso a um fornecedor: manter a liberdade de trocar de plataforma quando o custo ou o suporte deixarem de fazer sentido

A própria Veeam coloca a portabilidade entre nuvens e o teste de upgrade de clusters entre os principais casos de uso de mobilidade de aplicações.

Tá bom, mas não basta pegar os YAMLs e aplicar no cluster novo? Não basta, e esse é o ponto que mais pega. O manifesto descreve a aplicação, mas os dados ficam nos volumes persistentes, ou seja, o banco de dados sobe vazio do outro lado. Além disso, o cluster de destino quase nunca é igual ao de origem. A storage class tem outro nome (o Longhorn do laboratório não existe no EKS, por exemplo) e o PVC fica pendente. O ingress aponta para outro hostname ou usa outra ingress class. E ainda tem Secrets e ConfigMaps que precisam acompanhar a aplicação. GitOps resolve bem a parte dos manifestos, mas não leva os dados junto.

É aí que o Kasten faz diferença. O backup dele já contém a aplicação inteira, manifestos e volumes. Esse backup é exportado para um location profile e importado no cluster de destino, onde é restaurado. No meio do caminho entram os Transforms, que, segundo a documentação, permitem modificar os recursos do Kubernetes durante o restore. Desta forma, a troca de storage class ou de hostname acontece na hora da restauração, sem editar nada na mão. Mostrei isso em detalhes no post sobre o Transform Set do Veeam Kasten. Para quem tem vários clusters, vale ver também o gerenciamento de múltiplos clusters com o Veeam Kasten.

Verdadeiramente acredito que essa é uma das funcionalidades mais subestimadas do Kasten. Quem já fez um restore em outro cluster sabe que a mecânica de uma migração e a de um DR é a mesma, só muda o motivo. Por isso eu sempre recomendo começar pelo teste de DR, como fiz no Testando o Disaster Recovery do Veeam Kasten. Se o restore funciona do outro lado, a migração já está praticamente pronta. 🙂

Por fim, mover aplicação no Kubernetes é mover dados e adaptar o ambiente, e não apenas copiar arquivos YAML. O importante é saber que a mesma ferramenta que protege as aplicações também ajuda a mudar de cluster, de distribuição ou de nuvem sem depender de nenhum fornecedor.

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