Durante muito tempo — e ainda hoje em muitos cenários on-premises — o Kubernetes foi (e é) executado sem integrações nativas de cloud provider. Antes de EKS, GKE e AKS se tornarem padrão, era responsabilidade do operador configurar explicitamente rede, armazenamento, ingress, identidade e registry.

Este artigo é a primeira parte de uma série onde documento a construção de um cluster executando sobre Kubernetes in Docker (KinD), focando em:

• Configuração de CNI (rede de pods)
• Provisionamento dinâmico de storage com CSI
• Configuração de Ingress
• Estruturação e automação completa via Terraform

A parte de TLS com Vault e cert-manager ficará para o próximo artigo, pois ainda estou finalizando essa integração.

🎯 Motivação

Em ambientes gerenciados, temos automaticamente:

• CNI integrada à VPC
• Provisionamento dinâmico de discos
• Load Balancers
• Integrações de identidade

Mas nada disso é inerente ao Kubernetes. São componentes adicionais configurados pelo provedor.

A proposta deste projeto foi remover essas abstrações e implementar manualmente as capacidades essenciais de um cluster funcional.

Você não precisa saber mecânica para dirigir.
Mas quando o carro para no meio da estrada, esse conhecimento faz diferença.

---

🧱 Arquitetura do Projeto

O cluster foi criado com KinD e inicialmente não possuía:

• CNI funcional
• Provisionador de storage
• Ingress Controller
• Integrações externas

A partir disso, foram adicionados os seguintes componentes.

🌐 Rede — CNI com Calico

Para permitir comunicação entre pods e nós, foi instalado o:
Calico

Funções habilitadas:

• Atribuição de IPs aos pods
• Encapsulamento VXLAN
• Network Policies
• Comunicação inter-node

Sem CNI, pods não se comunicam — esse é o primeiro requisito real para um cluster utilizável.

💾 Storage Dinâmico — OpenEBS

Para substituir o papel que discos gerenciados fariam em cloud, implementei:

OpenEBS

Com isso foi possível:

• Criar StorageClasses
• Provisionar PVCs dinamicamente
• Utilizar backend baseado em armazenamento local

Isso reproduz o comportamento esperado por aplicações stateful em qualquer ambiente Kubernetes.

---

🧠 Estrutura Terraform — Organização Modular

O repositório do módulo:

https://github.com/pedrohro1992/tf-module-kind-cluster.git

O módulo tf-module-kind-blueprint atua como um módulo agregador.

Essa técnica é conhecida como:

Root Module Composition Pattern (ou Aggregator Module Pattern)

Nesse modelo:

• O módulo raiz não implementa recursos diretamente
• Ele compõe módulos especializados
• Centraliza variáveis e dependências
• Expõe uma interface limpa para consumo Cada componente (CNI, OpenEBS, NGINX Ingress) está encapsulado em seu próprio módulo Terraform.

Vantagens arquiteturais:

• Separação clara de responsabilidades
• Modularidade
• Reutilização
• Organização escalável
• Manutenção facilitada

---

🧩 Desafios Técnicos

Alguns pontos relevantes durante a implementação:

• Coordenação entre providers (Kubernetes e Helm)
• Garantia de ordem correta de dependências
• Idempotência dos módulos
• Encadeamento de outputs
• Inicialização do provider Kubernetes apenas após cluster estar disponível

Automatizar componentes de infraestrutura dentro de um cluster recém-criado exige atenção especial ao ciclo de vida dos recursos.

---

⚠️ Disclaimer

Tenho um senso de humor peculiar.

O nome fictício da “empresa” usada como estudo de caso no código é:

Cacetinho-SA

Sim, há referências a isso no código.
É intencional. 😄

💽 PVC provisionado dinamicamente pelo OpenEBS

🔮 Próximos Passos

Nos próximos artigos da série:

• Configuração de Identity Provider
• OIDC e Workload Identity
• DNS automático do Ingress com ExternalDNS
• TLS automático no Ingress com:
• cert-manager
• HashiCorp Vault como CA
• Evolução para Gateway API
• Service Mesh multi-cluster com Istio
• Empacotamento como Composition Function no Crossplane

(E provavelmente mais algumas ideias que surgirem no caminho.)

---

📌 Conclusão

Rodar Kubernetes sem cloud provider não é algo exótico — foi assim que muitos clusters rodaram por anos, e ainda rodam em ambientes bare-metal, edge e data centers privados.

Cloud providers apenas empacotam e integram:

• CNI
• CSI
• Ingress
• Identidade
• PKI

Implementar manualmente essas camadas muda completamente o nível de entendimento sobre a plataforma.

Este projeto não foi apenas sobre “fazer funcionar”, mas sobre compreender o que está acontecendo por baixo das abstrações.

No próximo artigo, entro na camada de identidade e TLS — que está se mostrando um desafio interessante.