Kubernetes: o que é, o que não é, e por que todo mundo finge que entende
K8s virou palavra de ordem em qualquer conversa sobre infra. Mas o que ele realmente faz — e quando você não precisa dele — fica perdido no hype.
Tem uma pergunta que eu aprendi a fazer em entrevistas técnicas antes de falar sobre Kubernetes: "você já rodou Kubernetes em produção?"
Não porque quero eliminar candidatos. Mas porque a resposta muda completamente o que vem a seguir. Quem rodou em produção fala sobre problemas reais. Quem não rodou fala sobre o que leu na documentação. São conversas muito diferentes.
Kubernetes virou o currículo obrigatório de qualquer pessoa que quer soar relevante em infra. E com isso veio um problema: a maioria das pessoas sabe falar K8s, mas poucos entendem o que ele realmente resolve.
Kubernetes é um orquestrador de containers. O que isso significa na prática: você tem containers rodando sua aplicação, e o Kubernetes decide onde, quando e quantas instâncias rodam — e mantém esse estado desejado mesmo quando coisas falham.
Se um nó cai, o Kubernetes move os containers para outro nó. Se a carga aumenta, você configura o autoscaler e ele cria mais instâncias. Se um container trava, o Kubernetes mata e recria.
Parece simples. E conceitualmente é. O problema é a implementação: Kubernetes tem pelo menos dez abstrações que você precisa entender antes de fazer um deploy funcionar — Pod, Deployment, Service, Ingress, ConfigMap, Secret, Namespace, ReplicaSet, HorizontalPodAutoscaler, PersistentVolume. E cada uma tem comportamentos implícitos que você descobre quando algo quebra.
O que Kubernetes não é: solução para problema de software ruim.
Se sua aplicação tem memory leak, Kubernetes vai reiniciar os containers e mascarar o problema por um tempo. Se sua aplicação tem race conditions, rodar em múltiplas réplicas vai amplificar o problema. Se seu banco de dados está mal modelado, Kubernetes não vai ajudar.
Kubernetes resolve problemas de operação, não de engenharia de software. E muita gente confunde as duas coisas.
Quando você precisa de Kubernetes? Quando você tem múltiplos serviços que precisam escalar independentemente, quando você quer garantia de disponibilidade sem gerenciar servidores individuais, quando você tem equipes diferentes deployando coisas diferentes no mesmo cluster de forma isolada.
Quando você não precisa de Kubernetes? Quando você tem uma aplicação, um banco de dados, e um servidor. Quando sua startup tem cinco usuários. Quando o custo operacional de manter um cluster supera o benefício que ele traz.
Um servidor com Docker Compose atende 90% dos casos de uso de startups em fase inicial. Fui operar um cluster Kubernetes com um único serviço de baixa carga e passei mais tempo gerenciando o cluster do que desenvolvendo o produto.
A curva de aprendizado é real e não é trivial. Meu primeiro deploy em Kubernetes levou três dias. Não três dias de trabalho intenso — três dias de "por que isso não está subindo?", "o que esse erro quer dizer?", "por que o pod está em CrashLoopBackOff se eu copiei o exemplo da documentação?".
Kubernetes tem uma linguagem própria. E você precisa aprender essa linguagem antes de conseguir ser produtivo. Não tem atalho aqui.
A coisa mais honesta que posso dizer sobre Kubernetes: é uma ferramenta poderosa para problemas específicos, que tem um custo operacional alto, e que a maioria das pessoas usa antes de precisar porque virou status.
Isso não é crítica. É contexto. A ferramenta certa para o problema certo é boa engenharia. A ferramenta mais impressionante para qualquer problema é desperdício de energia.
Essa semana: se você está estudando Kubernetes, pergunta antes de tudo: qual problema real você quer resolver com ele? Se a resposta for "quero aprender", ótimo. Se for "minha empresa precisa", entende primeiro qual problema de operação vocês têm que o Kubernetes endereça — e se não houver um problema claro, questiona a decisão.