Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Ao responder à pergunta "Como devo configurar o Kubernetes para multitenência?", os arquitetos devem primeiro compreender os limites conceptuais e os modelos de isolamento disponíveis. A multitenancy no AKS é a prática de executar várias cargas de trabalho isoladas, pertencentes a diferentes equipas, aplicações ou clientes, num cluster Kubernetes partilhado. Este artigo descreve em detalhe os conceitos fundamentais e os modelos de arquitetura da multitenancy no Azure Kubernetes Service (AKS).
Sugestão
Quais são os três modelos de multitenência no AKS? A multilocação no AKS utiliza um espectro de isolamento com três modelos comuns: isolamento por espaço de nomes, isolamento por conjunto de nós e um cluster por inquilino. O isolamento de namespace é mais adequado para equipas internas de confiança e para a máxima eficiência em termos de custos, o isolamento de grupos de nós proporciona uma separação mais forte das cargas de trabalho com sobrecarga moderada, e um cluster por inquilino proporciona o isolamento mais forte para cenários com inquilinos não fiáveis ou altamente regulados.
Para obter instruções de implementação passo a passo e manifestos YAML, consulte o guia complementar: Melhores práticas para multitenancy no AKS.
Porquê multi-inquilinação no AKS?
A arquitetura multiarrendatário permite que múltiplas equipas, aplicações ou clientes partilhem um único cluster do Kubernetes. A principal justificação para a multitenancy no AKS é a eficiência em termos de custos e a escala operacional.
Executar um cluster dedicado para cada aplicação ou equipa resulta numa fragmentação significativa de recursos, capacidade de computação ociosa e sobrecarga multiplicada do plano de controlo. Ao consolidar cargas de trabalho em clusters multi-inquilino, as organizações maximizam a utilização de recursos e reduzem o gasto na cloud. Operacionalmente, a utilização de uma arquitetura multi-tenant reduz a dimensão da frota, o que significa que as equipas de plataforma têm menos clusters para corrigir, atualizar, monitorizar e proteger, simplificando, assim, a gestão do ciclo de vida.
Qual é a diferença entre multitenência flexível e rígida?
O Kubernetes não é, por si só, um sistema multi-inquilino. Para alcançar a multilocação, deve conceber um modelo de isolamento "leve" ou "rigoroso", com base no nível de confiança entre os locatários.
A diferença entre multi-tenancy soft e hard no Kubernetes reside principalmente no modelo de confiança e nos consequentes requisitos de isolamento. A multi-inquilinação suave assume inquilinos internos confiáveis e foca-se em prevenir interferências acidentais através de controlos lógicos como namespaces, RBAC e quotas. A multitenência estrita pressupõe um nível baixo ou nulo de confiança entre os locatários e requer controlos de isolamento mais robustos para reduzir o risco de acesso malicioso, movimento lateral e exposição de dados.
| Modelo | Nível de confiança | Goal | Caso de utilização | Cenários de exemplo |
|---|---|---|---|---|
| Multi-tenancy flexível | Elevada confiança entre inquilinos internos | Prevenir interferências acidentais, falta de recursos e colisões de configuração | Ambientes internos de plataforma onde as equipas partilham infraestrutura | Várias equipas de produto numa só organização a partilhar um cluster AKS para dev/test e serviços internos |
| Multi-arrendamento rígido | Baixa ou nula confiança entre inquilinos | Prevenir ataques maliciosos, movimentos laterais e exfiltração de dados | Alojamento externo de clientes e cargas de trabalho reguladas | Fornecedor de SaaS que aloja cargas de trabalho específicas do cliente, em que o isolamento do locatário é um requisito de segurança e conformidade |
O espectro de isolamento
Multitenência no AKS não é uma escolha binária; Existe num espectro. À medida que se avança através do espectro, o isolamento aumenta, mas também a complexidade operacional e o custo. Este espectro serve de estrutura organizadora para a conceção de clusters multicliente:
- Isolamento por namespaces (lógico): Os locatários partilham os mesmos grupos de nós e plano de controlo, mas são separados logicamente por namespaces do Kubernetes. Esta é a base da multi-locação flexível.
- Isolamento do conjunto de nós (Computação física): Os locatários partilham o plano de controlo, mas são-lhes atribuídos nós de trabalho dedicados. Isto melhora a separação das cargas de trabalho e a mitigação de vizinhos ruidosos, mas não constitui um isolamento completo entre tenants, uma vez que os componentes ao nível do plano de controlo e do cluster continuam a ser partilhados.
- Cluster por locatário (Totalmente físico): Os locatários estão completamente isolados com o seu próprio plano de controlo do AKS e o plano de dados. Esta é a forma mais extrema de multi-inquilino estrito, contornando efetivamente a partilha a nível do Kubernetes em favor do isolamento a nível do Azure.
Primitivas do AKS para multicliente
O AKS fornece um conjunto de primitivas nativas e integradas no Azure para impor o espectro de isolamento.
- Microsoft Entra ID: Fornece gestão centralizada de identidade e acessos para autenticação de utilizadores e sistemas automatizados na API Kubernetes.
- Azure RBAC: Mapeia as identidades do Microsoft Entra ID para permissões do Kubernetes, garantindo que os inquilinos só possam aceder aos seus recursos autorizados.
- Espaços de nomes geridos: Fornece limites lógicos dentro do cluster para agrupar os recursos do inquilino, aplicar quotas e definir o acesso.
- Azure Policy / Gatekeeper: Aplica regras centralizadas de conformidade e governação em todo o cluster para evitar que os inquilinos implementem configurações inseguras ou não autorizadas.
- Azure CNI: Fornece integração nativa de rede virtual para redes AKS e suporta segmentação de tráfego de inquilinos com controlos de políticas de rede. O comportamento do endereço IP do pod depende do modo CNI selecionado (por exemplo, Overlay ou Sub-rede do pod).
- Azure Container Networking Services (ACNS) Cilium L7: Fornece políticas de rede de alto desempenho baseadas em eBPF e filtragem de tráfego de Camada 7 para isolar estritamente o tráfego de rede dos inquilinos.
- Identidade da carga de trabalho: Permite que pods individuais se autentiquem de forma segura em serviços externos do Azure usando identidade federada, eliminando segredos partilhados entre inquilinos.
Mapear camadas de isolamento entre planos
Para construir uma arquitetura segura com múltiplos inquilinos, tem de aplicar as primitivas do AKS ao longo de três planos distintos do ambiente do cluster.
| Avião | Description | Primitivas aplicadas do AKS |
|---|---|---|
| Plano de controlo | Garantir o acesso ao servidor API Kubernetes e aos limites lógicos. | Microsoft Entra ID, Azure RBAC, Espaços de nomes geridos |
| Plano de dados | Proteção do tráfego de rede, execução computacional e fronteiras ao nível do nó. | Azure CNI, ACNS Cilium L7, conjuntos de nós |
| Plano de recursos | Regula o consumo de computação, acesso externo e conformidade de configuração. | Azure Policy, identidade da carga de trabalho |
Que modelo de isolamento deve escolher?
Use a seguinte matriz para determinar qual ponto no espectro de isolamento melhor se adequa às suas necessidades organizacionais.
| Modelo de isolamento | Nível de segurança | Eficiência de custos | Complexidade operacional | Mais adequado para |
|---|---|---|---|---|
| Namespace-per-tenant | Baixo a Médio (Lógico) | Alta (Partilha máxima) | Baixo (Um único cluster para gerir) | Equipas internas, ambientes de desenvolvimento e teste, multitenência flexível. |
| Node-pool-per-tenant | Alto (computação isolada) | Médio (Plano de controlo partilhado) | Médio (Gestão de contaminações/tolerâncias) | Cargas de trabalho internas e externas que necessitam de uma separação computacional mais forte enquanto partilham um plano de controlo; Não é ideal para arrendatários hostis de zero-trust. |
| Cluster-per-tenant | Mais alto (Físico) | Baixo (Custos elevados) | Alta (Gestão de frota necessária) | Multilocação hostil, clientes empresariais externos, confiança zero. |
Quando usar cada modelo
- Utilize namespace-per-tenant quando os locatários forem internos ou fiáveis, a eficiência de custos for uma prioridade e os controlos de isolamento lógico forem suficientes.
- Usa node-pool-per-tenant quando precisares de maior separação de computação e redução do impacto ruidoso nos vizinhos, partilhando ainda um plano de controlo AKS.
- Utilize cluster-per-tenant quando os locatários não forem de confiança, os limites regulamentares forem rigorosos ou o seu modelo de risco exigir um mínimo de infraestrutura partilhada.
Passos seguintes
Agora que compreende os modelos conceptuais e primitivas para multitenância, consulte o guia de implementação para aplicar estes conceitos ao seu cluster.
Resumo
- A multitenência no Azure Kubernetes Service (AKS) é a prática de executar múltiplas cargas de trabalho isoladas de inquilinos na infraestrutura partilhada do Kubernetes para reduzir custos e simplificar as operações.
- O namespace-per-tenant é o modelo mais eficiente em termos de custos para cargas de trabalho internas confiáveis porque maximiza a partilha de infraestruturas enquanto aplica limites lógicos.
- O conjunto de nós por inquilino melhora a separação de computação e o controlo de vizinhos ruidosos, mas ainda partilha o plano de controlo do AKS e outros componentes ao nível do cluster.
- Cluster-per-tenant oferece o isolamento entre tenants mais forte para cenários de confiança zero e de elevada regulamentação, mas implica custos mais elevados e maior sobrecarga operacional.