Kubernetes vs Docker Compose: qual usar e quando

Uma das perguntas mais frequentes de times que estão amadurecendo sua infraestrutura é: "quando devo migrar do Docker Compose para o Kubernetes?" A resposta curta é: provavelmente mais tarde do que você pensa. A resposta longa é o que este artigo explora.

O que cada um resolve

Docker Compose

Docker Compose é uma ferramenta para definir e executar aplicações multi-container em um único host. Com um arquivo YAML você descreve todos os serviços da aplicação — API, banco de dados, cache, workers — e os sobe com um único comando.

# docker-compose.yml
services:
  api:
    build: ./api
    ports:
      - "8080:8080"
    environment:
      - DATABASE_URL=postgres://user:pass@db:5432/myapp
    depends_on:
      db:
        condition: service_healthy

  db:
    image: postgres:16
    environment:
      POSTGRES_DB: myapp
      POSTGRES_USER: user
      POSTGRES_PASSWORD: pass
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U user -d myapp"]
      interval: 5s
      timeout: 5s
      retries: 5
    volumes:
      - postgres_data:/var/lib/postgresql/data

  redis:
    image: redis:7-alpine
    command: redis-server --maxmemory 256mb --maxmemory-policy allkeys-lru

volumes:
  postgres_data:

Simples, legível, funciona no laptop do dev e no servidor de produção com o mesmo arquivo. Esse é o poder do Compose.

Kubernetes

Kubernetes é um orquestrador de containers distribuído. Ele gerencia containers em um cluster de múltiplos nós, com capacidade nativa de auto-scaling, self-healing, rolling deployments, service discovery, gerenciamento de secrets e muito mais.

O equivalente do Compose acima em Kubernetes envolve no mínimo: um Deployment para a API, um Service para expô-la, um StatefulSet para o banco de dados, um PersistentVolumeClaim para armazenamento, um Deployment para o Redis, um ConfigMap para variáveis de ambiente e um Secret para credenciais — mais de 100 linhas de YAML para a mesma stack.

Onde o Docker Compose brilha

Desenvolvimento local

Nenhuma ferramenta bate o Compose para ambiente de desenvolvimento. docker compose up sobe toda a stack em segundos, com hot reload, logs consolidados e isolation perfeita entre projetos. Times que tentam usar Kubernetes localmente (mesmo com Minikube ou Kind) frequentemente voltam ao Compose por praticidade.

Aplicações de um único servidor

Se sua aplicação roda em uma VM e não precisa escalar horizontalmente, o Compose é suficiente — e muito mais simples de operar. Um servidor com 8 vCPUs e 32GB de RAM aguenta facilmente dezenas de containers com Compose, sem a complexidade operacional do Kubernetes.

Times pequenos e MVPs

Um time de 2-3 pessoas não deveria gastar semanas configurando Kubernetes quando o Compose resolve o problema em um dia. Complexidade operacional tem custo real — custo em tempo de engenharia que poderia estar sendo usado para construir produto.

Pipelines de CI/CD

Docker Compose é excelente para subir serviços de suporte em pipelines de teste — banco de dados, mensageria, mock de APIs. A maioria dos sistemas de CI (GitHub Actions, GitLab CI) tem suporte nativo ao Compose.

# .github/workflows/test.yml
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Start services
        run: docker compose -f docker-compose.test.yml up -d
      - name: Run tests
        run: dotnet test
      - name: Stop services
        run: docker compose -f docker-compose.test.yml down

Onde o Kubernetes é necessário

Escala horizontal automática

Quando o tráfego da sua aplicação varia significativamente ao longo do dia, o Kubernetes Horizontal Pod Autoscaler (HPA) pode escalar automaticamente o número de réplicas baseado em CPU, memória ou métricas customizadas.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api
  minReplicas: 2
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

Alta disponibilidade sem downtime

Rolling deployments no Kubernetes garantem que uma nova versão seja implantada gradualmente, com health checks, e que a versão antiga só seja removida depois que a nova estiver saudável. Zero downtime por padrão.

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # cria 1 pod novo antes de remover o antigo
      maxUnavailable: 0  # nunca reduz abaixo da capacidade desejada

Múltiplos serviços independentes (microsserviços)

Quando você tem 10, 20 ou 50 microsserviços com times de desenvolvimento independentes, cada um com seu próprio ciclo de deploy, o Kubernetes fornece a camada de orquestração necessária. Compose não foi projetado para esse cenário.

Workloads distribuídos em múltiplos nós

Kubernetes distribui automaticamente containers entre os nós disponíveis do cluster, considera recursos disponíveis e regras de afinidade, e redireciona tráfego automaticamente quando um nó falha.

Multi-tenancy e isolamento

Namespaces do Kubernetes permitem isolar ambientes (dev, staging, prod) ou clientes (em arquiteturas SaaS) no mesmo cluster, com políticas de rede, quotas de recursos e controle de acesso por namespace.

A matriz de decisão

                              Compose   Kubernetes
─────────────────────────────────────────────────
Dev local                       ✅          ⚠️
CI/CD (serviços de teste)        ✅          ✅
Servidor único, tráfego estável  ✅          ❌ (over-engineering)
Alta disponibilidade             ❌          ✅
Auto-scaling                     ❌          ✅
Rolling deployments zero-downtime ❌         ✅
Microsserviços (10+ serviços)    ❌          ✅
Time pequeno (1-3 devs)          ✅          ⚠️ (custo cognitivo alto)
Budget restrito para ops         ✅          ⚠️ (requer dedicação)

O custo operacional do Kubernetes

Kubernetes não é gratuito em termos operacionais. Considere:

• Custo de infraestrutura: um cluster mínimo com alta disponibilidade no EKS (AWS) custa a partir de R$ 800–1.200/mês só de nós (sem contar o control plane do EKS a ~$0,10/hora). Adicione load balancer, storage, transferência de dados e o custo real facilmente passa de R$ 2.000–3.000/mês para um setup básico.
• Custo de engenharia: alguém no time precisa dominar Kubernetes. A curva de aprendizado é real — espere 2-4 meses para um engenheiro experiente se tornar produtivo em operações K8s.
• Complexidade de debugging: problemas de rede, DNS, permissões de RBAC e scheduling são significativamente mais complexos de diagnosticar em K8s do que em Compose.

A alternativa intermediária: serviços gerenciados

Entre o Compose e o Kubernetes existe um território muitas vezes ignorado: serviços PaaS gerenciados que abstraem a orquestração.

• AWS ECS (Elastic Container Service): gerenciamento de containers com escalabilidade automática, sem complexidade do Kubernetes. Boa escolha para times AWS que não precisam da flexibilidade total do K8s.
• Railway, Render, Fly.io: plataformas que fazem deploy de containers com um comando, escalam automaticamente e gerenciam SSL, domínios e banco de dados. Excelente para MVPs e aplicações de médio porte sem time de DevOps dedicado.
• AWS App Runner: deploy de imagens Docker com zero configuração de infraestrutura.

Para muitas aplicações, um desses serviços gerenciados oferece 80% das vantagens do Kubernetes com 20% da complexidade.

O caminho de migração quando o Compose não é mais suficiente

Se você está usando Compose em produção e começa a sentir as limitações (deploys com downtime, sem auto-scaling, dificuldade de rodar múltiplas réplicas), o caminho de migração mais suave é:

1. Mantenha o Compose para dev local — não há razão para mudar isso.
2. Adicione um serviço gerenciado primeiro (ECS ou Fly.io) para ganhar deploy sem downtime antes de partir para K8s.
3. Containerize tudo corretamente — garanta que suas imagens são stateless, configuradas via variáveis de ambiente e têm health checks implementados.
4. Migre serviço por serviço — comece pelo serviço menos crítico para ganhar experiência antes de migrar o core da aplicação.
5. Use managed Kubernetes (EKS, GKE, AKS) — operar o control plane por conta própria raramente vale a pena.

Conclusão

Docker Compose é uma ferramenta excelente que resolve de forma elegante a maioria dos casos de uso de times menores e aplicações de porte médio. Kubernetes é uma plataforma poderosa para problemas específicos — escala horizontal, alta disponibilidade, microsserviços — que a maioria das aplicações simplesmente não tem.

A regra prática: comece com Compose, migre para um serviço gerenciado quando precisar de deploys sem downtime, e avalie Kubernetes quando tiver múltiplos serviços independentes e um engenheiro com tempo para operar o cluster. Adicionar complexidade antes de precisar dela é um dos erros mais comuns — e mais caros — em infraestrutura de software.

Se você está avaliando a infraestrutura ideal para seu produto ou precisa de ajuda para estruturar a migração, a Neryx tem experiência com ECS, EKS e Terraform em ambientes de produção. Consultoria inicial gratuita.