EKS Blue/Green Cluster Migration
Nesta demonstração, vamos mostrar como migrar entre dois clusters Amazon EKS de versões diferentes sem nenhum downtime, usando uma abordagem blue/green com GitOps (ArgoCD) e Route53 weighted routing.
Cenário
Imagine que você tem um cluster EKS na versão 1.34 (duas versões atras). O upgrade in-place de control plane e uma "one-way door" - não existe rollback. E se fosse um EKS on Outposts Local Cluster v1, nem existiria o botao de upgrade pra v2. A solução: não vamos atualizar o cluster velho. Vamos substituir ele sem que o usuário perceba.
- Dois clusters (1.34 e 1.36) coexistindo na mesma VPC, sincronizando o mesmo repositorio Git
- Tráfego migrando progressivamente (90/10 → 50/50 → 0/100) via pesos no DNS - controlados por commits no Git
- Rollback instantâneo (um commit reverte tudo em menos de 2 minutos)
- O cluster velho sendo destruido sem que nenhum request falhe
| Componente | Papel |
|---|---|
| Amazon EKS (1.34 + 1.36) | Clusters blue e green |
| ArgoCD (self-managed) | GitOps - sincroniza o mesmo repo em ambos os clusters |
| Route53 (weighted records) | Distribui tráfego entre os clusters por peso |
| ExternalDNS | Reconcilia automaticamente os pesos do Git no Route53 |
| Karpenter | Provisiona nodes sob demanda em ambos clusters |
| Gitea (HTTPS) | Repositorio GitOps auto-hospedado (long-lived) |