Multilocação no Kubernetes

Multi-Tenant é um estilo de arquitetura onde você tem uma aplicação centralizada que atende a vários clientes.

Em Cloud Computing, multilocação também se refere à hospedagem compartilhada, em que os recursos do servidor são divididos entre clientes diferentes.

Neste estilo, geralmente queremos isolar um usuário ou aplicativo de outros usuários ou aplicativos em uma infraestrutura compartilhada.

O Kubernetes é um orquestrador de locatário único , ou seja, uma única instância do plano de controle é compartilhada entre todos os locatários de um cluster. Mas ai vem o pulo do gato... existem diversos objetos do k8s que você pode criar uma "aparência" de multilocação que permite implementar o isolamento de locatário enquanto mitiga os riscos de usar um orquestrador de locatário único.

Duas abordagens podem ser implementadas: Soft Multi-Tenant e Hard Multi-Tenant (tipo single-tenant).

Para o Soft-Multi-Tenant você aproveita dos objetos nativos do Kubernetes, por exemplo, namespace, RBAC e politicas de redes para criar uma separação lógica entre os inquilinos.

Vale ressaltar, que os controles acima não impedem que os Pods de diferentes locatários compartilhem um nó. Para isso faz-se necessário um isolamento mais forte, por exemplo, NodeSelector, Anti-Affinity Rules, Taints e Tolerations.

Usando os componentes nativos do Kubernetes, os seguintes objetos podem ser usados para o isolamento de inquilinos:

Namespace: fundamental para implementar a multilocação flexível. Com ele, iremos definir cotas, políticas de rede, contas de serviço etc.

Politicas de Redes: por padrão, todos os pods no k8s podem se comunicar entre si. Esse comportamento pode ser alterado com políticas de redes. A aplicação de políticas de rede requer um mecanismo de politica como Calico ou Cilium.

RBAC: usado para permitir uma administração de objetos do k8s por grupos ou indivíduos selecionados.

Cotas: usadas para definir limites nas cargas de trabalho hospedadas no cluster. Podendo especificar a quantidade máxima de CPU e memória que um Pod pode consumir em um cluster ou namespace. Ter esse acesso ilimitado aos recursos do cluster pode causar escassez, o que levará à degradação do desempenho e à perda de disponibilidade do aplicativo. Para evitar que isso ocorra, deve-se planejar a imposição de cotas em namespaces no ambiente multilocatário

Pod priority e Pre-emption: útil quando você deseja fornecer diferentes qualidades de serviços para diferentes clientes. Com ele, você pode configurar prioridades no Pod para um determinado cliente e quando houver capacidade insuficiente disponível, o kubelet removerá os Pods de menor prioridade para acomodar os de maior prioridade. 

Na abordagem Hard Multi-Tenant a ideia é implementar o provisionamento de diferentes cluster para cada inquilino o que se tornará caro rapidamente, já que poderá pagar os custos de cada plano de controle para cada cluster e não poderá compartilhar os recursos entre eles. Levando, também, a subutilização de clusters ou super utilização de outros.

Até mesmo a necessidade do uso de ferramentas especiais para o gerenciamento desses diversos cluster. E mesmo usando ferramentas como Terraform e CDK para o provisionamento desses cluster, essa abordagem é mais lenta que a criação de um simples namespace.

Por fim, a comunidade do Kubernetes reconhece que as abordagens atuais para multilocação possuem seus desafios. Esse tema vem sendo abordado na Multi-Tenancy Special Interest Group (SIG) por meio de alguns projetos, que incluem Hierarchical Namespace Controller e Virtual Cluster.

Vale acompanhar esse SIG e ficar por dentro do que vem sendo discutido para as próximas versões.