GitHub

A maioria das equipes que migra para Kubernetes chega lá convencida de que está resolvendo um problema de infraestrutura. O que elas descobrem, geralmente seis meses depois, é que trocaram um conjunto de problemas por outro muito mais sofisticado — e que a complexidade operacional que elas achavam ter eliminado simplesmente mudou de endereço.

O que Kubernetes realmente faz bem

Kubernetes nasceu para resolver um problema concreto: orquestrar contêineres em escala, com resiliência e capacidade de recuperação automática. Ele faz isso muito bem. Se sua organização opera dezenas de serviços com padrões de tráfego variáveis, precisa de deploys sem downtime, e tem time com maturidade para operar a plataforma, Kubernetes entrega valor real.

O agendamento de workloads, a gestão de recursos, o suporte a estratégias de rollout progressivo e a integração com ferramentas de observabilidade são genuinamente bons. Esses benefícios não são marketing — eles existem, funcionam e fazem diferença em produção.

O problema não é o que Kubernetes promete. É o que ele cobra em troca.

A complexidade que aparece depois da migração

Networking em Kubernetes não é uma configuração simples. É uma camada inteira de abstração — CNI plugins, Service meshes, políticas de rede, DNS interno, ingress controllers — que você precisa entender, manter e depurar quando algo quebra. E algo vai quebrar.

Storage é outro ponto de atrito que a maioria subestima. Volumes persistentes, StorageClasses, modos de acesso, snapshots, backup de PVCs: tudo isso precisa ser projetado com cuidado. Aplicações stateful em Kubernetes são significativamente mais complexas do que as mesmas aplicações rodando em máquinas virtuais convencionais.

RBAC, por sua vez, é o tipo de coisa que ninguém documenta bem durante a migração e que se transforma em dívida técnica em questão de semanas. Definir permissões granulares para namespaces, service accounts e workloads distintos exige disciplina que equipes sob pressão de entrega raramente conseguem manter.

Upgrades de cluster são outro capítulo. Kubernetes tem ciclo de vida agressivo: versões ficam obsoletas rápido, e cada upgrade exige validação de compatibilidade de APIs, manifests, Helm charts e operadores. Ignorar isso por alguns meses e você estará operando uma versão sem suporte em produção.

O paradoxo do SRE

Existe uma ironia bem conhecida em times que adotam Kubernetes sem planejamento adequado: você precisa de engenheiros de confiabilidade experientes para operar a ferramenta que deveria reduzir a necessidade de operação manual. O Kubernetes foi construído para Google-scale. Ele carrega essa herança.

Equipes pequenas frequentemente descobrem que estão gastando mais tempo operando a plataforma do que desenvolvendo produto. Cada incidente envolve logs de múltiplos pods, rastreamento de eventos de scheduling, análise de limites de recursos e debugging de rede que só faz sentido para quem conhece profundamente as abstrações internas.

Isso não é um defeito de design. É uma consequência direta da generalidade da plataforma. Kubernetes resolve problemas complexos de forma complexa — e essa complexidade não desaparece só porque os contêineres estão rodando.

Quando Kubernetes gerenciado muda o cálculo

EKS, GKE e AKS não eliminam a complexidade operacional, mas distribuem parte dela para o provedor de nuvem. O plano de controle — etcd, API server, scheduler, controller manager — fica sob responsabilidade do provedor. Upgrades de versão se tornam menos traumáticos. Integração com serviços de identidade, storage e rede do provedor vem pré-configurada.

Para equipes que já operam dentro de um provedor de nuvem específico, Kubernetes gerenciado reduz o custo de entrada de forma significativa. Não é zero, mas é substancialmente menor do que operar um cluster self-managed.

O cálculo muda novamente quando você considera lock-in. GKE Autopilot, por exemplo, abstrai tanto que você perde controle sobre scheduling e configuração de nodes. É uma troca válida para alguns times — e inaceitável para outros. A escolha depende de onde você quer soberania e onde aceita delegar.

Quando uma estratégia mais simples é a decisão inteligente

Kubernetes não é a resposta correta para todo workload. Se você opera um monolito bem estruturado com tráfego previsível, uma instância EC2 bem configurada com um processo de deploy automatizado pode ser mais confiável, mais barata e muito mais fácil de operar.

Ferramentas como Fly.io, Railway, Render ou mesmo AWS App Runner entregam a maioria dos benefícios operacionais de Kubernetes — zero downtime, scaling automático, rollbacks — sem a camada de abstrações que exige especialistas para manter.

A pergunta que as equipes raramente fazem antes de migrar é direta: qual problema específico o Kubernetes vai resolver que a infraestrutura atual não consegue? Se a resposta for vaga — "escalabilidade", "modernização", "melhor gestão de contêineres" — o investimento operacional provavelmente não se justifica.

Kubernetes faz sentido quando você tem múltiplos serviços com ciclos de deploy independentes, necessidade de isolamento entre workloads, padrões de tráfego altamente variáveis, e uma equipe com capacidade real de operar a plataforma. Esses quatro critérios juntos raramente aparecem antes de uma organização ter dezenas de engenheiros e anos de maturidade em contêineres.

A decisão que acontece na hora errada

A migração para Kubernetes quase sempre acontece no momento de menor preparo. A equipe está crescendo, a pressão por escalabilidade apareceu, alguém viu uma talk no KubeCon — e a decisão é tomada antes que o time tenha experiência suficiente para entender o que está assumindo.

O resultado típico: seis meses de esforço para migrar, seguidos de outros seis tentando estabilizar o ambiente. Os problemas que motivaram a migração — deploys frágeis, falta de isolamento, dificuldade de escalar — continuam existindo, agora com uma camada a mais de diagnóstico.

Isso não significa que a migração foi errada. Significa que ela precisava de mais planejamento, de um cronograma realista e de capacitação antes da execução. Kubernetes é uma plataforma poderosa. Mas poder e simplicidade raramente coexistem — e quem não entende essa distinção aprende depois que a decisão já foi tomada.