Kubernetes: Quando a Promessa de Escala Vira Dívida Técnica em Microserviços

A Dor Real: O dia em que o cluster virou o seu maior inimigo

Microserviços já são complicados por natureza. Agora junte isso com um Kubernetes mal planejado e você cria um monstro corporativo que ninguém controla. **A promessa de elasticidade vira uma fábrica de incidentes.**

O que vejo nas trincheiras é simples: times adotam Kubernetes achando que é “só subir os YAMLs”. Mas esquecem que cada microserviço precisa de:

• Política de rede
• Gerenciamento de secrets
• Health checks bem escritos
• Requests/limits realistas
• Banco de dados resiliente a picos inesperados

Quando o cluster escala errado, quem paga é o banco de dados — e aí nasce a **dívida técnica mais cara**: incidentes silenciosos de performance, difícil rastreabilidade e um grafo de dependências que ninguém mais entende.

A Solução Pragmática: Simplifique antes de orquestrar

A saída não é abolir o Kubernetes. É entendê-lo no contexto de negócio. Se sua empresa não tem tráfego imprevisível e não faz deploy contínuo de centenas de serviços por dia, você provavelmente não precisa de um cluster com 40 operadores rodando de fundo.

Pragmatismo significa:

• Usar plataformas que escondem a complexidade quando faz sentido (como Fury ou soluções gerenciadas).
• Deixar o Kubernetes para times com maturidade real em observabilidade e automação.
• Evitar o over-engineering: container não é desculpa para transformar seu banco em um pesadelo distribuído.

Implementação de Sênior: Observabilidade antes de escalar

Quer evitar que o Kubernetes destrua seu banco? Monitore o impacto de cada microserviço no cluster e no banco antes de liberar autoscaling.

Aqui vai um exemplo realista de configuração HPA com limites seguros e um endpoint bem definido para health check:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: pedidos-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: pedidos-service
  minReplicas: 2
  maxReplicas: 6
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60
---
apiVersion: v1
kind: Service
metadata:
  name: pedidos-liveness
spec:
  selector:
    app: pedidos
  ports:
    - port: 8080
      targetPort: 8080
---
# Exemplo de endpoint real para saúde do serviço
# (Node.js apenas como referência)
const express = require('express');
const app = express();

app.get('/health', async (req, res) => {
  const dbOk = await pingDatabase();
  if (!dbOk) return res.status(500).send('DB-error');
  res.send('OK');
});

Esse é o mínimo para não transformar o cluster em um canhão apontado diretamente para o seu banco.

Direto das Trincheiras

• Evite autoscaling sem proteção no banco: ele vai escalar antes do seu RDS/CloudSQL conseguir acompanhar.
• Reduza microserviços que só existem para atender diagramas bonitos — serviços “finos demais” explodem o tráfego interno.
• Antes de migrar para Kubernetes, descubra o que realmente dói: implantação? resiliência? rastreabilidade? Kubernetes não resolve cultura ruim.

O Custo da Escolha: Kubernetes não é neutro

Adotar Kubernetes cedo demais cria uma dívida técnica operacional difícil de pagar. Mas ignorá-lo quando o negócio exige escala agressiva também é um erro caro.

Você precisa entender quando:

• Usar: seu tráfego é volátil, você faz centenas de deploys/dia, e seu time domina automação.
• Evitar: você só quer subir meia dúzia de serviços e manter o banco saudável.

No fim, a questão não é Kubernetes. É maturidade.

Fontes

30.000 deploys diários: desvendando os segredos do Mercado Livre

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, onde descascamos outros hypes da nossa área.

Valeu e até a próxima! 😉