Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Ao responder à pergunta "Como configuro o Kubernetes para multilocação?", os arquitetos devem primeiro entender os limites conceituais e os modelos de isolamento disponíveis. A multilocação no AKS é a prática de executar várias cargas de trabalho isoladas, pertencentes a diferentes equipes, aplicativos ou clientes, em um cluster compartilhado do Kubernetes. Este artigo detalha os conceitos fundamentais e os modelos arquiteturais de multilocação no AKS (Serviço de Kubernetes do Azure).
Dica
Quais são os três modelos de multilocação no AKS? A multilocação do AKS usa um espectro de isolamento com três modelos comuns: isolamento de namespace, isolamento de pool de nós e cluster por locatário. O isolamento de namespace é o mais indicado para equipes internas confiáveis e para a máxima eficiência de custos; o isolamento por pool de nós adiciona uma separação mais forte entre cargas de trabalho, com sobrecarga moderada; e um cluster por locatário oferece o isolamento mais forte para cenários com locatários não confiáveis ou altamente regulados.
Para obter instruções de implementação passo a passo e manifests em YAML, consulte o guia complementar: Práticas recomendadas para multilocação no AKS.
Por que multilocação no AKS?
A multilocação permite que várias equipes, aplicativos ou clientes compartilhem um único cluster do Kubernetes. A principal lógica para a multilocação no AKS é a eficiência de custo e a escala operacional.
Manter um cluster dedicado para cada aplicação ou equipe resulta em fragmentação significativa de recursos, capacidade computacional ociosa e multiplicação da sobrecarga do plano de controle. Ao consolidar cargas de trabalho em clusters multilocatários, as organizações maximizam a utilização de recursos e reduzem os gastos com a nuvem. Operacionalmente, a multilocação reduz o tamanho da frota, o que significa que as equipes de plataforma têm menos clusters para corrigir, atualizar, monitorar e proteger, simplificando assim o gerenciamento do ciclo de vida.
Qual é a diferença entre a multilocação flexível e rígida?
O Kubernetes não é inerentemente um sistema multilocatário. Para obter várias locações, crie um modelo de isolamento "flexível" ou "rígido" com base no nível de confiança entre locatários.
A diferença entre a multilocação flexível e rígida no Kubernetes está principalmente no modelo de confiança e em requisitos de isolamento resultantes. A multilocação flexível pressupõe locatários internos confiáveis e se concentra na prevenção de interferência acidental usando controles lógicos, como namespaces, RBAC e cotas. A multilocação rígida pressupõe confiança baixa ou zero entre locatários e exige controles de isolamento mais fortes para reduzir o risco de acesso mal-intencionado, movimentação lateral e exposição de dados.
| Modelo | Nível de confiança | Objetivo | Caso de uso | Cenários de exemplo |
|---|---|---|---|---|
| Multitenância flexível | Alta confiança entre locatários internos | Evitar interferência acidental, falta de recursos e colisões de configuração | Ambientes internos de plataforma em que as equipes compartilham a infraestrutura | Várias equipes de produtos em uma organização compartilhando um cluster do AKS para desenvolvimento/teste e serviços internos |
| Multilocação rígida | Confiança baixa ou zero entre locatários | Evitar ataques mal-intencionados, movimentação lateral e exfiltração de dados | Hospedagem de clientes externos e cargas de trabalho regulamentadas | Provedor de SaaS que hospeda cargas de trabalho específicas de cada cliente, em que o isolamento entre locatários é um requisito de segurança e conformidade |
O espectro de isolamento
A multilocação no AKS não é uma escolha binária; ela existe ao longo de um espectro. À medida que você se move pelo espectro, o isolamento aumenta, mas também a complexidade operacional e o custo. Esse espectro constitui a base de organização para o projeto de cluster multilocatário:
- Isolamento de namespace (Lógico): os locatários compartilham os mesmos pools de nós e o plano de controle, mas são separados logicamente por namespaces do Kubernetes. Esta é a base da multilocação flexível.
- Isolamento do pool de nós (computação física): os locatários compartilham o plano de controle, mas recebem nós de trabalho dedicados. Isso melhora a separação de cargas de trabalho e a mitigação do efeito de vizinho barulhento, mas não representa isolamento completo de locatários porque os componentes do plano de controle e em nível de cluster ainda são compartilhados.
- Um cluster por locatário (totalmente físico): locatários são totalmente isolados, com seus próprios planos de controle e de dados do AKS. Essa é a forma mais extrema de multilocação rígida, contornando na prática o compartilhamento em nível de Kubernetes em favor do isolamento em nível do Azure.
Primitivos do AKS para multilocação
O AKS fornece um conjunto de primitivas nativas e integradas ao Azure para garantir o espectro de isolamento.
- Microsoft Entra ID: fornece gerenciamento centralizado de identidade e acesso para autenticar usuários e sistemas automatizados na API do Kubernetes.
- Azure RBAC: mapeia identidades Microsoft Entra ID para permissões do Kubernetes, garantindo que os locatários só possam acessar seus recursos autorizados.
- Namespaces gerenciados: Fornece limites lógicos dentro do cluster para agrupar recursos dos locatários, aplicar cotas e definir o escopo do acesso.
- Azure Policy/Gatekeeper: impõe regras centralizadas de conformidade e governança em todo o cluster para impedir que os locatários implantem configurações não seguras ou não autorizadas.
- Azure CNI: fornece integração de rede virtual nativa para a rede do AKS e dá suporte à segmentação de tráfego de locatário com controles de política de rede. O comportamento do IP do pod depende do modo CNI selecionado (por exemplo, Overlay ou Sub-rede do Pod).
- Azure ACNS (Serviços de Rede de Contêiner) Cilium L7: fornece políticas de rede baseadas em eBPF de alto desempenho e filtragem de tráfego de Camada 7 para isolar estritamente o tráfego de rede do locatário.
- Identidade de carga de trabalho: permite que pods individuais se autentiquem com segurança em serviços externos do Azure usando identidade federada, eliminando segredos compartilhados entre locatários.
Mapeando camadas de isolamento entre planos
Para criar uma arquitetura segura de vários locatários, você deve aplicar os primitivos do AKS em três planos distintos do ambiente do cluster.
| Avião | Description | Primitivos do AKS aplicados |
|---|---|---|
| Plano de controle | Protegendo o acesso ao servidor de API do Kubernetes e aos limites lógicos. | Microsoft Entra ID, AZURE RBAC, namespaces gerenciados |
| Plano de dados | Proteger o tráfego de rede, a execução de computação e limites em nível do nó. | CNI do Azure, ACNS com Cilium L7, pools de nós |
| Plano de recursos | Controlar o consumo de computação, o acesso externo e a conformidade de configuração. | Azure Policy, identidade da carga de trabalho |
Qual modelo de isolamento você deve escolher?
Use a matriz a seguir para determinar qual ponto no espectro de isolamento melhor atende aos seus requisitos organizacionais.
| Modelo de isolamento | Nível de segurança | Redução de custos | Complexidade operacional | Melhor ajuste para |
|---|---|---|---|---|
| Namespace por locatário | Baixo a Médio (Lógico) | Alto (compartilhamento máximo) | Baixo (um único cluster para gerenciar) | Equipes internas, ambientes de desenvolvimento/teste, multilocação flexível. |
| Pool de nós por locatário | Alta (computação isolada) | Médio (plano de controle compartilhado) | Médio (Gerenciamento de manchas/tolerâncias) | Cargas de trabalho internas e externas que precisam de separação de computação mais forte ao compartilhar um plano de controle; não é ideal para locação hostil de confiança zero. |
| Cluster por locatário | Máximo (físico) | Baixo (sobrecarga alta) | Alto (gerenciamento de frota necessário) | Multilocação hostil, clientes corporativos externos, confiança zero. |
Quando usar cada modelo
- Use um namespace por locatário quando os locatários forem internos ou confiáveis, quando a eficiência de custo for uma prioridade e quando os controles de isolamento lógico forem suficientes.
- Use o pool de nós por locatário quando precisar de um isolamento computacional mais forte e de menor impacto de vizinhos barulhentos, mantendo o compartilhamento de um único plano de controle do AKS.
- Use um cluster por locatário quando os locatários não forem confiáveis, os limites regulatórios forem rigorosos ou seu modelo de risco exigir o mínimo de infraestrutura compartilhada.
Próximas Etapas
Agora que você entende os modelos conceituais e as primitivas de multilocação, siga para o guia de implementação para aplicar esses conceitos ao seu cluster.
Ponto-chave
- A multilocação no AKS (Serviço de Kubernetes do Azure) é a prática de executar cargas de trabalho isoladas de vários locatários em uma infraestrutura compartilhada do Kubernetes para reduzir custos e simplificar as operações.
- O namespace por locatário é o modelo mais econômico para cargas de trabalho internas confiáveis, pois maximiza o compartilhamento de infraestrutura ao aplicar limites lógicos.
- O pool de nós por locatário melhora a separação de computação e o controle de vizinho barulhento, mas ainda compartilha o plano de controle do AKS e outros componentes em nível de cluster.
- Um cluster por locatário oferece o mais alto nível de isolamento entre locatários para cenários de confiança zero e altamente regulamentados, mas exige custos mais altos e maior sobrecarga operacional.