Kubernetes se tornou o símbolo de que uma empresa "faz infra de verdade" — mas essa reputação carrega um custo que poucos calculam antes de adotar. Em conversas com times de engenharia de startups em crescimento, o padrão se repete: alguém leu sobre K8s, viu que empresas grandes usam, e propôs migrar. Seis meses depois, boa parte do tempo do time está em operação de cluster, não em produto.
Resumo rápido: Kubernetes é uma ferramenta poderosa para orquestração de containers em escala, mas exige maturidade operacional, time dedicado e complexidade que muitas startups não precisam. Docker Compose, K3s e PaaS gerenciados resolvem a maioria dos problemas com muito menos overhead. K8s vale quando você tem múltiplos serviços, times diferentes deployando de forma independente e carga que justifica orquestração complexa.
O que Kubernetes realmente é — e o que ele faz por você
Kubernetes é um sistema de orquestração de containers. Ele gerencia onde seus containers rodam, reinicia automaticamente containers que morrem, distribui carga entre réplicas, gerencia secrets e configurações, e fornece mecanismos para deploys sem downtime.
Esses problemas são reais. Mas a questão é: você já tem esses problemas?
Se você tem um único servidor, três serviços e um time de cinco pessoas, a maioria desses problemas pode ser resolvida com ferramentas ordens de magnitude mais simples. Kubernetes não resolve problema de escala que você ainda não tem — ele cria complexidade operacional para uma escala futura hipotética.
A abstração do K8s é poderosa e, ao mesmo tempo, o maior obstáculo de entrada. Pods, ReplicaSets, Deployments, Services, Ingress, ConfigMaps, Secrets, PersistentVolumes, Namespaces, RBAC, NetworkPolicies — são conceitos que um time precisa dominar antes de colocar qualquer carga de trabalho real em produção. E cada um deles tem edge cases que aparecem exatamente no pior momento.
Docker Compose em produção: mais longe do que você imagina
Docker Compose é frequentemente descartado como "ferramenta de desenvolvimento", mas essa visão subestima o que ele entrega em produção.
Para uma operação com menos de dez serviços, um ou dois servidores, e um time pequeno, o Compose resolve de forma elegante: sobe todos os serviços com um único comando, define dependências entre containers, gerencia volumes e redes internas, e aceita variáveis de ambiente sem exposição de secrets no repositório.
O que ele não faz: distribuir containers entre múltiplos servidores automaticamente, reiniciar containers em outro host se o servidor morrer, ou orquestrar deploys graduais (canary, blue/green) de forma nativa.
Se esses três pontos não são problemas que você enfrenta hoje, o Compose é a escolha racional. Ele é auditável, compreensível por qualquer pessoa que saiba Docker, e o arquivo docker-compose.yml cabe em uma única tela.
K3s: Kubernetes sem o peso do Kubernetes
K3s é uma distribuição de Kubernetes certificada, desenvolvida pela Rancher, com um binário único de menos de 100 MB. Ele inclui tudo que você precisa para um cluster funcional — incluindo kubectl, controlador de ingress e gerenciamento de certificados TLS — sem as dependências pesadas da instalação padrão.
Para startups que precisam de orquestração multi-nó mas não querem operar EKS, GKE ou AKS, o K3s é o meio-termo mais honesto. Você tem a API do Kubernetes, pode usar Helm Charts, pode rodar Argo CD para GitOps — mas com uma footprint operacional muito menor.
K3s funciona bem em servidores ARM (Hetzner CAX, Oracle Ampere), o que abre a possibilidade de clusters de alto desempenho com custo mensal baixo. Dois nodes de K3s num CAX21 da Hetzner podem ser suficientes para a maioria das cargas de startups em fase de crescimento. É esse tipo de decisão de arquitetura — K3s vs. K8s gerenciado, ARM vs. x86, custo vs. SLA — que o time de DevOps da MaxVision avalia junto com o cliente antes de qualquer migração.
Quando o Kubernetes gerenciado (EKS, GKE, AKS) faz sentido
Kubernetes gerenciado pela cloud tira de você a responsabilidade de operar o control plane — o conjunto de componentes que gerencia o estado do cluster. Você ainda opera os nodes e tudo que roda neles, mas não precisa se preocupar com etcd, kube-apiserver ou upgrades do control plane.
Os casos em que isso começa a fazer sentido:
- Múltiplos times deployando serviços de forma independente, com necessidade de isolamento por namespace
- Carga que justifica autoscaling horizontal automático (HPA) — serviços que sobem para dezenas de réplicas em picos e precisam reduzir automaticamente
- Requisitos de compliance que exigem auditoria de acesso granular (RBAC detalhado, audit logs)
- Estratégias de deploy sofisticadas (canary releases, circuit breakers) que ferramentas como Argo Rollouts gerenciam bem
Note que nenhum desses pontos é "quero usar Kubernetes porque é moderno". Todos são problemas operacionais concretos que uma startup raramente tem antes de atingir escala real.
PaaS: a alternativa que poucos consideram seriamente
Plataformas como Railway, Render, Fly.io e Northflank entregam boa parte do que Kubernetes promete — deploy automático, scaling, SSL, preview environments — sem exigir que você entenda o que é um CrashLoopBackOff.
Para produtos em validação, MVPs e SaaS com até alguns milhares de usuários, um PaaS bem escolhido costuma ser a decisão mais inteligente. O custo por compute pode ser maior do que gerenciar sua própria infra, mas o custo de engenharia para operar Kubernetes é real e frequentemente subestimado.
O ponto de inflexão onde o PaaS para de fazer sentido geralmente chega quando a conta mensal ultrapassa o salário de um engenheiro de infra — ou quando você tem requisitos que o PaaS simplesmente não cobre (dados que não podem sair do seu ambiente, hardware específico, integrações com redes privadas).
A tabela que você deveria ver antes de decidir
| Dimensão | Docker Compose | K3s | K8s Gerenciado | PaaS |
|---|---|---|---|---|
| Curva de aprendizado | Baixa | Moderada | Alta | Muito baixa |
| Multi-servidor | Nao nativo | Sim | Sim | Sim (gerenciado) |
| Custo infra | Barato (1 servidor) | Barato (ARM possivel) | Moderado a alto | Moderado a alto |
| Custo operacional | Muito baixo | Baixo a moderado | Alto | Quase zero |
| Autoscaling | Manual | Sim (HPA) | Sim (HPA + Cluster Autoscaler) | Sim (gerenciado) |
| GitOps / CD avancado | Manual | Argo CD possivel | Argo CD, Flux | Integrado |
| Isolamento por time | Limitado | Namespaces | Namespaces + RBAC completo | Projetos isolados |
| Adequado para | 1-2 servidores, time pequeno | Crescimento, ARM, IoT | Times multiplos, escala real | Validacao, MVP, SaaS |
Os sinais reais de que você precisa de Kubernetes
Em vez de migrar por antecipação, vale observar se esses sinais aparecem na sua operação:
Você tem mais de um time deployando serviços que não podem interferir entre si. Quando dois times precisam de isolamento real de recursos, namespaces do Kubernetes entregam isso de forma limpa.
Você sofreu downtime por falha de um único servidor e não tinha como realocar carga automaticamente. Kubernetes com múltiplos nodes redistribui pods automaticamente em caso de falha de node.
Seu autoscaling hoje é manual — alguém acorda às 3h para subir instâncias. HPA (Horizontal Pod Autoscaler) resolve isso de forma automática e auditável.
Você gerencia mais de quinze serviços diferentes com ciclos de deploy independentes. A partir desse número, a orquestração manual começa a criar dependências e erros difíceis de rastrear.
Seu custo de nuvem está crescendo mais rápido do que sua receita e você não tem visibilidade de qual serviço consome o quê. Kubernetes com métricas por namespace dá essa visibilidade.
Se você identificou dois ou mais desses sinais, a conversa sobre Kubernetes começa a ser fundamentada. Qualquer coisa abaixo disso, vale revisitar as alternativas primeiro.
O custo real de operar Kubernetes que ninguém conta
Kubernetes não é um sistema que você "instala e esquece". Ele exige manutenção contínua:
Upgrades de versão seguem um ciclo regular, e versões antigas perdem suporte. Cada upgrade pode quebrar dependências de aplicações que não estavam preparadas para mudanças de API.
Certificates TLS internos, kubeconfig, secrets do cluster — tudo tem validade e precisa de rotação. Um etcd corrompido pode derrubar o cluster inteiro.
A rede do Kubernetes (CNI plugins como Calico, Flannel, Cilium) adiciona uma camada de troubleshooting que não existe no Docker simples. Quando uma aplicação não consegue se comunicar com outra, a investigação pode envolver política de rede, DNS interno, ServiceAccount, e outros componentes.
Monitoramento de um cluster K8s bem feito exige Prometheus, Grafana, Loki para logs, e Alertmanager. São serviços que consomem recursos do próprio cluster e precisam de manutenção.
Nenhum desses pontos é intransponível. Mas o custo de engenharia é real, e startups com time pequeno pagam esse custo em tempo que poderia estar em produto.
Perguntas Frequentes
Kubernetes é obrigatório para ser "sério em infra"?
Não. Seriedade em infra é sobre uptime, segurança, backup, observabilidade e capacidade de responder a incidentes — não sobre qual orquestrador você usa. Uma operação com Docker Compose bem configurado, healthchecks, Traefik para TLS, Restic para backup e alertas no Grafana é mais séria do que um cluster K8s mal gerenciado sem monitoramento.
Docker Swarm ainda é opção?
Docker Swarm foi oficialmente descontinuado como produto prioritário pela Docker. Para multi-nó, K3s é a alternativa mais segura hoje: tem suporte ativo, é Kubernetes certificado e aceita o mesmo ecossistema de ferramentas.
K3s suporta o mesmo que K8s gerenciado?
K3s implementa a API do Kubernetes e é certificado pela CNCF, então ferramentas como Helm, Argo CD, Prometheus Operator e Cert-manager funcionam sem modificação. A principal diferença é que o control plane roda em um dos seus próprios nodes, então você é responsável por ele. Para a maioria das startups que saem do Compose, K3s é suficiente por bastante tempo.
Quando migrar para K8s gerenciado (EKS/GKE/AKS)?
Quando o custo de operar o control plane do K3s se torna um problema real — seja porque o time cresceu e o cluster virou gargalo, ou porque vocês precisam de SLA de control plane que só o provedor pode dar. Em geral, essa transição faz sentido quando você já tem engenheiro(s) dedicados a infra e o produto já gerou receita suficiente para absorver o custo.
Posso usar Kubernetes para rodar IA self-hosted?
Sim, e há casos em que faz sentido — especialmente se você já tem um cluster e quer adicionar Ollama ou vLLM como mais um serviço. Mas para começar com IA self-hosted, uma VM dedicada com Docker Compose é mais simples e mais rápida de operar. Veja mais em IA self-hosted vs nuvem: quando vale rodar no seu servidor.
Conclusão
Kubernetes é uma ferramenta extraordinária para os problemas que ele resolve. O erro não é adotá-lo — é adotá-lo antes de ter os problemas que ele resolve.
Para a maioria das startups em fase de crescimento, a progressão natural é: Docker Compose em um servidor bem configurado, depois K3s quando o multi-nó se torna necessário, depois K8s gerenciado quando múltiplos times e escala real exigem a orquestração completa.
Pular etapas antecipando escala é uma das formas mais eficientes de consumir tempo de engenharia sem entregar valor para o produto.
Avaliar onde a sua operação está nessa progressão — e escolher a ferramenta certa para o estágio atual, não para uma escala hipotética — é o tipo de decisão que o departamento de DevOps da MaxVision toma junto com o cliente, desde Docker Compose até K3s e K8s gerenciado. Se o seu cenário ainda não está claro, esse é o ponto de partida.
