Reconstruir o GKE sem reemitir certificados
Um ensaio real de reconstrução expôs falhas que a revisão de código não pegou e, depois, permitiu três reconstruções de cluster sem consumir a cota de emissão de certificados.
O ensaio adotou 49 de 49 certificados sem reemitir. É um teste de recuperação, não um SLA de tempo de recuperação em produção.
Contribuição em resumo
- Minha responsabilidade
- Ensaio de reconstrução, correções de bootstrap/teardown e verificações de recuperação de certificados e GitOps.
- Escopo
- Um ensaio completo seguido de reuso em três reconstruções de ambiente durante a renumeração da rede.
- Colaboração & limites
- Fui responsável pelo procedimento de infraestrutura e pela validação; a recuperação das aplicações foi verificada pelo estado do GitOps.
- Resultado
- O ensaio adotou 49/49 certificados TLS com zero reemissões e restaurou 35 aplicações do ArgoCD.
O problema
Faixas de rede sobrepostas impediam a conectividade privada entre uma plataforma mais nova e serviços legados. Algumas faixas de endereços do GKE são imutáveis, então a mudança exigia reconstruir os clusters. Uma reconstrução que reemitisse silenciosamente cada certificado TLS poderia esgotar uma cota semanal de emissão compartilhada antes de a plataforma ficar saudável.
Minha contribuição
Executei um ensaio destrutivo de reconstrução em um ambiente isolado, corrigi falhas nos scripts de bootstrap e teardown e verifiquei a adoção de certificados, os endereços reservados do load balancer e a recuperação do GitOps. Depois usei esse processo em três reconstruções de ambiente como parte da renumeração da rede.
A ordem da recuperação importa
Restaurei os Secrets de TLS antes de recriar os recursos Certificate. Isso permitiu que o cert-manager adotasse os certificados existentes em vez de solicitar substituições. Os endereços externos reservados foram preservados de forma independente da subnet antiga, então substituir o cluster não exigiu alterar os registros DNS associados.
Executar o processo expôs defeitos que uma revisão estática não havia pegado: uma guarda rejeitava o estado criado pela etapa anterior, kinds de recurso ausentes quebravam uma deleção que seria idempotente e remover o External Secrets Operator antes de seus finalizers concluírem podia causar um deadlock no teardown. Corrigi a ordenação do ciclo de vida e verifiquei o estado resultante do cluster.
Resultados e medição
O ensaio reportou 49 certificados encontrados, 49 adotados, zero reemitidos e nenhum permaneceu não-pronto. Eles ficaram Ready em cerca de 20 segundos; esse é o tempo até o certificado ficar pronto, não a duração da reconstrução completa. A cota de emissão de certificados permaneceu no mesmo valor antes e depois. A identidade do node mudou, confirmando que este era um cluster novo, e não um reinício do antigo.
Depois, o método deu suporte a três reconstruções de cluster durante a renumeração da rede sem consumir cota de emissão adicional. O peering privado foi então ativado e verificado com um teste de conectividade antes/depois. Isso não estabelece um RTO de produção nem uma garantia de disaster recovery para toda a empresa.
O que eu repetiria
Um plano de recuperação ganha credibilidade quando suas etapas destrutivas foram de fato executadas. Preserve os recursos que carregam identidade, exercite a ordem de restauração e valide as aplicações recuperadas antes de dizer que a plataforma foi reconstruída.
Trabalhos relacionados: a base de Terraform e Shared VPC e a migração de workloads em fases.
Decisões e próximos passos
Uma visão retrospectiva da abordagem e dos seus limites. A próxima melhoria é uma proposta, não um resultado já entregue.
Alternativa e justificativa
Reemitir certificados é mais simples do que restaurá-los, mas arrisca as cotas de emissão. Restaurar o estado de TLS primeiro permite que o controller adote a identidade existente.
Trade-off
Um ensaio comprova o caminho de recuperação testado; ele não estabelece um SLA de tempo de recuperação em produção.
O que eu melhoraria a seguir
Próxima melhoria: agendar ensaios repetidos, registrar os tempos de recuperação e testar a recuperação quando uma dependência preservada estiver ausente.