Migração sem downtime para novos clusters Kubernetes
Mover uma plataforma inteira para novos clusters é o tipo de mudança que dá errado às 2 da manhã. Veja como fiz isso sem downtime: uma virada blue-green no nível do cluster, uma troca de DNS interno e scale-to-zero como rollback de um comando só.
Prepare a migração de aplicações e dados antes da virada de DNS e, então, valide o destino.
Contribuição em resumo
- Minha responsabilidade
- Movimentação faseada de workloads/dados, validação do destino e virada de DNS com rollback.
- Escopo
- Migração no nível do cluster, mantendo os workloads legados durante a transição.
- Colaboração & limites
- Coordenei a mudança de infraestrutura em torno das dependências de workloads e dados; cada serviço exige sua própria aceitação da virada.
- Resultado
- Uma estratégia de migração faseada e repetível, com um caminho de rollback. Nenhuma garantia universal de tempo de recuperação ou disponibilidade é inferida.
Reconstruir clusters é só metade do trabalho. Depois que os novos clusters existem, cada workload ainda precisa ser movido para eles, e "mover a produção para um cluster diferente" é exatamente a frase que faz as pessoas agendarem uma janela de manutenção à meia-noite. Eu não queria janela nem downtime, então tratei tudo como um deployment blue-green, só que no nível do cluster, em vez de um único serviço.
A estratégia: blue-green no nível do cluster
Os novos clusters rodaram em paralelo com os legados. Nada foi apagado até que o novo lado estivesse comprovado. A sequência:
- Suba os workloads nos novos clusters enquanto os clusters legados continuam atendendo todo o tráfego em produção.
- Faça a virada apontando o DNS interno de cada app migrado para os novos clusters. O tráfego muda na camada de DNS, sem reimplantar quem faz as chamadas.
- Escale os workloads legados a zero em vez de apagá-los. Eles ficam como um rollback a quente: se algo parecer errado, escalar o lado antigo de volta e apontar o DNS de volta é uma reversão de um único comando.
- Desative somente após o período de estabilização, quando o novo lado já tiver rodado limpo por tempo suficiente para confiar.
O que de fato precisou ser movido
Uma plataforma é mais do que seus pods sem estado. A migração cobriu toda a superfície:
- Aplicações — os serviços sem estado, reimplantados nos novos clusters.
- Cloud Functions, agendadores e filas de tarefas — a cola orientada a eventos e a cron que é fácil de esquecer até algo parar de disparar.
- Dados do Firestore — a parte com estado, migrada para o novo projeto para que os apps nos novos clusters leiam do lugar certo.
- Agendamentos de escala — as janelas de escalonamento para cima/para baixo em ambientes fora de produção, recriadas para que os novos clusters custem o mesmo ociosos que os antigos.
Escale a zero, não apague
A jogada mais valiosa em uma migração de cluster é manter os workloads antigos com zero réplicas em vez de apagá-los. Custa quase nada deixar um deployment ocioso estacionado, e isso transforma o rollback de uma reconstrução em um comando de escala de uma linha mais uma troca de DNS. Apague somente depois que o novo lado tiver conquistado sua confiança.
As partes que as pessoas esquecem
A migração não termina quando o tráfego flui. Duas limpezas foram importantes:
- Monitoramento que ainda sonda os hosts antigos. Depois da virada, as sondas blackbox estavam verificando os hostnames internos legados e exibindo uma parede de alertas falsos de "fora do ar". Reapontá-las para os hosts migrados foi o que de fato deixou a migração "concluída".
- Ferramental deixado para trás nos clusters legados. Agentes de custo e outros add-ons com escopo de cluster precisaram ser desinstalados de forma limpa (releases do Helm, além de CRDs e namespaces remanescentes), para que os clusters vazios estivessem realmente vazios antes de serem desmontados.
O que eu diria a quem está começando isso
- Trate a mudança de cluster como blue-green. Rode os dois em paralelo, faça a virada na camada de DNS e nunca apague o lado antigo até que o novo esteja comprovado.
- Escale os workloads antigos a zero, não os apague. Esse é o seu rollback, e mantê-lo custa quase nada.
- Inventarie toda a superfície primeiro: funções, agendadores, filas de tarefas e dados com estado, não apenas os pods óbvios.
- Termine o serviço. Reaponte o monitoramento para os novos hosts e limpe os clusters antigos, ou você vai caçar alertas fantasmas por semanas.
Decisões e próximos passos
Uma visão retrospectiva da abordagem e seus limites. A próxima melhoria é uma proposta, não um resultado entregue.
Alternativa e justificativa
Uma migração in-place reduz a capacidade paralela; clusters paralelos permitem a validação do destino antes de desviar o tráfego.
Trade-off
A operação em paralelo adiciona custo temporário, além de riscos de comportamento de DNS/cache e de sincronização de estado.
O que eu melhoraria em seguida
Próxima melhoria: registrar a aceitação por serviço, o tempo de rollback e as condições para remover a capacidade legada com segurança.