Migração do GKE para Dataplane V2 (Cilium / eBPF)
O GKE está trocando sua rede padrão de iptables para Cilium e eBPF, e o campo que controla isso não pode ser alterado em um cluster em execução. Veja como transformei uma destruição e recriação forçada em um bootstrap GitOps versionado e um plano de validação de 18 pontos.
Entrega fora de produção com verificações explícitas e rollback; produção ficou fora deste escopo.
Contribuição em resumo
- Minha responsabilidade
- Migração de rede fora de produção e bootstrap de plataforma repetível.
- Escopo
- Migração de development, staging e sandbox; produção excluída desta entrega.
- Colaboração & limites
- Validei a compatibilidade de infraestrutura e dos controllers na janela fora de produção disponível.
- Resultado
- Uma entrega fora de produção em etapas, com validação explícita e rollback; nenhum resultado de migração em toda a produção é reivindicado.
O GKE anunciou que, a partir de 30 de março de 2027, novos clusters passam a usar o Dataplane V2 (DPv2) por padrão, que substitui o antigo data plane de kube-proxy e iptables (Dataplane V1) por Cilium e eBPF. O detalhe: o campo datapath_provider é imutável. Não dá para trocar um cluster em execução de V1 para V2. O único caminho é destruir e recriar o cluster.
Por que migrar cedo, e não no prazo final
Esperar até 2027 é a opção cara. Eu migrei enquanto era barato e seguro:
- A janela estava aberta. Três dos quatro clusters (dev, staging e sandbox) estavam vazios, zero nodes e zero workloads ativos. Esse é o momento de menor risco e menor custo que esta migração jamais terá.
- Evitar uma surpresa depois. Se eu esperasse, na próxima vez que qualquer cluster fosse recriado após o prazo ele herdaria o DPv2 por padrão, sem nenhuma validação prévia da stack da plataforma (ingress, cert-manager, external secrets, autoscaling, progressive delivery, GitOps).
- Quitar dívida no processo. Recriar um cluster obriga você a ter um bootstrap de verdade. Essa foi a oportunidade de substituir anos de configuração manual por um pipeline repetível.
Tornando o campo imutável explícito
A causa raiz do risco de "surpresa em 2027" é que o campo sempre tinha ficado no padrão da nuvem. Eu tornei o datapath_provider uma variável do Terraform explícita e obrigatória no módulo do cluster, para que nenhum cluster seja criado sem uma escolha consciente:
- dev, staging e sandbox recriados com
ADVANCED_DATAPATH(DPv2 / Cilium). - produção mantida explicitamente em
LEGACY_DATAPATH; migrar um cluster de produção ativo é um projeto à parte que precisa de uma janela de manutenção de verdade.
A lição se generaliza: qualquer campo de infraestrutura imutável deveria ser uma variável explícita no código, nunca um padrão herdado. Os padrões mudam sem avisar.
O lado bom: um bootstrap GitOps
Antes disso, subir um cluster significava um monte de kubectl apply manuais e instalações ad-hoc de Helm: cert-manager, dois ingress controllers, o autoscaler, cluster issuers. Esse conhecimento vivia na cabeça das pessoas. Como um destruir e recriar teria perdido tudo isso, eu converti em um diretório de bootstrap versionado mais um workflow de CI, de forma que subir um cluster do zero agora é uma execução de pipeline determinística e revisada. A recriação também me permitiu atualizar o autoscaler algumas versões minor e fixar versões exatas do cert-manager e do resto.
Cada cluster recriado então se registra novamente no controller central de GitOps, já que o endpoint de API do cluster, o token e o certificado CA mudam todos na recriação.
Valide o data plane, não presuma
Trocar o data plane pode mudar comportamentos sutis (aplicação de NetworkPolicy, IPs de origem, conectividade). Validei cada cluster recriado contra um plano de 18 pontos: NetworkPolicies, external secrets com Workload Identity, sincronização do GitOps, scraping do Prometheus, emissão do cert-manager e egress pelo Cloud NAT, entre outros. Tudo verde antes que qualquer coisa passasse a depender disso.
O que eu diria para quem está começando isto
- Torne os campos imutáveis explícitos na sua IaC. Se mudar um campo significa recriar o recurso, ele deveria ser uma variável obrigatória e revisada, não um padrão silencioso.
- Aproveite a janela de cluster vazio. O momento mais barato para fazer uma migração destrutiva é antes de qualquer coisa estar rodando nele.
- Deixe uma recriação forçada quitar dívida. Se você precisa reconstruir, reconstrua como código: transforme o bootstrap manual em um pipeline GitOps repetível.
- Deixe a produção por último, com a sua própria janela. Prove o padrão primeiro nos clusters vazios.
- Valide o data plane explicitamente. Uma troca de rede é exatamente onde o "provavelmente ainda funciona" te pega.
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
Manter o dataplane anterior evita o trabalho de migração imediato; uma reconstrução controlada oferece a chance de validar o substituto antes de uma futura mudança de dependência.
Trade-off
A rede imutável do cluster exige recriação. A compatibilidade dos controllers e a ordem de restauração importam tanto quanto a criação do cluster.
O que eu melhoraria a seguir
Próxima melhoria: manter um checklist de compatibilidade e ensaiar os pré-requisitos de produção antes de planejar qualquer migração de produção à parte.