Como migrar EKS para GKE com a ferramenta open-source do Google

Migrar uma aplicação Kubernetes de uma cloud para outra nunca foi trocar uma lâmpada. É desmontar parte da casa, carregar os fios por um corredor estreito e remontar tudo em outro endereço — sem estourar o disjuntor. Quando o Google decidiu abrir o código de uma ferramenta que automatiza parte dessa jornada entre o Amazon EKS e o Google Kubernetes Engine, meu primeiro instinto foi de ceticismo saudável. Depois de fuçar o repositório e cruzar com a nota divulgada pelo Eurisko.com.br, mudei de opinião. A sacada não está só na automação — está no modelo de como a IA entra nesse processo.

Por que migrar EKS para GKE é mais difícil do que parece

Na minha experiência liderando migrações, o que derruba times não é mover pods. É mover o que está ao redor: IAM Roles for Service Accounts (IRSA), security groups, Classic Load Balancers anotados em Services, e toda aquela floresta de políticas assumidas via OIDC providers da AWS. O GKE tem um modelo análogo — Workload Identity —, mas as primitivas são diferentes, e a correspondência um-para-um raramente existe.

Para um dev sênior, três coisas costumam ser o verdadeiro gargalo:

Identidade federada: o IRSA da AWS usa um OIDC provider por cluster e uma trust policy por role. O Workload Identity do Google exige uma binding entre a GCP Service Account e a K8s Service Account via annotation iam.gke.io/gcp-service-account. Não é tradução direta.
Recursos anotados: Services do tipo LoadBalancer, Ingress com alb.ingress.kubernetes.io, e StorageClasses com provisioners da AWS não funcionam no GKE sem reescrita.
Configurações de rede: Security groups, VPC peering, e endpoints privados não têm equivalente 1:1 — é preciso repensar topologia.

É aí que entra a ferramenta do Google. E é aí que a maioria das abordagens automatizadas tropeça.

Como a ferramenta funciona (e por que isso importa)

O ponto que me chamou atenção, e que o Eurisko destacou bem, é a separação de responsabilidades: a IA raciocina, mas não tem acesso ao cluster de destino. A ferramenta combina o que o pessoal chama de “raciocínio probabilístico” (LLM interpretando Terraform, Helm charts, manifests) com “validação determinística” (regras fixas que checam se a saída faz sentido).

Na prática, o pipeline costuma seguir este formato:

Coleta manifestos EKS, Terraform/CloudFormation e Helm values.
Um LLM sugere as transformações (ex.: converter uma iam.amazonaws.com/role-arn annotation em iam.gke.io/gcp-service-account).
Validadores determinísticos checam: nomes válidos, regions conhecidas, APIs suportadas, ausência de segredos vazando para o prompt.
O output é um pacote de manifests Terraform/Kubernetes prontos para revisão humana.

Esse desenho é importante porque resolve um problema que eu já vi estourar em produção: gente jogando credenciais de cluster dentro do contexto do modelo “só pra acelerar”. A ferramenta assume que o humano revisa — a IA propõe, o engenheiro assina.

Na Prática: comparando IRSA com Workload Identity

Para você sentir o tamanho da diferença, segue um exemplo real. Imagine um pod que precisa falar com o S3 no cluster de origem.

EKS / AWS — IRSA típico:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: app-s3-reader
  namespace: default
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/AppS3ReaderRole

E a trust policy da role na AWS:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "Federated": "arn:aws:iam::123456789012:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/EXAMPLExxx"
    },
    "Action": "sts:AssumeRoleWithWebIdentity",
    "Condition": {
      "StringEquals": {
        "oidc.eks.us-east-1.amazonaws.com/id/EXAMPLExxx:sub": "system:serviceaccount:default:app-s3-reader"
      }
    }
  }]
}

GKE — Workload Identity equivalente:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: app-storage-reader
  namespace: default
  annotations:
    iam.gke.io/gcp-service-account: app-storage-reader@meu-projeto.iam.gserviceaccount.com

E a binding IAM no lado GCP:

gcloud iam service-accounts add-iam-policy-binding \
  app-storage-reader@meu-projeto.iam.gserviceaccount.com \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:meu-projeto.svc.id.goog[default/app-storage-reader]"

Repare que no EKS a confiança é declarada na role; no GKE, é declarada na service account GCP. A ferramenta do Google precisa entender essa inversão sem inverter a semântica. É exatamente o tipo de tradução onde um LLM bem guiado ajuda, e um LLM solto sem validação produz lixo elegante.

Erros comuns que eu já vi (e cometi)

Se você está pensando em usar essa ferramenta — ou qualquer ferramenta de migração assistida por IA —, preste atenção nestes pontos:

Confiar 100% no diff gerado. O output é uma sugestão. Eu vi annotation de service account ser “traduzida” para um e-mail inexistente no GCP, e o pipeline passou porque o validador só checava formato, não existência. Validação real precisa rodar contra a API do GCP.
Esquecer de revisar permissões de borda. Ingress e Network Policies mudam de cloud para cloud. Se o cluster EKS tinha SG aberto para a VPC de testes e o GKE não replicar isso explicitamente, seu CI quebra em silêncio.
Migrar tudo de uma vez. Strangler Fig Pattern continua valendo. Migre um namespace, valide, expanda. Ferramenta de IA acelera, mas rollback em Kubernetes cross-cloud é caro.
Ignorar custo de dados. A migração de configuração é só metade. Se houver EBS snapshots ou dados em S3, o custo de tráfego de saída e refactor de storage pode dobrar o orçamento da operação.
Colocar segredos no contexto do modelo. Mesmo que a ferramenta não peça, é fácil vazar um aws_secret_access_key ao colar manifests. Higiene vale ouro aqui.

Comparativo rápido: o que mais existe no mercado

Para ser justo, a ferramenta do Google não está sozinha nesse espaço. Existem alternativas:

Terraformer / Terraform Import: ótimo para gerar IaC a partir do estado atual, mas não traduz entre provedores. Você precisa reescrever os recursos.
Kompose: velho de guerra, converte docker-compose em manifests. Resolve outro problema.
Vendored tools de vendors (Cloudamize, Cirrus Migrate): fechados, caros, bons para workloads não-Kubernetes.
Equipes internas com prompt engineering + scripts: o que muita gente fazia antes. Funciona, mas não escala e vira débito técnico rápido.

O diferencial do projeto open-source do Google é justamente tratar a IA como assistente, não como executor, e entregar um pipeline auditável. Isso é raro.

FAQ — perguntas que devs realmente fazem

1. A ferramenta substitui um arquiteto de migração?

Não. Ela reduz o trabalho mecânico de tradução de manifestos. Decisões de topologia, custos e estratégia de rollout continuam sendo humanas. Pense nela como um estagiário muito rápido que erra com elegância.

2. Funciona para clusters EKS Fargate?

Parcialmente. Os manifestos de workload convertem normalmente, mas algumas integrações com AWS Fargate (perfil de execução, ENI trunk driver) não têm equivalente direto no GKE e precisam de adaptação manual.

3. Preciso reescrever meus Helm charts?

Em geral, não. O que costuma precisar de ajuste são os values.yaml que injetam annotations específicas da AWS e os templates que referenciam IAM roles hardcoded. A ferramenta sinaliza esses pontos, mas a edição final é sua.

4. E se meu cluster já usa GitOps (ArgoCD/Flux)?

Aí fica até mais simples. Você roda a ferramenta uma vez, gera os manifests GKE, commita no repositório, e o GitOps faz o resto. Só revise o PR antes de dar merge.

5. Qual o risco real de segurança?

O risco não está na ferramenta em si — o pipeline roda localmente e não envia seus manifestos para um modelo externo, a menos que você configure assim. O risco está em você, na pressa, copiar um secret para o contexto. Trate o input da mesma forma que trataria logs: sanitize antes.

O que eu levaria pra casa disso tudo

Se eu fosse apresentar isso para um time hoje, diria: usem para acelerar o survey, não para fechar a migração. O ganho real está em mapear 80% do trabalho mecânico em horas, não em semanas. Os 20% finais — rede, identidade, custos, compliance — continuam exigindo cérebro humano tomando decisão.

E o detalhe mais importante, que vale repetir: o Google entendeu que dar a chave do cluster para um LLM é uma péssima ideia. A IA fica do lado de fora da porta, propondo. Você decide quem entra. Em 2026, com a enxurrada de agentes automatizados aparecendo em todo canto, esse desenho vale como referência até para projetos que não têm nada a ver com Kubernetes.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.