Kubernetes Rescue

Estabilizar e baratear um cluster que já está em produção

Kubernetes cobra em operação o que entrega em flexibilidade. Quando a conta deixa de fechar, entramos para achar a causa, estabilizar o ambiente e devolver um cluster que o seu time consegue tocar.

A primeira conversa não tem custo e não vira proposta automática.

  • Estabilização primeiro
  • Custo medido antes e depois
  • Runbook e plano de upgrade

Sinais de que o cluster precisa disso

Estes são os motivos mais comuns de quem chega até aqui.

  • Pods reiniciam, nós saturam e deploys travam sem explicação.
  • O custo dos nós cresceu, mas a utilização real é baixa: requests e limits nunca foram revisados.
  • O upgrade de versão é adiado há três ciclos por medo de derrubar produção.
  • Ingress, DNS ou rede falham de forma intermitente e ninguém reproduz.
  • RBAC e segredos foram sendo concedidos por exceção, e viraram a regra.
  • Não existe backup do estado do cluster nem plano para recriá-lo.

Para quem

  • Empresas que rodam produto em EKS, GKE ou AKS sem alguém dedicado ao cluster.
  • Times que herdaram um cluster montado por um fornecedor ou por quem já saiu.
  • Quem está avaliando se Kubernetes ainda faz sentido para o tamanho atual do produto.

Como funciona

Estabilização primeiro, otimização depois. Misturar as duas é como se corrige um sintoma e se perde a causa.

  1. Avaliação

    Estabilidade, custo, capacidade, autoscaling, rede, ingress, versões, RBAC, backup e observabilidade. O objetivo é separar causa de sintoma.

  2. Estabilização

    Correções na ordem do impacto em produção: recursos, probes, disrupção, escalonamento, ingress e o que estiver derrubando o ambiente.

  3. Otimização

    Node pools, requests e limits, autoscaling e compromissos de consumo ajustados ao uso real, com o custo medido antes e depois.

  4. Entrega

    Cluster documentado, mudanças em infraestrutura como código, runbook das operações comuns e um plano de upgrade. Se quiser, seguimos operando.

O que você recebe

Um cluster que o seu time entende. Não uma dependência nova.

  • Diagnóstico com as causas identificadas e as correções na ordem de impacto.
  • Ambiente estabilizado, com cada mudança revisável e reversível.
  • Capacidade e autoscaling ajustados ao uso real, com o custo medido antes e depois.
  • Observabilidade de cluster e de aplicação, com alerta que aponta causa.
  • Backup do estado do cluster e recuperação testada.
  • Documentação, runbooks e plano de upgrade.

O que não prometemos

  • Não vendemos plantão emergencial 24 por 7. Atendimento fora do horário comercial é combinado caso a caso.
  • Não garantimos percentual de redução antes de olhar o cluster. O número vem da medição.
  • Se Kubernetes não fizer sentido para o seu estágio, dizemos isso e propomos o caminho mais simples.
  • Nossa profundidade maior é em EKS e GKE. Em AKS aplicamos o mesmo método, e somos claros sobre o que é novo para nós.

Perguntas frequentes

O cluster está caindo agora. Dá para começar rápido?

Escreva descrevendo o cenário. Quando há urgência, fechamos primeiro um escopo de estabilização e o resto vem depois. O que não fazemos é prometer atendimento imediato antes de conversar.

Vocês consertam o cluster ou refazem?

Depende do estado. Quando o cluster foi criado na mão e não existe infraestrutura como código, recriar com Terraform costuma ser mais seguro do que consertar. A decisão sai da avaliação, com o seu time.

Trabalham com qual distribuição?

EKS na AWS e GKE no Google Cloud são onde temos mais horas. Também atendemos AKS e k3s em ambientes menores.

Vocês podem operar depois?

Sim. O Managed DevOps cobre o acompanhamento recorrente do cluster, dos pipelines e do custo.

Descreva o cluster.

Com os sintomas e o tamanho do ambiente, já conseguimos dizer o que investigaríamos primeiro.

A primeira conversa não tem custo e não vira proposta automática.