A Dor Real: O Cluster Que Escala Tudo, Menos Seu Produto
O problema não começa no Kubernetes; começa no time que compra o hype achando que “escalabilidade” é sinônimo de “orquestrador distribuído”. A verdade nua: Kubernetes resolve problemas de gente grande, mas cria novos gargalos para times que ainda estão lutando com deploys manuais, pipelines instáveis e serviços que mal escalam verticalmente.
O paradoxo aparece quando o cluster cresce, mas o throughput do negócio continua o mesmo. O gargalo deixa de ser a infraestrutura e vira a arquitetura — mais especificamente, o excesso de peças que o próprio Kubernetes incentiva quando usado sem critério.
Se você não tem clareza do fluxo da sua aplicação, Kubernetes só vai empilhar dívida técnica mais rápido.
A Solução Pragmática: Limitar o Escopo e Medir Gargalos de Verdade
Antes de falar em pods, nodes e autoscaling, você precisa identificar o gargalo real. A Teoria das Restrições é direta: otimize o que trava o fluxo. Spoiler: quase nunca é falta de orquestração distribuída.
Se sua aplicação não bate 1k RPS de forma consistente, provavelmente o gargalo está em lógica de negócio, queries ruins, filas mal dimensionadas ou I/O travando tudo.
Kubernetes só entra na equação quando:
- A arquitetura é naturalmente distribuída.
- Os serviços têm requisitos de isolamento, disponibilidade e observabilidade que valem o custo.
- A equipe tem maturidade para operar o cluster sem virar refém de YAML duplicado e deploys quebrados.
Implementação de Sênior: Observando o Gargalo Com Métricas e Autoscaling Real
Quer saber se o Kubernetes é gargalo? Meça.
Abaixo um exemplo de configuração de HPA (Horizontal Pod Autoscaler) realmente funcional, que aponta diretamente onde dói: consumo de CPU e latência de aplicação.
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
name: api-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: api-service
minReplicas: 2
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70
- type: Pods
pods:
metric:
name: request_latency_ms
target:
type: AverageValue
averageValue: 200
Repare que incluímos latência como métrica de verdade — porque throughput ruim não se resolve com mais pods, e sim entendendo o fluxo que limita o sistema.
Quer algo ainda mais direto? Um diagrama simples do fluxo de gargalo:
Client -> API Gateway -> Service A -> Database
|-> Queue -> Worker -> External API
Se Service A está lento:
- aumentar pods não resolve query ruim
- retries excessivos matam o cluster
- Kubernetes apenas amplifica o caos
O Custo da Escolha: Kubernetes Pode Ser uma Âncora
Kubernetes dá superpoderes, mas cobra pedágio alto.
Os principais custos:
- Stack operacional enorme (Prometheus, Grafana, Ingress, Service Mesh…).
- Fragmentação da lógica de deploy: configuração vira outro sistema para manter.
- Escalabilidade que escala custo antes de escalar valor.
- Times júniores totalmente travados em problemas que nada têm a ver com produto.
Por outro lado, não usar Kubernetes também tem custos:
- Escalabilidade manual cansativa.
- Dificuldade de automação.
- Ambientes inconsistentes.
A decisão final é simples: Kubernetes só vale quando o negócio precisa, não quando o arquiteto quer.
Direto das Trincheiras
- Se você não monitora latência e throughput, não tem maturidade para Kubernetes.
- Antes de migrar, reescreva os piores serviços: containerizar lixo só cria lixo distribuído.
- Simplifique: service mesh não é obrigatório; às vezes um Ingress bem configurado resolve.
Fontes Utilizadas
Diretório de artigos, Framework Well-Architected da AWS – Framework, Sistemas Operacionais – Fundamentos, Evolução e Arquitetura …
Obrigado por acompanhar essa reflexão até o fim!
Espero que esses pontos ajudem você a tomar decisões mais lúcidas no seu próximo projeto. Não deixe de conferir outros artigos aqui no blog reymaster.dev.br, onde descascamos outros hypes da área.
Vlw, até a próxima! 😉
