Kubernetes: quando não usar (e o que usar no lugar)

Kubernetes virou sinônimo de infraestrutura moderna, o que é ruim para quem precisa decidir. Sinônimo de moderno não é critério — critério é o problema que a ferramenta resolve e o preço que ela cobra.

Ele resolve problemas de operação em escala, e resolve bem. O preço é uma camada permanente de complexidade que não desaparece depois da configuração inicial: ela aparece em todo diagnóstico, em toda atualização e em toda contratação.

A pergunta útil não é se Kubernetes é bom. É se você tem o problema dele.

O que ele resolve de fato

Vale enumerar com honestidade, porque cada item é real:

• Reconciliação contínua. Você declara o estado desejado e o sistema trabalha para mantê-lo. Container que morre volta, máquina que sai tem a carga redistribuída.
• Implantação progressiva. Atualização gradual, com verificação de saúde e retorno automático se algo degradar.
• Escala horizontal automática, respondendo a métricas.
• Abstração de infraestrutura. A mesma descrição roda em provedores diferentes.
• Vocabulário comum. Uma equipe grande compartilha os mesmos conceitos, e a descrição da aplicação é padronizada.

Esse último é subestimado e talvez seja o mais valioso em organização grande: com quarenta serviços e seis equipes, ter um jeito único de descrever "como isto roda" vale muito.

O custo que raramente é contabilizado

O que não aparece na avaliação inicial:

• Cinco camadas entre a requisição e o processo. Ingress, Service, Pod, container, aplicação. Um 502 pode nascer em qualquer uma, e diagnosticar exige conhecer todas.
• Atualização do cluster. Kubernetes tem ciclo de versões rápido e janela de suporte curta. Você atualiza o cluster várias vezes ao ano, e cada atualização é uma operação de risco.
• Rede que exige estudo. Plugin de rede, política de tráfego, DNS interno, descoberta de serviço. Nada disso é intuitivo.
• Estado é difícil. Rodar banco de dados dentro do cluster é possível e é notoriamente trabalhoso. A maioria acaba com o banco fora, o que enfraquece o argumento da abstração.
• Custo de base. O plano de controle e os componentes de sistema consomem recurso antes de qualquer aplicação sua subir.
• Contratação e continuidade. Você passa a precisar de gente com esse conhecimento específico, e a passagem de bastão fica mais cara.

Nenhum item é impeditivo. Somados, formam um custo fixo — e custo fixo só se paga com volume.

Os sinais de que ainda não é hora

Alguns indicadores razoavelmente objetivos:

• Menos de dez serviços distintos. Abaixo disso, a coordenação não é o gargalo.
• Uma ou duas pessoas cuidando de infraestrutura. O cluster vai consumir uma fatia relevante do tempo delas.
• Carga previsível. Sem picos bruscos, a escala automática não tem o que fazer.
• Implantação uma ou duas vezes por semana. O ganho de automação é pequeno nessa frequência.
• Nenhum requisito de alta disponibilidade contratual. Se algumas dezenas de segundos de indisponibilidade em uma atualização são aceitáveis, arranjos bem mais simples atendem.
• "Vamos precisar disso quando crescermos." Talvez. E migrar depois, com o problema real em mãos, costuma custar menos que operar a complexidade por dois anos esperando o crescimento.

O que resolve os mesmos problemas, mais barato

Vale mapear item a item, porque a discussão costuma ser tratada como tudo ou nada.

Container que reinicia sozinho. É restart: unless-stopped no compose, ou Restart=on-failure no systemd. Um serviço que volta ao morrer não exige orquestrador — o assunto está detalhado nos artigos sobre Docker em produção e escrever units.

Implantação sem downtime. Subir a versão nova ao lado e trocar o destino é possível com um proxy reverso e duas linhas de configuração. Para site estático, um link simbólico trocado atomicamente resolve, como no artigo sobre rsync.

Escala horizontal. Duas ou três VMs atrás de um balanceador atendem uma faixa enorme de carga. Adicionar a quarta é uma operação de minutos, e a criação de VPS leva cerca de um minuto.

Isolamento de recurso. Cgroups pelo systemd, como no artigo sobre limitar CPU e IO, entregam contenção por serviço sem nenhuma camada nova.

Infraestrutura declarativa. OpenTofu ou Ansible descrevem servidores em arquivo versionado. Você tem o benefício da descrição reproduzível sem o plano de controle.

Verificação de saúde e recuperação. Healthcheck no compose, ou um teste externo que reinicia o serviço quando ele para de responder.

Quando Kubernetes é a resposta certa

Para não parecer que a conclusão é sempre "não". Ele compensa quando:

• Há dezenas de serviços com ciclos de vida independentes e equipes diferentes implantando.
• A carga varia muito, e escalar manualmente já custou incidente ou dinheiro.
• Implantações são frequentes — várias por dia, por várias equipes.
• Multi-inquilino com isolamento por namespace e cota é requisito.
• Já existe conhecimento na equipe, e não é uma aposta de aprendizado.
• Um serviço gerenciado assume o plano de controle, o que remove a parte mais trabalhosa da conta.

Repare que esses cenários descrevem organizações que já cresceram. É exatamente o público para quem a ferramenta foi construída.

O meio-termo que costuma ser esquecido

Entre "compose numa VM" e "cluster Kubernetes" existe bastante espaço, e é onde a maioria das operações brasileiras de porte médio vive bem:

Duas ou três VMs com compose e um balanceador na frente. Redundância real, implantação por script, e nenhuma abstração nova. Se uma máquina cair, o balanceador tira do rodízio.

Orquestradores mais simples. Existem opções que entregam agendamento e reconciliação com uma fração dos conceitos.

Kubernetes leve gerenciado, quando a decisão é mesmo por ele. Distribuições enxutas reduzem bastante o custo operacional em relação a montar o cluster completo à mão.

O ponto é que a escolha não é binária. Cada degrau resolve um conjunto de problemas e cobra um preço — e vale subir um degrau por vez, quando o degrau atual doer.

Uma pergunta que orienta a decisão

Antes de adotar, vale responder por escrito: qual problema concreto, que já aconteceu, isso resolve?

Se a resposta descreve um incidente real — "ficamos duas horas fora porque a máquina morreu e ninguém percebeu", "a implantação derrubou o site na quinta" —, o passo seguinte é avaliar qual ferramenta resolve aquilo, e Kubernetes pode ser a resposta ou não.

Se a resposta é hipotética — "quando tivermos muito tráfego", "é o padrão do mercado" —, o custo é certo e o benefício é especulativo.

Vale acrescentar uma segunda pergunta, menos confortável: quem opera isso quando a pessoa que montou sair? Infraestrutura que só uma pessoa entende é um risco independente da tecnologia, e Kubernetes concentra esse risco mais que a média.

A infraestrutura mais adequada não é a mais avançada — é a que a sua equipe consegue operar com segurança às três da manhã. Para muita gente isso significa um cluster bem configurado. Para muita gente significa duas VMs, compose e um script de deploy que cabe em uma página — e não há nada de atrasado nisso.

O custo que aparece só no segundo ano

Há uma assimetria temporal que engana bastante na avaliação inicial. Montar um cluster é um projeto com começo, meio e fim — e projetos são fáceis de justificar, porque o esforço é visível e limitado.

Operar o cluster é uma despesa contínua que ninguém orçou. Ela aparece como atualização de versão a cada poucos meses, como certificado interno que expira, como plugin de rede que muda de comportamento, e como a tarde inteira gasta para descobrir que o problema era uma política de tráfego escrita há um ano por alguém que já saiu.

Vale conversar com quem opera cluster há mais de dois anos antes de decidir. A avaliação de quem acabou de montar é sistematicamente mais otimista que a de quem já passou por três ciclos de atualização.

Isso não é argumento contra a ferramenta — é argumento a favor de contabilizar o custo inteiro. Uma decisão tomada com os dois anos na conta costuma ser diferente da tomada com a semana de instalação na conta.

O caminho de volta também importa

Uma última consideração, raramente feita: sair do Kubernetes é mais difícil que entrar.

A aplicação passa a depender de conceitos dele — descoberta de serviço por DNS interno, configuração injetada por objetos próprios, armazenamento abstraído. Nada disso existe fora, e migrar de volta significa reescrever a camada de implantação inteira.

Não é motivo para não adotar. É motivo para adotar quando a decisão estiver sustentada por um problema real, e não por expectativa — porque a reversão custa caro o suficiente para que ninguém a faça, e a equipe acaba mantendo por inércia uma complexidade que nunca precisou.