Local development: Kind, K3d e Minikube

1. Introdução ao Desenvolvimento Local com Kubernetes

1.1. Por que usar clusters locais?

Desenvolver com Kubernetes localmente oferece três vantagens fundamentais: ciclo de feedback rápido, custo zero de infraestrutura cloud e isolamento completo entre ambientes. Em vez de aguardar pipelines de CI/CD para validar alterações, você pode testar manifests, deployments e services diretamente na sua máquina, reduzindo o tempo de iteração de minutos para segundos.

1.2. Desafios de simular produção localmente

Recriar fielmente um ambiente produtivo localmente é complexo. Limitations de recursos de hardware, diferenças em configurações de rede, ausência de balanceadores de carga reais e falta de storage distribuído são obstáculos comuns. Ferramentas como Kind, K3d e Minikube surgem para mitigar esses problemas, cada uma com abordagens distintas.

1.3. Visão geral das ferramentas

  • Kind (Kubernetes in Docker): Executa nós Kubernetes como containers Docker. Ideal para testes de multi-nó e CI/CD.
  • K3d (K3s em Docker): Baseado no K3s da Rancher, é extremamente leve e suporta alta disponibilidade nativa.
  • Minikube: Ferramenta madura com múltiplos drivers e addons, focada em desenvolvimento local completo.

2. Kind (Kubernetes in Docker)

2.1. Arquitetura: nós como containers Docker

Kind transforma cada nó do cluster (control-plane e workers) em containers Docker. Isso permite simular clusters multi-nó com poucos comandos. A comunicação entre nós ocorre via rede Docker interna.

2.2. Comandos essenciais

# Criar cluster padrão (single node)
kind create cluster --name dev-cluster

# Criar cluster com 3 nós (1 control-plane + 2 workers)
kind create cluster --config kind-config.yaml

# Excluir cluster
kind delete cluster --name dev-cluster

# Carregar imagem local para o cluster
kind load docker-image minha-app:latest --name dev-cluster

2.3. Configuração avançada

Arquivo kind-config.yaml para multi-nó com port mapping e Ingress:

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
  extraPortMappings:
  - containerPort: 80
    hostPort: 8080
    protocol: TCP
- role: worker
- role: worker

Para habilitar Ingress, instale o controller após criar o cluster:

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/deploy/static/provider/kind/deploy.yaml

3. K3d (K3s em Docker)

3.1. Diferenças do Kind

K3d utiliza o K3s, uma distribuição certificada do Kubernetes com ~60MB de binário. Diferente do Kind, que usa código Kubernetes padrão, o K3s remove componentes não essenciais e substitui etcd por SQLite (ou embedded etcd). A leveza permite iniciar clusters em segundos.

3.2. Criação de clusters com múltiplos servidores e agents

# Cluster básico com 1 servidor + 2 agents
k3d cluster create dev-k3d \
  --servers 1 \
  --agents 2 \
  --port "8080:80@loadbalancer"

# Cluster com alta disponibilidade (3 servidores)
k3d cluster create ha-cluster \
  --servers 3 \
  --agents 3

3.3. Integração com registries locais e exposição de portas

# Criar registry local e conectar ao cluster
k3d registry create local-registry --port 5000
k3d cluster create dev \
  --registry-use local-registry:5000

# Mapear portas do host para o load balancer
k3d cluster create web \
  --port "3000:80@loadbalancer" \
  --port "443:443@loadbalancer"

4. Minikube

4.1. Funcionalidades: drivers e addons

Minikube suporta drivers como Docker, VirtualBox, Hyper-V, KVM e VMware. Os addons estendem funcionalidades:

# Iniciar com driver Docker
minikube start --driver=docker --cpus=4 --memory=8192

# Listar e habilitar addons
minikube addons list
minikube addons enable ingress
minikube addons enable metrics-server
minikube addons enable dashboard

4.2. Comandos do dia a dia

# Iniciar/parar cluster
minikube start
minikube stop

# Abrir dashboard web
minikube dashboard

# Expor service via tunnel (para LoadBalancer)
minikube tunnel

# Obter IP do cluster
minikube ip

4.3. Casos de uso: volumes persistentes e métricas

Minikube oferece suporte nativo a PersistentVolumeClaims com o provisionador standard:

# Criar PVC de exemplo
kubectl apply -f - <<EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: exemplo-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
EOF

# Ver métricas do cluster
kubectl top nodes
kubectl top pods

5. Comparação Prática entre as Ferramentas

5.1. Performance e consumo de recursos

Ferramenta Tempo de inicialização Consumo RAM (cluster single) Consumo CPU
Kind ~60 segundos ~500 MB Baixo
K3d ~20 segundos ~250 MB Muito baixo
Minikube ~90 segundos ~1 GB Moderado

5.2. Facilidade de setup e curva de aprendizado

  • Kind: Simples, mas requer configuração manual para Ingress e storage.
  • K3d: Mais simples, com load balancer embutido e registry integrado.
  • Minikube: Interface mais amigável com dashboard e addons, mas maior consumo.

5.3. Suporte a funcionalidades avançadas

  • Load Balancer: K3d oferece nativamente; Kind requer MetalLB; Minikube usa tunnel.
  • Storage: Minikube tem melhor suporte a volumes persistentes; Kind e K3d dependem de provisionadores externos.
  • RBAC e Network Policies: Todas suportam, mas Minikube tem configuração mais direta.

6. Fluxo de Trabalho DevOps com Clusters Locais

6.1. Integração com Docker Compose e desenvolvimento iterativo

Use kompose para converter Docker Compose em manifests Kubernetes:

# Converter docker-compose.yaml para manifests
kompose convert -f docker-compose.yaml -o k8s/

# Aplicar no cluster local
kubectl apply -f k8s/

6.2. Uso com Helm e CI/CD local

# Instalar Helm chart localmente
helm install minha-app ./chart --values values-dev.yaml

# Com Skaffold para desenvolvimento contínuo
skaffold dev --default-repo=localhost:5000

6.3. Debugging e logs

# Logs em tempo real com stern
stern "minha-app-*"

# Port-forward para service
kubectl port-forward service/minha-app 8080:80

# Executar comando interativo no pod
kubectl exec -it deployment/minha-app -- sh

7. Boas Práticas e Troubleshooting

7.1. Limpeza de clusters e gerenciamento de recursos

# Remover clusters não utilizados
kind delete clusters --all
k3d cluster delete --all
minikube delete --all

# Verificar consumo de recursos
docker stats
kubectl describe nodes

7.2. Problemas comuns

  • Falha de pull de imagem: Sempre use kind load docker-image ou registry local.
  • Conflito de portas: Verifique portas em uso com lsof -i :8080 e ajuste mappings.
  • Cluster não inicia: Aumente recursos no Docker Desktop ou VirtualBox.

7.3. Dicas para reproduzir cenários de produção

  • Teste NetworkPolicies com calico ou cilium nos clusters.
  • Aplique ResourceQuotas e LimitRanges para simular restrições.
  • Use kubectl taint e kubectl cordon para simular falhas de nós.

8. Conclusão e Próximos Passos

8.1. Resumo: quando usar cada ferramenta

  • Kind: Ideal para CI/CD, testes de multi-nó e validação de manifests complexos.
  • K3d: Perfeito para desenvolvimento rápido, prototipagem e máquinas com recursos limitados.
  • Minikube: Recomendado para iniciantes, testes de storage e funcionalidades avançadas como métricas e dashboard.

8.2. Migração do local para staging/produção

O fluxo típico é: desenvolver localmente → testar em cluster local → deploy em staging via CI/CD → produção. Use os mesmos manifests e Helm charts em todos os ambientes, ajustando apenas valores via values.yaml.

8.3. Referência aos temas vizinhos

Explore Helm hooks para automação de pré/post deploy, testes de manifests com kubeval e conftest, e monitoramento com Prometheus Operator.

Referências