Kubernetes só vale a pena a partir de qual escala: a resposta honesta

1. A promessa e o custo real do Kubernetes

O Kubernetes vende uma ideia sedutora: escalabilidade automática, alta disponibilidade e gerenciamento simplificado de contêineres. Na prática, porém, a realidade é mais complexa. O Horizontal Pod Autoscaler (HPA) não resolve todos os problemas de carga — ele exige métricas bem configuradas, limites de recursos definidos e um conhecimento profundo de como sua aplicação se comporta sob estresse.

A complexidade operacional escondida inclui:

  • RBAC (Role-Based Access Control): configurar permissões granulares para diferentes times
  • Namespaces: organizar recursos e isolar ambientes
  • Network Policies: controlar o tráfego entre pods
  • Persistent Volumes: gerenciar armazenamento stateful

Manter um cluster Kubernetes saudável exige um time com conhecimentos de SRE (Site Reliability Engineering). Se sua equipe não tem alguém dedicado a isso, o custo de aprendizado e manutenção pode superar rapidamente qualquer benefício.

# Exemplo de manifesto YAML para um deployment simples
apiVersion: apps/v1
kind: Deployment
metadata:
  name: minha-aplicacao
  namespace: producao
spec:
  replicas: 3
  selector:
    matchLabels:
      app: minha-aplicacao
  template:
    metadata:
      labels:
        app: minha-aplicacao
    spec:
      containers:
      - name: app
        image: minha-app:1.0
        resources:
          requests:
            memory: "256Mi"
            cpu: "250m"
          limits:
            memory: "512Mi"
            cpu: "500m"

2. Cenários onde Kubernetes NÃO compensa

Aplicações monolíticas com baixa variação de carga

Se você tem uma aplicação monolítica que recebe tráfego previsível, Kubernetes é overkill. Um simples servidor com Docker ou até mesmo um deploy tradicional via SSH resolve o problema com muito menos complexidade.

Times pequenos (1-3 devs) sem infraestrutura dedicada

Para equipes enxutas, o tempo gasto aprendendo Kubernetes, configurando clusters e debugando problemas de rede poderia ser melhor empregado no desenvolvimento de funcionalidades. A curva de aprendizado do Kubernetes é íngreme — dominar conceitos como pods, services, ingress, configmaps e secrets leva semanas ou meses.

Projetos com tráfego previsível e poucos microsserviços (< 5)

Quando você tem menos de 5 microsserviços, a orquestração manual ou via Docker Compose é perfeitamente viável. A sobrecarga operacional do Kubernetes não se justifica.

# Exemplo de docker-compose.yml para 3 serviços
version: '3.8'
services:
  api:
    build: ./api
    ports:
      - "3000:3000"
    depends_on:
      - banco
  banco:
    image: postgres:15
    environment:
      POSTGRES_DB: minhaapp
    volumes:
      - dados:/var/lib/postgresql/data
  cache:
    image: redis:7-alpine

volumes:
  dados:

3. O ponto de inflexão: métricas para decidir

Número de microsserviços

O ponto de inflexão geralmente ocorre quando você tem 10 ou mais microsserviços. Nesse cenário, gerenciar dependências, variáveis de ambiente e comunicação entre serviços manualmente se torna inviável.

Frequência de deploys

Se sua equipe faz múltiplos deploys por dia, Kubernetes oferece benefícios reais com rollouts graduais, health checks e rollbacks automáticos. Para deploys semanais ou quinzenais, a complexidade adicional não compensa.

Necessidade de isolamento

Ambientes efêmeros por branch ou pull request são um caso de uso clássico onde Kubernetes brilha. Se você precisa de ambientes isolados para cada feature em desenvolvimento, a automação do Kubernetes reduz drasticamente o overhead.

# Métricas para avaliar se Kubernetes vale a pena
# Use esta checklist:
# 1. Número de microsserviços: _____ (< 10? Considere alternativas)
# 2. Deploys por semana: _____ (< 7? Docker Compose pode bastar)
# 3. Tamanho do time de infra: _____ (0? Contrate ou espere)
# 4. Variação de carga: _____ (previsível? Sem Kubernetes)

4. Alternativas viáveis antes do Kubernetes

Docker Compose + Docker Swarm

Para times pequenos com até 5 serviços, Docker Swarm oferece orquestração nativa com muito menos complexidade. A curva de aprendizado é baixa e a integração com Docker Compose é direta.

Coolify ou Dokku

Essas ferramentas oferecem uma experiência PaaS (Platform as a Service) self-hosted. Você faz deploy via git push, e a plataforma gerencia contêineres, domínios e certificados SSL automaticamente. Ideal para projetos de escala baixa a média.

Nomad + Consul

A HashiCorp oferece o Nomad como uma alternativa mais simples ao Kubernetes. Ele gerencia contêineres e aplicações não-containerizadas com uma configuração muito mais enxuta. Consul cuida da descoberta de serviços e configuração.

# Exemplo de job Nomad para um serviço simples
job "api-servico" {
  datacenters = ["dc1"]
  group "api" {
    count = 2
    task "api" {
      driver = "docker"
      config {
        image = "minha-api:1.0"
        port_map {
          http = 8080
        }
      }
      resources {
        cpu    = 500
        memory = 256
      }
    }
  }
}

5. A escala mínima honesta: números do mundo real

Estudo de caso: startup com 3 microsserviços e 2 devs (fracasso)

Uma startup de fintech decidiu migrar para Kubernetes com apenas 3 microsserviços e 2 desenvolvedores. Após 3 meses, eles tinham gasto mais de 40 horas-homem por semana apenas mantendo o cluster. Os deploys, que antes levavam 5 minutos com Docker Compose, passaram a levar 30 minutos devido a problemas de configuração de rede e permissões. A startup voltou ao Docker Compose após 4 meses.

Estudo de caso: empresa média com 15 microsserviços e 5 devs (sucesso)

Uma empresa de e-commerce com 15 microsserviços e 5 desenvolvedores (incluindo 1 SRE dedicado) migrou para o Google Kubernetes Engine (GKE). O tempo de deploy caiu de 2 horas para 10 minutos. A escalabilidade horizontal automática permitiu lidar com picos de Black Friday sem intervenção manual. O custo operacional aumentou em 20%, mas a produtividade do time subiu 300%.

Regra de ouro

Kubernetes só vale a pena quando o custo operacional adicional é menor que o ganho de produtividade. Para a maioria dos projetos, isso acontece quando:

  • Você tem 10+ microsserviços
  • Um time de 3+ desenvolvedores dedicados a infraestrutura
  • Deploys frequentes (múltiplos por dia)
  • Variação de carga significativa (picos sazonais ou imprevisíveis)
# Estimativa de custo operacional mensal
# Cluster Kubernetes self-hosted (3 nodes)
# - 3 servidores: ~$300/mês
# - Armazenamento: ~$50/mês
# - Rede: ~$30/mês
# - Tempo de SRE (20h/semana): ~$2.000/mês
# Total: ~$2.380/mês

# Alternativa: Docker Compose em 1 servidor
# - 1 servidor: ~$100/mês
# - Armazenamento: ~$20/mês
# - Tempo de manutenção (5h/semana): ~$500/mês
# Total: ~$620/mês

6. Como começar sem se comprometer com o cluster

K3s e MicroK8s

Essas distribuições leves do Kubernetes rodam em máquinas pequenas (até mesmo em Raspberry Pi). São perfeitas para aprendizado e desenvolvimento local. O K3s, da Rancher, tem apenas 40MB de binário e consome menos de 512MB de RAM.

Kubernetes gerenciado vs. self-hosted

Para produção, sempre prefira Kubernetes gerenciado (EKS, GKE, AKS). O custo é maior, mas você terceiriza a complexidade do plano de controle, upgrades e patches de segurança. O self-hosted só faz sentido se você tem um time de SRE experiente.

Adoção gradual com Kompose

O Kompose converte arquivos docker-compose.yml em manifestos Kubernetes automaticamente. Isso permite uma migração gradual: você começa com Docker Compose, converte para Kubernetes e ajusta conforme necessário.

# Convertendo docker-compose.yml para Kubernetes com Kompose
kompose convert -f docker-compose.yml -o k8s-manifests/

# Resultado: arquivos deployment.yaml, service.yaml, etc.
# Exemplo de deployment gerado automaticamente
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 1
  selector:
    matchLabels:
      io.kompose.service: api
  template:
    metadata:
      labels:
        io.kompose.service: api
    spec:
      containers:
        - image: minha-api:1.0
          name: api
          ports:
            - containerPort: 3000

7. Sinais de que você precisa migrar (ou não)

Sinais de que você PRECISA migrar para Kubernetes

  • O deploy manual vira gargalo e quebra com frequência
  • A equipe gasta mais tempo com infraestrutura do que com features
  • O custo de cloud sem Kubernetes supera o custo com Kubernetes
  • Você precisa de ambientes efêmeros para cada branch ou PR
  • A aplicação precisa escalar horizontalmente em minutos, não horas

Sinais de que você NÃO DEVE migrar para Kubernetes

  • Seu time tem menos de 3 pessoas
  • Você tem menos de 5 microsserviços
  • O tráfego é previsível e estável
  • Você não tem orçamento para um SRE dedicado
  • A aplicação é monolítica e funciona bem em um único servidor
# Decisão final: matriz de maturidade para Kubernetes
# 
# Pontue de 0 a 5 em cada critério:
# - Número de microsserviços: (0-5)
# - Frequência de deploys: (0-5)
# - Tamanho do time de infra: (0-5)
# - Variação de carga: (0-5)
# - Necessidade de isolamento: (0-5)
# Total: ____ / 25
# 
# Resultado:
# 0-10: Docker Compose ou alternativas simples
# 11-17: Considere Kubernetes gerenciado (GKE, EKS)
# 18-25: Kubernetes é a escolha certa

A resposta honesta é: Kubernetes só vale a pena quando a complexidade que ele resolve é maior que a complexidade que ele introduz. Para a maioria dos projetos, isso acontece entre 10 e 15 microsserviços, com um time de pelo menos 5 desenvolvedores e deploys múltiplos por dia. Antes disso, ferramentas mais simples como Docker Compose, Coolify ou Nomad entregam mais valor com menos dor de cabeça.

Referências