Kubernetes Gerenciado no Brasil: Quando Faz Sentido pra Empresa B2B (2026)

Kubernetes virou palavra da moda, mas continua sendo overkill pra maioria dos casos. A pergunta certa não é "Kubernetes ou não?" — é "quais sinais reais do meu produto pedem Kubernetes?". Este guia mostra como decidir pra empresa B2B brasileira em 2026.

O que Kubernetes gerenciado resolve — e o que não resolve

Kubernetes é um orquestrador de containers. Ele decide onde e como rodar seus contêineres, faz balanceamento, reinicia o que caiu, sobe réplicas quando o tráfego aumenta. Managed Kubernetes tira do seu time o trabalho de manter o control plane (etcd em cluster HA, upgrades do api-server, tuning do scheduler, backup do banco de config).

O que Kubernetes resolve bem:

• Deploy sem downtime: rolling update nativo, blue-green, canary por Ingress
• Escala automática: HPA por CPU/memória ou métrica custom (fila, latência)
• Auto-healing: pod caiu, scheduler sobe outro sozinho
• Isolamento multi-tenant: namespaces com RBAC, network policies, resource quotas
• Padrão declarativo: infra descrita em YAML versionado em Git, reproduzível

O que Kubernetes NÃO resolve — e cria trabalho:

• Não faz seu app ser mais rápido. Se código está lento, K8s só sobe mais pods lentos
• Não resolve banco de dados stateful (Postgres, MySQL) sem operator dedicado — e operator próprio dá trabalho
• Não substitui monitoramento (Prometheus/Grafana), log centralizado (Loki/ELK), CI/CD (ArgoCD, Flux) — tudo isso vira ecossistema extra
• Não elimina complexidade de rede — Service Mesh (Istio, Linkerd) só é preciso se você já sofre com ela

4 sinais reais que a sua empresa precisa de Kubernetes

Antes de contratar K8s gerenciado, veja quantos desses 4 sinais você tem hoje:

Sinal 1: 4 ou mais serviços com escalonamento independente

Se sua aplicação é um monolito único (Rails, Django, Laravel, .NET) que escala tudo junto, K8s não agrega muito. Docker Compose numa VM cuida bem.

Agora, se você tem: API pública, worker de processamento, agendador cron, webhook receiver, gRPC interno — cada um consumindo CPU/RAM diferente em horário diferente — orquestrador começa a fazer sentido.

Sinal 2: Deploy várias vezes por semana sem downtime aceitável

Se seu produto é interno (ERP, sistema administrativo), deploy noturno com 15 min de janela é aceitável. Docker Compose com docker-compose up -d resolve.

Se você tem SaaS multi-cliente que gera receita 24/7 e precisa deployar 5-10 vezes por semana sem cair conexão de nenhum cliente, K8s rolling update vira exigência prática.

Sinal 3: Multi-tenant/multi-cliente com isolamento forte

Se cada cliente do seu SaaS precisa banco isolado, quota de CPU/RAM isolada, network policy que impede um ver o outro, K8s namespace + RBAC + network policy resolve nativo. Fora dele, você reinventa o mecanismo em nginx + iptables + orquestração caseira.

Sinal 4: Equipe com pelo menos 1 pessoa que já rodou K8s em produção

Este é o sinal mais subestimado. K8s tem curva de aprendizado real: YAML, RBAC, storage classes, ingress, service mesh, observabilidade, upgrade de versão. Se ninguém na equipe já sofreu com K8s em produção, você vai gastar 3-6 meses aprendendo — e nesse tempo, sua concorrência entrega feature.

Regra prática: se você marca 3+ dos 4 sinais, Kubernetes faz sentido. Se marca 2 ou menos, provavelmente vai gastar mais tempo com K8s do que ganha em benefício. Docker Compose ou VM dedicada segue bem.

Managed Kubernetes vs self-hosted vs Docker Swarm

Se você decidiu que precisa de orquestração, aí sim vale comparar opções.

Docker Compose em VM

Quando: monolito ou 2-3 serviços, deploy noturno OK, 1 dev cuidando. Custo operacional: mínimo. Escala: vertical (VM maior) ou script custom pra rodar em 2 VMs. Perfeitamente aceitável até uns 50 requests/segundo consistentes.

Docker Swarm

Modo "K8s light". Orquestra vários nodes com sintaxe compose. Quando: tem 4-8 serviços, precisa HA básica, não quer complexidade K8s. Limite: ecosystem morreu — features novas param, integrações com CI/CD e observability são fracas. Recomendável só se equipe já domina.

Kubernetes self-hosted

Você instala K8s do zero (kubeadm, RKE, Rancher) em VMs próprias. Tem controle total do control plane, banco etcd, versão exata. Custo operacional: alto — precisa cuidar de etcd HA, upgrade de control plane, backup de etcd, tuning de kubelet. Um engineer full-time só pra isso quando cluster passa de 10 nodes.

Managed Kubernetes (GKE, EKS, AKS, Audaks K8s Gerenciado)

Provedor cuida do control plane, você usa só worker nodes. Vantagem: upgrade sem stress, HA garantido por SLA, integração pronta com storage e load balancer. Custo real: vale a pena a partir de 3 worker nodes, porque tempo de engenharia poupado paga a diferença.

Comparativo pratico:

Opção	Setup	Operação	Escala	Recomendado pra
Docker Compose	1 hora	Baixa	Vertical / 2 VMs	1-3 serviços, dev único
Docker Swarm	4 horas	Média	Horizontal simples	4-8 serviços, equipe pequena
K8s self-hosted	2-4 semanas	Alta	Ilimitada	Equipe experiente, controle total
K8s gerenciado	30 minutos	Média-baixa	Ilimitada	4+ serviços, deploy frequente

Por que empresa BR escolhe Kubernetes gerenciado nacional vs EKS/GKE

Se você já decidiu por K8s gerenciado, a próxima escolha é: provedor internacional (EKS/GKE/AKS) ou nacional?

Razões práticas pra escolher provedor BR em 2026:

• Sem IOF 6,38%: pagamento em Real dedutível como despesa operacional. Em cloud gringa vira lançamento cambial variável
• Latência real dentro do BR: cluster em SP responde <30ms pra usuário Sudeste/Sul. EKS us-east-1 tem 120ms+
• LGPD direta: dados sob ANPD, sem cláusula de transferência internacional
• Sem cobrança de egress interno: tráfego pod-a-pod ou pra Object Storage BR não gera fatura surpresa
• Suporte em português por engineer: chamado em português com engineer que já operou K8s em produção BR, não script decorado
• Compliance setorial: contrato compatível com Bacen (fintech), CFM (saúde), TJSP

Onde EKS/GKE ainda ganham: features cutting-edge (Vertex AI, integrações profundas com serviços gringos), operação global multi-região automática. Se você tem cliente na Europa e Ásia, cloud internacional continua fazendo sentido.

SLA e observabilidade — o que exigir do provedor BR

Contrato de K8s gerenciado BR sério inclui:

• SLA control plane ≥ 99,9% — provedor responde pelo uptime do api-server
• Upgrade de versão com janela agendada — versões N-2 suportadas, notificação com 30 dias
• Backup automatizado de etcd — snapshot recorrente com retenção configurável
• Persistent Volume com CSI driver nacional — armazenamento em datacenter BR, sem ida-e-volta pra AWS
• Ingress Controller pronto — Nginx ou HAProxy configurado, TLS via cert-manager automatizado
• Métricas expostas em Prometheus — você conecta seu Grafana ou usa Grafana gerenciado

Sem essas garantias, "K8s gerenciado" vira K8s que você continua operando — só mudou a fatura.

Custos reais: comparar TCO antes de assinar

Não olhe só preço por worker node. TCO real de K8s tem 4 componentes:

1. Worker nodes: VMs onde seus pods rodam. Você paga por CPU/RAM. Reserve 20-30% do node pra system pods (kubelet, kube-proxy, CNI, log-shipper)
2. Control plane: em managed geralmente incluso ou taxa fixa mensal
3. Storage persistente: PV baseado em block storage — cobrança por GB provisionado ao mês
4. Load balancer + tráfego: LB do ingress + egress. Em provedor BR sério, egress interno é gratuito (só cobra saída pra internet)

Regra: se seu cluster tem 3 worker nodes de 4vCPU/8GB rodando 24/7, TCO típico de managed BR fica na faixa de 30-50% mais barato que EKS us-east-1 quando incluído câmbio, IOF, egress e tempo de engenharia.

Migração de VM/Docker Compose pra K8s: roteiro real

Se você decidiu migrar pra K8s, este é o passo-a-passo pragmático:

1. Semana 1 — Containerize: garantir que cada serviço tem Dockerfile funcionando, healthcheck configurado, config via env var
2. Semana 2 — Registry: subir imagens em registry (Harbor self-hosted, GitLab Container Registry ou registry gerenciado do provedor). CI publica em cada push
3. Semana 3 — Cluster piloto: cluster gerenciado com 2 worker nodes, deploy 1 serviço não crítico (worker de fila, cron job)
4. Semana 4 — Ingress + TLS: nginx ingress, cert-manager pra Let's Encrypt, DNS apontando pra LB
5. Semana 5-6 — Storage e stateful: PV pra volumes stateless (uploads, cache), estratégia pra bancos (usar DBaaS externo ao cluster geralmente é mais seguro que rodar Postgres/MySQL dentro)
6. Semana 7-8 — Observability: Prometheus + Grafana + Loki, alertas críticos ligados a Slack ou PagerDuty
7. Semana 9+ — Migração progressiva: um serviço por semana, monitorando 7 dias antes de desligar VM antiga

Tempo total realista: 2-3 meses pra empresa com 5-10 serviços. Menos que isso é otimismo; mais que isso, cluster nasce complicado demais.

FAQ Kubernetes gerenciado B2B Brasil

Kubernetes gerenciado no Brasil é caro?

Depende do provedor e do tamanho do cluster. Provedor nacional geralmente cobra menos que EKS/GKE quando comparado em Reais, pois não tem câmbio, IOF nem cobrança agressiva de egress. Para cluster pequeno (3 worker nodes), a diferença chega a 30-50% no total anual.

Vale rodar banco de dados dentro do cluster K8s?

Geralmente não. Postgres/MySQL stateful em K8s exige operator maduro (Zalando, CrunchyData, Percona), backup dedicado, PV com IOPS garantido. Recomendação prática: use DBaaS gerenciado ao lado do cluster, cluster K8s cuida só do stateless.

Preciso de service mesh (Istio/Linkerd) desde o dia 1?

Não. Service mesh adiciona complexidade grande (mais 1-2 pods por node, latência extra em cada request). Só vale quando você já sofre com: mTLS entre microserviços, traffic splitting fino, retry/circuit breaker complexo. Sem esses problemas concretos, mesh vira peso morto.

Como escolher tamanho de worker node?

Regra: um worker node deve caber 5-15 pods do seu app típico. Nodes muito pequenos (1vCPU/2GB) desperdiçam CPU em overhead do kubelet. Nodes muito grandes (16vCPU/64GB) concentram risco (se um cai, muitos pods vão junto). Sweet spot típico: 4vCPU/8GB ou 8vCPU/16GB.

Vale expor cluster K8s direto na internet?

Só o Ingress deve estar público. API server (kubectl) fica atrás de VPN ou IP-list restrita. Pods internos não recebem tráfego direto — só via Service/Ingress. Além disso: RBAC habilitado do dia 1, network policies isolando namespaces por padrão, secrets criptografados em rest (usar SealedSecrets ou provedor de KMS).

Suporte em português cobre Kubernetes de verdade?

Provedor sério tem engineer que já operou K8s em produção — não script decorado. Chamado em português, resposta técnica em português, RCA (root cause analysis) formal quando incidente. Antes de assinar, teste: abra chamado técnico ("como escalar Ingress Nginx pra suportar 10k RPS?"). Resposta em minutos por engineer real = provedor sério.

Como migrar de EKS/GKE pra provedor nacional?

Manifestos K8s são portáveis. O que muda: (1) storage class (ajusta CSI driver); (2) LoadBalancer service (ajusta annotations); (3) IAM/IRSA vira RBAC nativo; (4) integrações com serviços gringos (S3, RDS) vão pro equivalente nacional (Object Storage BR, DBaaS BR). Migração assistida por engineer BR geralmente leva 2-4 semanas pra cluster médio.

Próximos passos

• Kubernetes vs Docker Swarm vs Nomad: qual escolher em 2026
• Microsserviços no Brasil: quando vale (e quando destrói TCO)
• Kubernetes Gerenciado Audaks — control plane cuidado, worker nodes em datacenter Tier III BR
• DBaaS gerenciado — Postgres/MySQL fora do cluster K8s