Multi-Tenancy no Kubernetes: modelos, camadas de isolamento e boas práticas

TL;DR

• Multi-tenancy no Kubernetes significa rodar várias equipes, projetos ou clientes em um único cluster compartilhado, em vez de um cluster dedicado para cada um — e nada do isolamento acontece automaticamente.
• Quatro camadas principais sustentam tudo: namespaces, RBAC, network policy e resource quotas (incluindo LimitRanges), além dos Pod Security Standards protegendo o nível dos workloads. Pule uma delas e um tenant que deveria ficar isolado começa a afetar todos os outros.
• Existem três modelos de isolamento: soft (baseado em namespaces, o mais barato, isolamento apenas lógico), hard (clusters virtuais como vCluster ou Capsule) e físico (node pools ou clusters dedicados, isolamento mais forte, custo mais alto). A maioria das organizações combina os três em vez de padronizar em um só.
• A maioria das falhas vem de drift, não de uma configuração inicial ruim: as equipes configuram quotas e RBAC corretamente uma vez e nunca mais revisitam conforme os workloads mudam.

Coloque dez equipes em um único cluster Kubernetes e, por padrão, nada impede a equipe A de ler os secrets da equipe B, consumir a CPU da equipe B ou derrubar um control plane do qual a equipe B também depende. O multi-tenancy no Kubernetes fecha essa lacuna com quatro camadas configuráveis: namespaces, RBAC, network policy e resource quotas.

O multi-tenancy permite que as organizações parem de pagar por dezenas de control planes ociosos e passem a compartilhar infraestrutura entre equipes, projetos ou clientes ("tenants"). Mas isso só funciona se cada uma dessas camadas for de fato configurada — e continuar configurada. O Kubernetes não vem multi-tenant de fábrica. Namespaces traçam uma fronteira lógica, não de segurança. Pule uma camada e um tenant que deveria ficar isolado começa a afetar todos os outros no cluster, seja rompendo uma fronteira de segurança ou simplesmente com um workload consumindo a CPU de outro.

Por que as equipes compartilham um cluster, afinal

Três motivos aparecem em quase todos os casos: custo, carga operacional e velocidade dos desenvolvedores.

Rodar dez clusters significa dez control planes, dez conjuntos de node pools superprovisionados, dez load balancers ociosos a maior parte do dia. Consolidar em dois ou três clusters compartilhados corta esse overhead diretamente. Também reduz a carga operacional: um cluster para aplicar patches, um lugar para monitorar a saúde do etcd, um conjunto de políticas para manter consistente, em vez do mesmo trabalho repetido em cada cluster que você opera.

A velocidade dos desenvolvedores é igualmente importante, embora chame menos atenção. Equipes que dependem de um time de plataforma para provisionar um novo cluster esperam dias. Equipes que solicitam um namespace em um cluster multi-tenant existente conseguem um em minutos, em modelo self-service, já com quotas e network policy anexadas. Times de plataforma chamam isso de "namespace-as-a-service", e muitas vezes é justamente isso que motiva a construção do multi-tenancy.

Os três modelos de multi-tenancy

Nem todo tenant precisa do mesmo isolamento. O modelo que você escolhe equilibra raio de impacto contra custo e a complexidade operacional que você decide assumir.

A maioria das organizações não escolhe um modelo e para por aí. Elas rodam soft multi-tenancy para equipes internas confiáveis e reservam o isolamento hard ou físico para o punhado de tenants (um cliente externo, um time de ML pesado em GPU, um workload regulado) que realmente precisa dele. Tratar o "multi-tenancy" como um único botão liga/desliga superdimensiona ou subdimensiona muitos desses projetos desde o início.

As camadas de isolamento que sustentam o soft multi-tenancy

A maioria das equipes começa com soft multi-tenancy por padrão. Quatro camadas o constroem, e você precisa configurar cada uma delas; nenhuma vem ativada de fábrica.

Namespaces dão a fronteira à qual todo o resto se conecta: um lugar para delimitar RBAC, quotas e network policy. Sozinhos, eles isolam nomes, não comportamento. Um pod no namespace A ainda pode falar com um pod no namespace B, e um workload sem limites de recursos ainda pode consumir um nó que os pods do namespace B também usam.

RBAC decide quem pode agir sobre o quê. Comece negando tudo por padrão, conceda apenas as roles mínimas que o time de cada tenant realmente precisa e vincule a grupos em vez de usuários individuais, para que o acesso não se degrade conforme pessoas entram e saem das equipes. O sprawl de RBAC por tenant (dezenas de Roles e RoleBindings quase duplicados saindo de sincronia) está entre os principais motivos de clusters multi-tenant ficarem cada vez mais difíceis de auditar com o tempo.

NetworkPolicy impede que tenants se alcancem pela rede, algo que RBAC e namespaces sozinhos não fazem:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-cross-namespace
  namespace: team-a
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: team-a

A maioria das equipes começa com uma política default-deny por namespace e depois adiciona regras de allow explícitas para o que realmente precisa se comunicar entre namespaces. Sem isso, qualquer pod do cluster pode alcançar qualquer outro pod por padrão. Namespaces não impõem fronteiras de rede por conta própria.

ResourceQuotas e LimitRanges impedem que um único tenant sufoque o resto do cluster em CPU, memória ou contagem de objetos. Uma ResourceQuota limita o que um namespace pode consumir no total; um LimitRange define padrões e máximos sensatos por contêiner dentro dele. Multi-tenancy e o problema do noisy neighbor se cruzam exatamente aqui: uma quota só protege o cluster quando as equipes definem corretamente os requests e limits por trás dela, próximos ao uso real. Quotas frouxas demais não param noisy neighbors; quotas apertadas demais só empurram as equipes a inflar requests e desperdiçar a economia de consolidação que o multi-tenancy prometia.

Pod Security Standards completam o quadro no nível dos workloads, restringindo contêineres privilegiados, host networking e acesso root por namespace, de modo que um invasor que comprometa um pod de um tenant não consiga escalar para o nó ou para o resto do cluster.