Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Quando si risponde alla domanda "Come si configura Kubernetes per la multi-tenancy?", gli architetti devono prima comprendere i limiti concettuali e i modelli di isolamento disponibili. La multi-tenancy in AKS consiste nell'eseguire più carichi di lavoro isolati, appartenenti a team, applicazioni o clienti diversi, in un cluster Kubernetes condiviso. Questo articolo illustra in dettaglio i concetti di base e i modelli architetturali per la multi-tenancy su Servizio Azure Kubernetes (AKS).
Tip
Quali sono i tre modelli multi-tenant in AKS? La multi-tenancy di AKS usa uno spettro di isolamento con tre modelli comuni: isolamento del namespace, isolamento del pool di nodi e un cluster per tenant. L'isolamento del namespace è ideale per i team interni fidati e per la massima efficienza in termini di costi; l'isolamento del pool di nodi aggiunge una separazione più netta dei carichi di lavoro con un overhead moderato; un cluster per tenant offre invece il massimo isolamento per scenari non fidati o altamente regolamentati.
Per istruzioni dettagliate per l'implementazione e i manifest YAML, consulta la guida di accompagnamento: Procedure consigliate per la multi-tenancy in AKS.
Perché il multi-tenancy nel servizio Azure Kubernetes?
La multi-tenancy consente a più team, applicazioni o clienti di condividere un singolo cluster Kubernetes. La motivazione principale della multi-tenancy in AKS è l'efficienza in termini di costi e la scalabilità operativa.
Gestire un cluster dedicato per ciascuna applicazione o team comporta una significativa frammentazione delle risorse, risorse di calcolo inutilizzate e un overhead del piano di controllo moltiplicato. Consolidando i carichi di lavoro in cluster multi-tenant, le organizzazioni ottimizzano l'utilizzo delle risorse e riducono la spesa per il cloud. In modo operativo, la multi-tenancy riduce le dimensioni della flotta, ovvero i team della piattaforma hanno meno cluster per applicare patch, aggiornare, monitorare e proteggere, semplificando così la gestione del ciclo di vita.
Qual è la differenza tra la multi-tenancy soft e quella hard?
Kubernetes non è intrinsecamente un sistema multi-tenant. Per supportare la multi-tenancy, è necessario progettare il sistema secondo un modello di isolamento "soft" o "hard", in base al livello di fiducia tra i tenant.
La differenza tra multi-tenancy soft e hard in Kubernetes risiede principalmente nel modello di fiducia e nei requisiti di isolamento che ne derivano. La multi-tenancy leggera presuppone tenant interni fidati e si concentra sulla prevenzione di interferenze accidentali tramite controlli logici come namespace, RBAC e quote. La multi-tenancy forte presuppone un livello di fiducia basso o nullo tra i tenant e richiede controlli di isolamento più rigorosi per ridurre il rischio di accessi malevoli, movimento laterale ed esposizione dei dati.
| Model | Livello di attendibilità | Obiettivo | Caso di utilizzo | Scenari di esempio |
|---|---|---|---|---|
| Multi-tenancy flessibile | Elevata fiducia tra i tenant interni | Prevenire interferenze accidentali, esaurimento delle risorse e conflitti di configurazione | Ambienti della piattaforma interna in cui i team condividono l'infrastruttura | Più team di prodotto in un'organizzazione che condividono un cluster del servizio Azure Kubernetes per i servizi di sviluppo/test e interni |
| Multi-tenancy rigida | Fiducia bassa o nulla tra i tenant | Prevenire attacchi dannosi, spostamento laterale ed esfiltrazione di dati | Hosting di clienti esterni e carichi di lavoro regolamentati | Provider SaaS che ospita carichi di lavoro specifici del cliente in cui l'isolamento del tenant è un requisito di sicurezza e conformità |
Spettro di isolamento
L'approccio multi-tenant in AKS non è una scelta binaria; si colloca lungo uno spettro. Man mano che ci si sposta lungo lo spettro, l'isolamento aumenta, ma aumentano anche la complessità operativa e i costi. Questo spettro costituisce l'asse portante per la progettazione di cluster multi-tenant:
- Isolamento dello spazio dei nomi (logico): i tenant condividono gli stessi pool di nodi e lo stesso piano di controllo, ma sono separati logicamente dagli spazi dei nomi Kubernetes. Questo è il fondamento della soft multi-tenancy.
- Isolamento del pool di nodi (calcolo fisico): i tenant condividono il piano di controllo ma vengono assegnati nodi di lavoro dedicati. Ciò migliora la separazione dei carichi di lavoro e la mitigazione del problema del vicino rumoroso, ma non garantisce un isolamento completo del tenant, perché il piano di controllo e i componenti a livello di cluster sono ancora condivisi.
- Cluster per tenant (fisico completo): i tenant sono completamente isolati e dispongono di un proprio piano di controllo AKS e di un proprio piano dati. Questa è la forma più estrema di multi-tenancy rigida, che di fatto aggira la condivisione a livello Kubernetes a favore dell'isolamento a livello Azure.
Primitive di AKS per ambienti multi-tenant
AKS offre una suite di primitive native e integrate con Azure per implementare i diversi livelli di isolamento.
- Microsoft Entra ID: fornisce la gestione centralizzata delle identità e degli accessi per l'autenticazione di utenti e sistemi automatizzati all'API Kubernetes.
- Azure RBAC: associa le identità di Microsoft Entra ID alle autorizzazioni di Kubernetes, garantendo che i tenant possano accedere solo alle risorse per cui sono autorizzati.
- Namespace gestiti: fornisce confini logici all'interno del cluster per raggruppare le risorse del tenant, applicare quote e definire l'ambito di accesso.
- Criteri di Azure/Gatekeeper: applica regole di governance e conformità centralizzate nel cluster per impedire ai tenant di distribuire configurazioni non sicure o non autorizzate.
- Azure CNI: fornisce l'integrazione nativa con la rete virtuale per il networking di AKS e supporta la segmentazione del traffico dei tenant tramite criteri di rete. Il comportamento ip del pod dipende dalla modalità CNI selezionata, ad esempio Overlay o Subnet pod.
- Azure Container Networking Services (ACNS) Cilium L7: offre criteri di rete basati su eBPF ad alte prestazioni e filtro del traffico di livello 7 per isolare rigorosamente il traffico di rete del tenant.
- Identità del carico di lavoro: consente ai singoli pod di eseguire l'autenticazione in modo sicuro ai servizi di Azure esterni usando l'identità federata, eliminando i segreti condivisi tra i tenant.
Mappatura dei livelli di isolamento tra i piani
Per creare un'architettura multi-tenant sicura, è necessario applicare le primitive del servizio Azure Kubernetes in tre piani distinti dell'ambiente cluster.
| Aereo | Description | Primitive del servizio Azure Kubernetes applicate |
|---|---|---|
| Piano di controllo | Protezione dell'accesso al server API Kubernetes e ai limiti logici. | Microsoft Entra ID, controllo degli accessi in base al ruolo Azure, spazi dei nomi gestiti |
| Piano dati | Protezione del traffico di rete, dell'esecuzione di calcolo e dei limiti a livello di nodo. | Azure CNI, ACNS Cilium L7, Pool di nodi |
| Piano di risorse | Gestire il consumo delle risorse di calcolo, gli accessi esterni e la conformità della configurazione. | Criteri di Azure, identità del carico di lavoro |
Quale modello di isolamento è necessario scegliere?
Usare la matrice seguente per determinare quale punto dello spettro di isolamento meglio soddisfa i requisiti dell'organizzazione.
| Modello di isolamento | Livello di sicurezza | Efficienza dei costi | Complessità operativa | Ideale per |
|---|---|---|---|---|
| Namespace per tenant | Da basso a medio (logico) | Alto (condivisione massima) | Basso (singolo cluster da gestire) | Team interni, ambienti di sviluppo e test, multi-tenancy flessibile. |
| Node-pool-per-tenant | Alto (elaborazione isolata) | Medio (piano di controllo condiviso) | Medio (gestione di taints/tolerations) | Carichi di lavoro interni ed esterni che richiedono una separazione più netta delle risorse di calcolo pur condividendo un piano di controllo; non ideale per ambienti di tenancy ostili basati su un modello zero trust. |
| Cluster-per-tenant | Massima (fisica) | Basso (sovraccarico elevato) | Alto (gestione della flotta richiesta) | Multi-tenancy ostile, clienti aziendali esterni, zero-trust. |
Quando usare ogni modello
- Utilizzare uno spazio dei nomi per tenant quando i tenant sono interni o attendibili, il contenimento dei costi è una priorità e i controlli di isolamento logico sono sufficienti.
- Usa node-pool-per-tenant quando hai bisogno di un isolamento più forte delle risorse di calcolo e di ridurre l'impatto dei noisy neighbor, continuando a condividere un unico piano di controllo di AKS.
- Usare cluster per tenant quando i tenant non sono attendibili, i limiti normativi sono rigidi o il modello di rischio richiede un'infrastruttura condivisa minima.
Passaggi successivi
Ora che hai compreso i modelli concettuali e le primitive del multitenancy, procedi alla guida di implementazione per applicare questi concetti al tuo cluster.
Conclusione
- La multi-tenancy in Servizio Azure Kubernetes (AKS) è la pratica di eseguire più carichi di lavoro tenant isolati nell'infrastruttura Kubernetes condivisa per ridurre i costi e semplificare le operazioni.
- Namespace-per-tenant è il modello più conveniente per carichi di lavoro interni attendibili perché ottimizza la condivisione dell'infrastruttura applicando limiti logici.
- Node-pool-per-tenant migliora la separazione delle risorse di calcolo e il contenimento del problema del "noisy neighbor", ma continua a condividere il piano di controllo di AKS e altri componenti a livello di cluster.
- Il cluster per tenant offre l'isolamento del tenant più sicuro per scenari con attendibilità zero e altamente regolamentati, ma richiede costi più elevati e un sovraccarico operativo maggiore.