kind: o jeito mais rápido de ter um cluster Kubernetes sem gastar um centavo de cloud

O que é o kind?

O kind (Kubernetes IN Docker) é uma ferramenta que permite executar clusters Kubernetes locais usando contêineres Docker como “nós” (nodes). Criado originalmente para testar o próprio Kubernetes, hoje é amplamente usado por desenvolvedores para desenvolvimento local, CI/CD e aprendizado.

Antes de mergulhar nos detalhes, veja como a arquitetura funciona:—

Por que usar o kind?

Antes do kind existia o Minikube, que usa máquinas virtuais para simular um cluster. O kind trocou VMs por contêineres Docker, o que trouxe vantagens concretas:

• Velocidade: um cluster sobe em cerca de 60 segundos.
• Leveza: sem overhead de VM, consome muito menos RAM e CPU.
• Multi-nó: é possível criar clusters com vários nodes no mesmo laptop.
• CI/CD nativo: por rodar em Docker, funciona perfeitamente em pipelines como GitHub Actions, GitLab CI, Jenkins etc.
• Versão exata do Kubernetes: você escolhe exatamente qual versão do K8s usar via image tag.

Instalação

O kind é um binário único, sem dependências além do Docker.

macOS (Homebrew)

brew install kind

Linux (binário direto)

curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.23.0/kind-linux-amd64
chmod +x ./kind
sudo mv ./kind /usr/local/bin/kind

Windows (Chocolatey)

choco install kind

Go install

go install sigs.k8s.io/kind@v0.23.0

Você também precisará do kubectl instalado separadamente para interagir com o cluster.

Uso básico

Criar um cluster

# Cluster simples com nome padrão ("kind")
kind create cluster

# Cluster com nome personalizado
kind create cluster --name meu-cluster

O comando acima cria um cluster de nó único (control plane + worker no mesmo contêiner) e configura automaticamente o ~/.kube/config para que o kubectl aponte para ele.

Verificar o cluster

kubectl cluster-info --context kind-meu-cluster
kubectl get nodes

Listar e deletar clusters

kind get clusters
kind delete cluster --name meu-cluster

Configuração avançada com arquivo YAML

O kind aceita um arquivo de configuração para personalizar o cluster. É aqui que a ferramenta fica realmente poderosa.

Cluster multi-nó

# kind-config.yaml
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
  - role: control-plane
  - role: worker
  - role: worker
  - role: worker

kind create cluster --config kind-config.yaml --name meu-cluster

Isso cria um control plane e três workers, cada um em seu próprio contêiner Docker.

Múltiplos control planes (alta disponibilidade)

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
  - role: control-plane
  - role: control-plane
  - role: control-plane
  - role: worker
  - role: worker

Nesta configuração, o kind provisiona automaticamente um load balancer HAProxy para distribuir o tráfego entre os control planes.

Escolhendo a versão do Kubernetes

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
  - role: control-plane
    image: kindest/node:v1.29.2@sha256:...
  - role: worker
    image: kindest/node:v1.29.2@sha256:...

Cada versão do Kubernetes tem uma image tag correspondente em kindest/node. Você encontra todas as versões disponíveis no repositório oficial do kind.

Port mapping e acesso a serviços

Um ponto frequente de confusão é como acessar aplicações rodando dentro do cluster. Como os nós são contêineres Docker, você precisa fazer port mapping explícito.

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

Com isso, um Service do tipo NodePort usando a porta 30080 ficará acessível em localhost:8080 na sua máquina.

Montagem de volumes locais

Para montar diretórios do host dentro dos nós do kind:

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
  - role: control-plane
    extraMounts:
      - hostPath: /home/user/dados
        containerPath: /mnt/dados

Isso é útil para persistência de dados durante desenvolvimento, especialmente com PersistentVolumes baseados em hostPath.

Carregando imagens Docker locais

Esta é uma das funcionalidades mais úteis do kind. Em vez de publicar uma imagem em um registry, você a carrega diretamente no cluster:

# Buildar a imagem normalmente
docker build -t minha-app:dev .

# Carregar no cluster kind
kind load docker-image minha-app:dev --name meu-cluster

Depois disso, nos seus manifests Kubernetes, defina imagePullPolicy: Never ou IfNotPresent para garantir que o Kubernetes use a imagem local e não tente fazer pull de um registry.

spec:
  containers:
    - name: minha-app
      image: minha-app:dev
      imagePullPolicy: Never

Configurações de rede

O kind usa o CNI kindnet por padrão, mas você pode desabilitá-lo para instalar outro, como Calico ou Cilium:

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
networking:
  disableDefaultCNI: true       # Desabilita o kindnet
  podSubnet: "192.168.0.0/16"  # Subnet para os pods
  serviceSubnet: "10.96.0.0/12"
  apiServerAddress: "127.0.0.1"
  apiServerPort: 6443

Depois de criar o cluster sem CNI, você instala o de sua escolha:

# Exemplo com Calico
kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml

Uso em pipelines de CI/CD

O kind é especialmente popular em pipelines de CI porque o ambiente já tem Docker disponível. Exemplo para GitHub Actions:

# .github/workflows/test.yml
name: Testes de integração

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Instalar kind e kubectl
        run: |
          curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.23.0/kind-linux-amd64
          chmod +x ./kind && sudo mv ./kind /usr/local/bin/kind
          curl -LO "https://dl.k8s.io/release/$(curl -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
          chmod +x kubectl && sudo mv kubectl /usr/local/bin/

      - name: Criar cluster
        run: kind create cluster --name ci-cluster

      - name: Build e load da imagem
        run: |
          docker build -t minha-app:${{ github.sha }} .
          kind load docker-image minha-app:${{ github.sha }} --name ci-cluster

      - name: Deploy e testes
        run: |
          kubectl apply -f k8s/
          kubectl wait --for=condition=ready pod -l app=minha-app --timeout=120s
          # Rodar testes de integração aqui

      - name: Deletar cluster
        if: always()
        run: kind delete cluster --name ci-cluster

kind vs outras soluções locais

O k3d é ligeiramente mais rápido por usar o k3s (Kubernetes simplificado), mas o kind usa Kubernetes puro (upstream), o que o torna mais fiel ao ambiente de produção — decisivo para testes confiáveis.

Comandos úteis de diagnóstico

# Ver logs de um nó específico
kind export logs --name meu-cluster /tmp/kind-logs

# Entrar dentro de um nó (contêiner Docker)
docker exec -it meu-cluster-control-plane bash

# Ver os contêineres Docker do cluster
docker ps --filter "label=io.x-k8s.kind.cluster=meu-cluster"

# Exportar o kubeconfig manualmente
kind get kubeconfig --name meu-cluster > ~/.kube/kind-config

Limitações do kind

O kind não substitui um cluster de produção e tem restrições importantes a considerar:

LoadBalancer não funciona nativamente. Services do tipo LoadBalancer ficam em estado porque não há cloud provider. A solução é usar o MetalLB ou o cloud-provider-kind (projeto experimental da SIG Cloud Provider), ou simplesmente usar NodePort com port mapping.

Persistent Volumes têm limitações. O armazenamento é baseado em hostPath dentro do contêiner Docker, portanto os dados somem ao deletar o cluster. Para persistência real em dev, use extraMounts ou um CSI driver compatível.

Não roda no Windows sem WSL2. No Windows, o kind exige WSL2 com Docker rodando dentro do subsistema Linux. Docker Desktop resolve isso automaticamente, mas é bom estar ciente.

Performance de I/O. Por ser aninhado (contêiner dentro de Docker), operações de disco intensivas são mais lentas do que em um cluster real.

Casos de uso ideais

O kind brilha em cenários bem definidos. É a escolha certa quando você precisa testar manifestos Kubernetes, Helm charts ou operators sem subir infraestrutura real. Em pipelines de CI, é imbatível pela velocidade e pelo isolamento — cada job cria seu próprio cluster do zero e o destrói ao final. Para aprender Kubernetes, o kind oferece clusters reais com todos os componentes upstream funcionando, sem o custo de cloud.

O que ele não é: um substituto para staging ou produção, nem uma ferramenta de desenvolvimento de aplicações simples onde Docker Compose seria suficiente. Se a sua aplicação não precisa de funcionalidades específicas do Kubernetes, o kind é overhead desnecessário.

Recursos oficiais

• Documentação: kind.sigs.k8s.io
• Repositório: github.com/kubernetes-sigs/kind
• Imagens disponíveis: hub.docker.com/r/kindest/node/tags