Kubernetes Não É Padrão de Ouro: É Armadilha se Você Não Souber Por Quê Está Usando

A Dor Real: Quando o Cluster Vira a Aplicação

O erro clássico é simples: a equipe pega um app de duas APIs, um banco e um worker, e decide que precisa de K8s porque ‘todo mundo está usando’. Resultado: metade do backlog vira YAML, CRD, autoscaler, ingress, service mesh e logs custando um rim.

Aqui nasce a sobreengenharia: quando o problema real não é escala, resiliência ou multi-tenant, mas a ansiedade tecnológica.

Em fóruns como r/kubernetes e r/mlops, o padrão se repete: gente usando Helm charts gigantes, deployments com sidecars sem necessidade e clusters que custam mais do que a própria aplicação gera em receita. Todo mundo repete o mantra da nuvem, mas ignora o contexto de negócio.

A Solução Pragmática: Kubernetes Só Onde Ele Faz Sentido

Use K8s quando você realmente precisa de:

• Escala horizontal recorrente
• Tráfego instável ou picos intensos
• Time multipartes mantendo serviços independentes
• Observabilidade padronizada e pipelines maduros

Se o seu caso é menor que isso, considere k3s, ECS Fargate, Nomad ou até uma VM bem configurada. Cloud não é religião.

Implementação de Sênior: Como Checar Sobrecarga no Seu Cluster

Abaixo um checklist automatizável usando uma Job simples no cluster que detecta sobreengenharia básica inspirada em ferramentas como as citadas no r/mlops (ex.: k8s‑detective):

apiVersion: batch/v1
kind: Job
metadata:
  name: k8s-sanity-check
spec:
  template:
    spec:
      containers:
      - name: sanity
        image: bitnami/kubectl:latest
        command:
        - "/bin/bash"
        - "-c"
        - |
          echo "> Pods sem requests/limits:";
          kubectl get pods -A -o json | jq '.items[] | select(.spec.containers[].resources.requests.cpu == null)' | wc -l;
          echo "> Deployments com mais de 3 sidecars:";
          kubectl get deploy -A -o json | jq '.items[] | select(.spec.template.spec.containers | length > 3) | .metadata.name';
      restartPolicy: Never
  backoffLimit: 0

Isso é sênior porque ataca o problema real: excesso de camadas. Nada de poetizar arquitetura; identifique o que está pesando o cluster.

Direto das Trincheiras

• Se você precisa de mais de 10 CRDs para rodar sua app, pare e pergunte: o sistema está servindo a você ou você está servindo ao sistema?
• Log custa dinheiro. O New Relic já bate nessa tecla. Defina TTL curtos para logs de debug e sempre traceie antes de logar.
• Evite service mesh até o último momento. 80% dos sistemas não precisam disso, só confundem o time.

O Custo da Escolha: Kubernetes Não É de Graça

Adotar K8s cedo demais cria três dívidas pesadas:

• Custo operacional (clusters inchados, nós subutilizados, storage mal configurado)
• Custo cognitivo (onboarding lento, debugging mais complexo)
• Custo financeiro (logs, métricas e monitoramento podem virar uma bola de neve)

Não usar Kubernetes também tem custo: menos automação, menos isolamento e menos elasticidade. Mas é um trade-off consciente, não uma receita universal.

Fontes

CodeModeToon : r/mlops, How to Optimize Log Management Costs Ebook | New Relic, K8s é muito complexo. Posso k3s em produção? : r/kubernetes

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! 😉