Kubernetes pra SaaS Multi-Tenant: Isolar Clientes Sem Multiplicar Custo (2026)

Software house brasileira que vende sistema white-label conhece o dilema: o cliente grande exige isolamento ("meus dados não podem estar junto dos outros"), mas subir um servidor por cliente detona a margem. Kubernetes resolve exatamente esse meio-termo — e é por isso que virou padrão pra SaaS B2B. Este guia mostra os 3 modelos com a conta de cada um.

Modelo 1 — Pool compartilhado (soft multi-tenancy)

Uma única instalação da aplicação serve todos os clientes. O isolamento acontece na camada de dados: coluna tenant_id, schema por cliente ou banco por cliente.

• Custo: o menor possível — recursos 100% compartilhados
• Quando usar: centenas/milhares de clientes pequenos, ticket baixo por cliente, produto padronizado
• Risco: bug de código pode vazar dado entre tenants; cliente pesado degrada os demais (noisy neighbor)
• No K8s: deployment único com HPA, banco fora do cluster em DBaaS com schema por tenant

Modelo 2 — Namespace por cliente (o sweet spot B2B)

Cada cliente recebe um namespace com seu próprio deployment, configuração e limites. É aqui que os recursos nativos do Kubernetes trabalham a seu favor:

• ResourceQuota por namespace: cliente do plano básico recebe 2 vCPU/4 GB de teto; enterprise recebe 8/16. Ninguém rouba recurso de ninguém — o noisy neighbor morre aqui
• NetworkPolicy (Calico): pods do cliente A não enxergam os do cliente B na rede. Isolamento de tráfego real, não só lógico
• RBAC por namespace: se o cliente exige auditoria, você concede acesso read-only só ao namespace dele
• Config por cliente via Helm: o mesmo chart com values diferentes — versão, feature flags e domínio próprios por tenant. Cliente conservador fica na v2.3 enquanto os demais vão pra v2.4
• Upgrade canário por tenant: atualiza 3 clientes beta na sexta, o resto na terça

A conta que interessa: em VMs separadas, 30 clientes = 30 VPS com sistema operacional, agente de monitoramento e folga de recurso cada — desperdício de 40-60% somado. Num cluster K8s, os mesmos 30 clientes compartilham nodes com empacotamento denso: a folga é do cluster, não de cada cliente. Na prática, 30 tenants médios cabem em 4-6 worker nodes bem dimensionados.

Modelo 3 — Cluster por cliente (hard multi-tenancy)

• Quando é obrigatório: contrato enterprise com exigência formal de infraestrutura dedicada, requisito regulatório de segregação física, ou cliente disposto a pagar por isso
• Custo: cada cluster tem seu control plane e nodes — só fecha a conta se o contrato individual paga
• Dica prática: ofereça como tier premium. "Ambiente dedicado" vira linha de receita, não custo

Arquitetura de referência pra software house BR

O desenho que recomendamos pra software house com 10-50 clientes B2B:

1. Cluster K8s gerenciado com 3-6 worker nodes — control plane, ingress, Calico e volumes NVMe já operados pela Audaks
2. Namespace por cliente com ResourceQuota e NetworkPolicy padrão aplicados via template
3. Ingress compartilhado roteando cliente1.seusistema.com.br → namespace cliente1, com TLS automatizado
4. Banco FORA do cluster: DBaaS PostgreSQL com database por tenant — banco stateful dentro de cluster multi-tenant é risco que não compensa
5. Arquivos em Object Storage S3 com bucket ou prefixo por tenant
6. Backup e monitoramento da infraestrutura inclusos no gerenciado; métricas de aplicação por namespace no seu stack (Prometheus + Grafana)

Erros que vemos em produção

1. Multi-tenant sem ResourceQuota: um cliente roda relatório pesado segunda 9h e derruba os outros 29. Quota não é opcional
2. Sem NetworkPolicy: K8s por padrão deixa todo pod falar com todo pod. Num vazamento, o atacante navega entre tenants. Calico com deny-by-default resolve
3. Banco dentro do cluster multi-tenant: Postgres num pod dividindo node com aplicação de 30 clientes = IOPS imprevisível e restore complicado. DBaaS externo é mais simples e mais seguro
4. Um único Ingress sem rate limit por tenant: cliente com integração mal feita (retry infinito) esgota o ingress de todos
5. Secrets compartilhados: cada namespace com seus secrets. Chave de API do cliente A não pode existir no namespace do B

FAQ

Namespace isola de verdade ou é só organizacional?

Namespace sozinho é organizacional. Namespace + ResourceQuota + NetworkPolicy + RBAC é isolamento operacional real — recurso, rede e acesso segregados. O que ele não é: isolamento de kernel (pra isso, cluster dedicado). Pra 95% dos contratos B2B, o modelo namespace bem configurado atende inclusive auditoria.

Como cobrar cliente por consumo?

ResourceQuota define o teto por namespace e vira a base do seu plano comercial: básico 2vCPU/4GB, pro 4/8, enterprise 8/16. Métricas por namespace mostram uso real — dá pra oferecer upgrade quando o cliente bate no teto com frequência.

Quantos tenants cabem num cluster?

Regra prática: some os requests de todos os tenants + 30% de folga e divida pela capacidade dos nodes. 30 tenants leves (0,5 vCPU/1 GB médios) cabem confortáveis em 4 nodes de 8 vCPU/16 GB. O limite arquitetural do K8s (centenas de namespaces) está longe de ser o gargalo — o gargalo é dimensionamento honesto.

E quando um cliente exige os dados no ambiente dele?

Tier dedicado: cluster próprio ou VPC isolada pra esse cliente, cobrado como premium. O resto da base continua no cluster compartilhado. Os dois modelos convivem — mesmo chart Helm, values diferentes.

Próximos passos

• Kubernetes gerenciado: quando faz sentido pra B2B
• Postgres em K8s: operator vs DBaaS
• Programa Software House Audaks — cloud white-label pra revenda
• Kubernetes Gerenciado Audaks