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

Source: Dev.to

Introdução

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.

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.

Componentes adicionados ao cluster KinD

CNI – Calico

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

• 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, permitindo:

• Criação de StorageClasses
• Provisionamento dinâmico de PVCs
• Utilização de backend baseado em armazenamento local

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

Ingress Controller – NGINX

(Instalação do controlador NGINX Ingress não detalhada aqui, mas incluída como módulo Terraform.)

Arquitetura Terraform

O repositório do módulo:

O módulo tf-module-kind-blueprint atua como um Aggregator Module (Root Module Composition 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 e reutilização
• Organização escalável
• Manutenção facilitada

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 o 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.

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

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, entrarei na camada de identidade e TLS — que está se mostrando um desafio interessante.