GKE em produção com Terraform e uma Shared VPC

Módulos TerraformVersione infraestrutura reutilizável

Shared VPCDefina subnets e fronteiras

Ambientes GKEProvisione cargas de trabalho isoladas

Módulos Terraform reutilizáveis provisionam as fronteiras de rede e os recursos GKE de forma consistente.

Contribuição em resumo

Minha responsabilidade

Terraform modular, fronteiras de rede e um rollout em fases da plataforma GKE.

Escopo

Shared VPC e infraestrutura isolada por ambiente; os exemplos públicos de landing zone são código reutilizável à parte.

Colaboração & limites

Projetei e implementei a base de infraestrutura descrita aqui; os exemplos públicos generalizam o padrão em vez de expor a configuração do empregador.

Resultado

Provisionamento de ambientes reutilizável e recursos de rede compartilhada protegidos, entregues por meio de uma transição de responsabilidade em fases.

Imagine um ambiente GKE e a rede por baixo dele, tudo provisionado à mão. Sem infraestrutura como código, sem consistência entre os ambientes e nada que impeça um terraform destroy acidental de derrubar a rede compartilhada. Este é um relato de como reconstruí isso em uma Shared VPC, clusters privados, uma base de código Terraform modular e um rollout em oito fases que nunca deixou o sistema meio gerenciado.

Tudo aqui é a técnica, sem nomes internos ou detalhes específicos. No final, deixo os links das landing zones open-source que construí para GCP, AWS e Azure, para que você possa ler o código real por trás do mesmo padrão.

O ponto de partida

Os clusters e a rede foram criados pelo console e por um arquivo Terraform monolítico, feito de copiar e colar. Não havia módulo reutilizável, nenhuma estratégia por ambiente e nenhum prevent_destroy na rede. Em outras palavras, o único recurso que você não pode recriar de qualquer jeito, a VPC, era a coisa menos protegida do projeto.

A arquitetura-alvo

• Shared VPC. Um projeto host é dono da VPC, das subnets, do Cloud NAT e do firewall. Cada ambiente é um projeto de serviço anexado a ele, então a rede fica em um só lugar e os clusters nunca têm a própria VPC.
• Clusters privados. Os nodes não têm IPs públicos. Todo o egress sai pelo Cloud NAT, então a superfície voltada para a internet é um único gateway, não cada node.
• Workload Identity. Os pods se autenticam como service accounts do GCP sem chaves no nível do node para gerenciar ou vazar.
• Shielded nodes. Secure Boot e Integrity Monitoring em cada node.
• Menor privilégio. Uma service account dedicada por ambiente, limitada ao que aquele ambiente precisa.
• State remoto. O state do Terraform em um backend GCS, não no notebook de ninguém.

O rollout, em oito fases

O objetivo de dividir em fases era nunca ter uma janela em que a rede ficasse meio gerenciada. Cada fase deixava o sistema em um estado funcional.

• 1. Design da arquitetura. Topologia de Shared VPC, estratégia de subnets e requisitos de cluster para quatro ambientes.
• 2. Configuração dos projetos. Projetos, APIs habilitadas e service accounts do IAM com bindings de menor privilégio.
• 3. Rede. Projeto host da Shared VPC, subnets, Cloud NAT e regras de firewall, tudo via Terraform.
• 4. Terraform modular. Refatorado de recursos inline monolíticos para módulos reutilizáveis; a configuração raiz passou a ser chamadas de módulo mais um arquivo de variáveis por ambiente.
• 5. CI/CD. GitHub Actions: terraform plan no pull request, terraform apply no merge, um workflow separado por ambiente.
• 6. Clusters. Os quatro clusters GKE (dev, stg, prd, sandbox) implantados pelos pipelines.
• 7. Guardrails. prevent_destroy = true na VPC, nas subnets e no Cloud NAT.
• 8. Documentação. Diagramas de arquitetura, runbooks e docs dos módulos para o handover.

Resultados

• Todo recurso de rede e de cluster é gerenciado no Terraform. Nada mais é criado a cliques.
• Os quatro clusters sobem em uma única execução automatizada do pipeline.
• Um novo ambiente é um novo arquivo de variáveis, não código novo.
• A rede compartilhada está protegida contra destruição acidental, e todos os projetos de serviço roteiam o egress por um único gateway NAT.

O mesmo padrão, como open source

O relato acima fica genérico, então aqui está o mesmo padrão como código que você pode de fato ler. Construí uma landing zone para cada grande nuvem: uma configuração de Terraform mais GitHub Actions para Kubernetes multiambiente, com os padrões de segurança já embutidos (state remoto, nenhum secret no repositório, IAM de menor privilégio, um aviso de segurança em destaque em cada README).

• GCP landing zone — GKE, Shared VPC, Terraform e GitHub Actions. O espelho mais próximo da arquitetura acima.
• AWS landing zone — o mesmo formato no EKS: VPC, IAM e Terraform multiambiente.
• Azure landing zone — AKS com foco em governança, segurança e implantações multiambiente.

O que eu diria a quem está começando isso

• Coloque a rede em um projeto host de Shared VPC desde o primeiro dia. Adaptar isso depois em clusters que já têm a própria VPC é doloroso.
• Adicione prevent_destroy a tudo que você não pode se dar ao luxo de recriar, antes de precisar, não depois do primeiro susto.
• Faça de um novo ambiente um arquivo de variáveis, não um copiar e colar do código. Se adicionar um ambiente significa editar recursos, a configuração ainda não é modular.
• Mantenha o state remoto e os secrets fora do repositório. As landing zones acima mostram os padrões que eu uso.

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

Uma stack monolítica é rápida de começar; separar a rede compartilhada das cargas de trabalho de cada ambiente reduz o acoplamento destrutivo.

Trade-off

Os módulos adicionam interfaces e fronteiras de state que precisam de responsável, versionamento e migração segura.

O que eu melhoraria a seguir

Próxima melhoria: automatizar as verificações de drift e validar a recuperação a partir de cada fronteira de state da infraestrutura.