Migração EKS para GKE: como migrar com a open-source do Google

Migração de AWS EKS para GKE sem perder a sanidade: o que a nova ferramenta open-source do Google realmente resolve

Já migrei cluster Kubernetes entre provedores suficientes vezes para saber que a dor nunca está no kubectl apply. Está em tudo aquilo que ninguém documentou: a IAM Role esquecida em um bucket, o Security Group hardcoded em um Helm chart de 2021, o ALB Controller rodando com permissões que ninguém lembra de ter concedido. Segundo o Eurisko.com.br, o Google acaba de abrir o código de uma ferramenta que ataca exatamente esse ponto — automatizar a tradução de cargas EKS para GKE usando IA, mas com validação determinística por baixo. E é isso que me chamou atenção, porque a maioria das tentativas que vi até hoje jogava tudo na LLM e rezava.

Vou destrinchar o que essa ferramenta faz de verdade, onde ela se encaixa no seu fluxo de migração e, principalmente, onde ela vai te deixar na mão.

O problema real que ninguém fala sobre migração multi-cloud

Na minha experiência, migrar Kubernetes entre nuvens não é um problema de Kubernetes. É um problema de identidade, rede e infraestrutura adjacente. O cluster em si — os Deployments, Services, ConfigMaps — é commodity. O que dói de verdade:

• Identidade de workload: na AWS você usa IAM Roles for Service Accounts (IRSA). No GKE, Workload Identity com binding para Google Service Accounts. A semântica é parecida, o mapeamento é traiçoeiro.
• Ingress e Load Balancer: AWS Load Balancer Controller vs. GKE Gateway / Ingress com NEGs. Os annotations não têm correspondência 1:1.
• Storage Classes e CSI drivers: EBS GP3 não é igual a Persistent Disk balanceado. E se você usa snapshots ou volume expansion, tem que revisar.
• Secrets e KMS: secretsmanager vs. Secret Manager do GCP, com CMK e políticas de rotação diferentes.
• Observabilidade: CloudWatch vs. Cloud Monitoring, com dashboards, alert policies e métricas customizadas que precisam ser reescritos.

É essa camada periférica que costuma estourar prazo e orçamento em projetos de migração.

O que a ferramenta do Google realmente faz (e o que ela não faz)

A proposta da ferramenta é focada e, por isso, me agrada: ela combina raciocínio de LLMs com validação determinística. Traduzindo para o dev que está lendo: a IA sugere a tradução, mas o resultado passa por um conjunto de regras e schemas antes de virar arquivo final. Isso é crucial, porque migrar manifestos com alucinação de LLM é receita para incidente em produção às 3h da manhã.

Ela atua principalmente em:

• Infraestrutura como Código: Terraform, Pulumi ou CDK da AWS lendo e produzindo o equivalente para GCP.
• Manifestos Kubernetes: recursos específicos do provider AWS (StorageClass para EBS, Service com type=LoadBalancer + annotations do ALB, ServiceAccount com annotation de IRSA) sendo convertidos para os equivalentes GKE.
• Identidade: tradução das anotações eks.amazonaws.com/role-arn para o padrão Workload Identity com iam.gke.io/gcp-service-account.

O que ela não faz — e seria ingênuo esperar que fizesse:

• Não move seus dados. Se você tem StatefulSets com 500 GB no EBS, vai ter que planejar cópia via rsync, velero ou storage transfer.
• Não recria dashboards e alertas. CloudWatch não vira Cloud Monitoring por mágica.
• Não garante paridade de custo. Cada cloud precifica de um jeito e isso muda a arquitetura.
• Não substitui testes de carga e chaos engineering no destino.

Comparativo honesto: como isso se posiciona no ecossistema

Antes de testar a ferramenta do Google, considere o que já existe no mercado. Eu já brinquei com várias abordagens:

Se você já tem uma esteira Terraform bem organizada, talvez o ganho marginal seja menor. Mas se o seu cluster EKS cresceu de forma orgânica — como 90% dos que vejo em produção —, ter um tradutor assistido por IA com validação determinística é um salto real.

Na Prática: como seria um fluxo de uso real

Vou simular um cenário comum: você tem um Deployment no EKS que monta um volume EBS e usa IRSA para acessar um bucket S3. Veja o manifesto original e a versão traduzida.

Manifesto original (EKS):

apiVersion: apps/v1
kind: Deployment
metadata:
 name: app-relatorios
 namespace: producao
spec:
 replicas: 3
 selector:
 matchLabels:
 app: relatorios
 template:
 metadata:
 labels:
 app: relatorios
 annotations:
 eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/app-relatorios-role
 spec:
 serviceAccountName: app-relatorios-sa
 containers:
 - name: app
 image: 123456789012.dkr.ecr.us-east-1.amazonaws.com/app-relatorios:v2.4.1
 env:
 - name: BUCKET_NAME
 value: relatorios-producao
 volumeMounts:
 - name: cache
 mountPath: /tmp/cache
 volumes:
 - name: cache
 persistentVolumeClaim:
 claimName: cache-relatorios
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: cache-relatorios
spec:
 accessModes: [ReadWriteOnce]
 storageClassName: gp3
 resources:
 requests:
 storage: 50Gi

Após a ferramenta processar, o esperado no GKE:

apiVersion: apps/v1
kind: Deployment
metadata:
 name: app-relatorios
 namespace: producao
spec:
 replicas: 3
 selector:
 matchLabels:
 app: relatorios
 template:
 metadata:
 labels:
 app: relatorios
 annotations:
 iam.gke.io/gcp-service-account: app-relatorios@meu-projeto-gcp.iam.gserviceaccount.com
 spec:
 serviceAccountName: app-relatorios-sa
 containers:
 - name: app
 image: us-central1-docker.pkg.dev/meu-projeto-gcp/app-relatorios/app:v2.4.1
 env:
 - name: BUCKET_NAME
 value: relatorios-producao
 volumeMounts:
 - name: cache
 mountPath: /tmp/cache
 volumes:
 - name: cache
 persistentVolumeClaim:
 claimName: cache-relatorios
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: cache-relatorios
spec:
 accessModes: ReadWriteOnce
 storageClassName: standard-rwo
 resources:
 requests:
 storage: 50Gi

Note o que mudou: a annotation de IRSA virou Workload Identity, a imagem migrou para Artifact Registry, o storageClassName saiu de gp3 para standard-rwo (o equivalente no GKE para Persistent Disk balanceado zonal). O accessModes: [ReadWriteOnce] virou um valor escalar — outro detalhe que pega muita gente.

O passo a passo recomendado em produção

1. Inventário e classificação: liste todos os clusters EKS, workloads, dependências externas (RDS, S3, SQS, etc.) e classifique por criticidade. Não migre tudo de uma vez.
2. Setup do GKE alvo: crie o cluster no GKE com Workload Identity habilitado desde o dia zero. É muito mais barato configurar do que migrar depois.
3. Run da ferramenta em modo dry-run: aplique a tradução em um repositório de manifesto paralelo. Faça review manual dos diffs gerados.
4. Pipeline de validação: kubectl apply --dry-run=server, conftest com OPA/Rego, kubeconform e os testes do policy-controller do GKE.
5. Migração de dados: para buckets use Storage Transfer Service; para bancos, DMS ou native replication; para volumes, velero ou snapshots cruzados.
6. Canary no destino: redirecione 5% do tráfego, observe métricas, expanda gradualmente.
7. Descomissionamento: só desligue o EKS após 30 dias de operação estável no GKE. Manter standby evita rollback doloroso.

Erros comuns que vejo em migrações EKS → GKE

1. Esquecer do IAM do node pool. No EKS, o Node IAM Role dá permissão para o kubelet falar com a API da AWS. No GKE, isso não existe — o controle é via Workload Identity + IAM bindings no GCP. Quem esquece disso fica 3 horas debugando pods que não iniciam.

2. Tratar Workload Identity como IRSA 1:1. A semântica é parecida, mas o namespace do Kubernetes precisa estar anotado e o bind entre GSA e KSA exige um iam.gke.io/gcp-service-account corretamente configurado. Use o guia oficial e o comando gcloud iam service-accounts add-iam-policy-binding.

3. Subestimar a diferença de rede. VPCs no GCP têm alcance global por padrão, mas regras de firewall e Private Service Connect se comportam diferente. Se seu cluster EKS depende de CIDR peering com a VPC do banco, planeje a topologia de rede no GCP antes de subir o cluster.

4. Manter annotations legadas da AWS. Já peguei clusters GKE em produção com service.beta.kubernetes.io/aws-load-balancer-name no Service. Não fazem nada, poluem o manifesto e confundem quem chega depois.

5. Não testar rollback. Migração sem plano de retorno é aposta. Defina SLIs/SLOs no destino, mantenha o EKS aquecido até validar, e documente o procedimento de cutover reverso.

6. Ignorar custos. EKS cobra por cluster (0,10 USD/hora). GKE cobra por cluster e também pelo tipo de cluster. Em Autopilot, o modelo é totalmente diferente — você paga por pods. Rode sempre o pricing calculator com seus workloads reais antes de tomar a decisão.

Quando essa ferramenta não vale a pena

Sendo direto: se você tem um cluster EKS com menos de 10 workloads e zero dependência AWS nativa, o custo-benefício de migrar é questionável. EKS é maduro, a equipe já conhece, e o ganho de mudar pode não compensar o risco. Migração multi-cloud faz sentido quando há uma razão estratégica real — preço, aquisição, requisito de soberania de dados ou lock-in inaceitável.

Também não espere bala de prata. A ferramenta do Google é uma peça do quebra-cabeça. Ela automatiza a parte chata e repetitiva, mas a engenharia de migração — estratégia de cutover, validação de dados, observabilidade, custos — continua sendo responsabilidade sua.

FAQ — perguntas que devs realmente fazem

A ferramenta funciona com manifestos Helm?
Sim, mas você precisa renderizar os templates primeiro com helm template para ter o YAML final antes de passar para a ferramenta. Helm templating com variáveis de ambiente gera centenas de combinações; escolha os valores canônicos de produção.

Ela substitui o Velero?
Não. A ferramenta traduz código e manifestos. O Velero move estado — recursos em runtime, volumes, secrets. Em uma migração completa, você provavelmente vai usar os dois em etapas diferentes.

Funciona para clusters EKS on Fargate?
Os manifestos em si sim. Mas tenha atenção: Fargate tem limitações (sem DaemonSets, sem hostNetwork) que existem também no GKE Autopilot, mas com regras diferentes. Revise cada workload.

Quanto tempo leva uma migração realista?
Depende do tamanho, mas para um cluster médio de 50 workloads com dependências de banco e storage, eu oriento 2 a 4 meses de projeto, incluindo paralelismo e validação. Quem promete migrar em 2 semanas está vendendo ilusión, não engenharia.

Posso usar sem confiar cegamente na IA?
Esse é justamente o ponto forte da abordagem: a saída da LLM passa por validação determinística antes de virar arquivo final. Você ainda precisa revisar, mas o trabalho braçal de traduzir manualmente é cortado drasticamente.

A ferramenta roda local ou precisa estar no GCP?
Como é open-source, você roda onde quiser — CI, laptop, esteira interna. Só precisa de credenciais para chamar as APIs se for usar os modelos do Google. Dá para plugar com Ollama ou outros backends dependendo da arquitetura.

Considerações finais

O movimento do Google com essa ferramenta open-source mostra uma direção interessante: