Introdução
Kubernetes virou quase um padrão automático quando se fala em containers. Em muitos projetos, a decisão de usá-lo acontece antes mesmo de entender o problema.
Mas Kubernetes não é uma solução universal. Ele resolve problemas específicos — e fora desse contexto, pode mais atrapalhar do que ajudar.
O que Kubernetes realmente resolve
Kubernetes não é sobre “rodar containers”. Ele resolve problemas de escala e operação:
- Orquestração de múltiplos containers
- Auto healing (recriação automática)
- Balanceamento de carga interno
- Deploys controlados (rolling update, rollback)
- Gestão de configuração e secrets
Se você não precisa disso, provavelmente não precisa de Kubernetes.
Quando faz sentido usar Kubernetes
1. Alta escala
- Muitas aplicações
- Muitos containers por aplicação
- Crescimento dinâmico
2. Alta disponibilidade real
- Aplicações críticas
- Zero downtime como requisito
3. Times maiores
- Vários times deployando continuamente
- Necessidade de padronização
4. Ambientes complexos
- Microservices
- Integrações intensas entre serviços
Quando Kubernetes é exagero
1. Aplicações simples
- WordPress
- GLPI
- Sistemas internos pequenos
2. Baixo volume de acesso
- Sites institucionais
- Ferramentas internas
3. Times enxutos
- Pouca gente para operar
- Sem dedicação exclusiva à plataforma
4. Falta de maturidade em containers
Se o básico ainda não está resolvido (Dockerfile, volumes, rede), Kubernetes só amplifica o problema.
O custo invisível do Kubernetes
Muita gente avalia só o custo de infraestrutura, mas ignora o principal:
Complexidade operacional
- Curva de aprendizado alta
- Troubleshooting mais difícil
- Mais componentes para manter
Tempo
- Setup inicial
- Ajustes finos
- Monitoramento
Dependência de conhecimento especializado
Não é trivial manter um cluster saudável.
Alternativas mais simples (e muitas vezes melhores)
Hoje existem opções que resolvem 80% dos cenários com muito menos esforço:
- Azure Container Apps
- AWS ECS / Fargate
- Google Cloud Run
- Docker Swarm (em alguns casos)
Essas plataformas entregam:
- Escala automática
- Deploy simples
- Menos overhead operacional
Um erro comum de arquitetura
Um padrão clássico:
“Vamos usar Kubernetes porque é o que o mercado usa”
Isso geralmente leva a:
- Overengineering
- Ambientes difíceis de manter
- Custos desnecessários
A decisão deveria ser baseada em necessidade real — não em tendência.
Um modelo simples de decisão
Antes de escolher Kubernetes, responda:
- Preciso escalar automaticamente?
- Tenho múltiplos serviços independentes?
- Tenho equipe para operar isso?
- Preciso de alta disponibilidade real?
Se a maioria das respostas for “não”, simplifique.
Conclusão
Kubernetes é uma ferramenta poderosa — mas não é neutra. Ele traz benefícios, mas também custos.
A melhor escolha não é a mais robusta, e sim a mais adequada ao contexto.
E muitas vezes, a melhor decisão é não usar Kubernetes.