Kubernetes sem Cloud Provider (Parte 1): CNI, Storage Dinâmico, Ingress e Arquitetura Terraform

Pedro Oliveira — Wed, 18 Feb 2026 02:40:16 +0000

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.

DEV Community: Pedro Oliveira