considerazioni servizio Azure Kubernetes (AKS) per la multi-tenancy

Azure
Servizio Azure Kubernetes

servizio Azure Kubernetes semplifica la distribuzione di un cluster Kubernetes gestito in Azure tramite l'offload del sovraccarico operativo alla piattaforma cloud di Azure. Come servizio Kubernetes ospitato, Azure gestisce attività critiche quali il monitoraggio dell'integrità e la manutenzione. La piattaforma Azure gestisce il piano di controllo del servizio Azure Kubernetes e si paga solo per i nodi di tale servizio che eseguono le applicazioni.

I cluster del servizio Azure Kubernetes possono essere condivisi tra più tenant in diversi scenari e modi. In alcuni casi, diverse applicazioni possono essere eseguite nello stesso cluster. In altri casi, più istanze della stessa applicazione possono essere eseguite nello stesso cluster condiviso, una per ogni tenant. Tutti questi tipi di condivisione vengono spesso descritti usando il termine multitenancy generico. Kubernetes non ha un concetto di prima classe di utenti finali o tenant. Offre comunque diverse funzionalità che consentono di gestire requisiti di tenancy diversi.

In questo articolo vengono descritte alcune delle funzionalità del servizio Azure Kubernetes utili per la creazione di sistemi multi-tenant. Per indicazioni generali e procedure consigliate per la multi-tenancy di Kubernetes, vedere Multi-tenancy nella documentazione di Kubernetes.

Tipi multi-tenancy

Il primo passaggio per determinare come condividere un cluster del servizio Azure Kubernetes tra più tenant consiste nel valutare i modelli e gli strumenti a disposizione. In generale, la multi-tenancy nei cluster Kubernetes rientra in due categorie principali, anche se molte varianti sono ancora possibili. La documentazione di Kubernetes descrive due casi d'uso comuni per la multi-tenancy: più team e più clienti.

Più team

Una forma comune di multi-tenancy consiste nel condividere un cluster tra più team all'interno di un'organizzazione. Ogni team può distribuire, monitorare e gestire una o più soluzioni. Questi carichi di lavoro devono spesso comunicare tra loro e con altre applicazioni interne o esterne che si trovano nello stesso cluster o in altre piattaforme di hosting.

Inoltre, questi carichi di lavoro devono comunicare con i servizi, ad esempio un database relazionale, un repository NoSQL o un sistema di messaggistica, ospitato nello stesso cluster o in esecuzione come servizi PaaS in Azure.

In questo scenario, i membri dei team spesso hanno accesso diretto alle risorse Kubernetes tramite strumenti, ad esempio kubectl. In alternativa, i membri hanno accesso indiretto tramite controller GitOps, ad esempio Flux e Argo CD, o tramite altri tipi di strumenti di automazione delle versioni.

Per altre informazioni su questo scenario, vedere Più team nella documentazione di Kubernetes.

Più clienti

Un'altra forma comune di multi-tenancy comporta spesso un fornitore SaaS (Software-as-a-Service). In alternativa, un provider di servizi esegue più istanze di un carico di lavoro per i clienti, considerate tenant separati. In questo scenario, i clienti non hanno accesso diretto al cluster del servizio Azure Kubernetes, ma hanno accesso solo all'applicazione. Inoltre, non sanno nemmeno che l'applicazione viene eseguita in Kubernetes. L'ottimizzazione dei costi è spesso un problema critico. I provider di servizi usano criteri Kubernetes, ad esempio quote di risorse e criteri di rete, per assicurarsi che i carichi di lavoro siano fortemente isolati l'uno dall'altro.

Per altre informazioni su questo scenario, vedere Più clienti nella documentazione di Kubernetes.

Modelli di isolamento

In base alla documentazione di Kubernetes, un cluster Kubernetes multi-tenant è condiviso da più utenti e carichi di lavoro comunemente definiti tenant. Questa definizione include cluster Kubernetes condivisi da team o divisioni diversi all'interno di un'organizzazione. Contiene anche cluster condivisi da istanze per cliente di un'applicazione SaaS (Software-as-a-Service).

L'architettura multi-tenancy del cluster è un'alternativa alla gestione di molti cluster dedicati a tenant singolo. Gli operatori di un cluster Kubernetes multi-tenant devono isolare i tenant l'uno dall'altro. Questo isolamento riduce al minimo i danni che un tenant compromesso o dannoso può fare al cluster e ad altri tenant.

Quando più utenti o team condividono lo stesso cluster con un numero fisso di nodi, c'è preoccupazione che un team possa usare più della propria equa condivisione di risorse. Resource Quotas è uno strumento per amministratori che consente di risolvere questo problema.

In base al livello di sicurezza fornito dall'isolamento, è possibile distinguere tra multitenancy soft e hard.

  • La multi-tenancy soft è adatta all'interno di una singola azienda in cui i tenant sono team o reparti diversi che si considerano attendibili tra loro. In questo scenario, l'isolamento mira a garantire l'integrità dei carichi di lavoro, orchestrare le risorse del cluster in gruppi di utenti interni diversi e difendersi da possibili attacchi alla sicurezza.
  • La multi-tenancy hard viene usata per descrivere scenari in cui tenant eterogenei non si considerano attendibili tra loro, spesso dalle prospettive di sicurezza e condivisione delle risorse.

Quando si prevede di creare un cluster multi-tenant servizio Azure Kubernetes (servizio Azure Kubernetes), è consigliabile prendere in considerazione i livelli di isolamento delle risorse e multi-tenancy forniti da Kubernetes:

  • Cluster
  • Spazio dei nomi
  • Pool di nodi o nodo
  • Pod
  • Contenitore

È anche consigliabile considerare le implicazioni per la sicurezza della condivisione di risorse diverse tra più tenant. Ad esempio, la pianificazione di pod da tenant diversi sullo stesso nodo può consentire di ridurre il numero di computer necessari nel cluster. D'altra parte, potrebbe essere necessario impedire la collocazione di carichi di lavoro specifici. Ad esempio, potrebbe non consentire l'esecuzione di codice non attendibile dall'esterno dell'organizzazione nello stesso nodo dei contenitori che elaborano informazioni riservate.

Anche se Kubernetes non può garantire un isolamento perfettamente sicuro tra i tenant, offre funzionalità che possono essere sufficienti per casi d'uso specifici. Come procedura consigliata, è consigliabile separare ogni tenant e le relative risorse Kubernetes nei relativi spazi dei nomi. È quindi possibile usare il controllo degli accessi in base al ruolo di Kubernetes e i criteri di rete per applicare l'isolamento del tenant. Ad esempio, l'immagine seguente mostra il modello di provider SaaS tipico che ospita più istanze della stessa applicazione nello stesso cluster, una per ogni tenant. Ogni applicazione risiede in uno spazio dei nomi separato.

Diagramma che mostra un modello di provider SaaS che ospita più istanze della stessa applicazione nello stesso cluster.

Esistono diversi modi per progettare e creare soluzioni multi-tenant con servizio Azure Kubernetes (servizio Azure Kubernetes). Ognuno di questi metodi include un proprio set di compromessi, in termini di distribuzione dell'infrastruttura, topologia di rete e sicurezza. Questi metodi influiscono sul livello di isolamento, sul lavoro di implementazione, sulla complessità operativa e sui costi. È possibile applicare l'isolamento del tenant nei piani dati e di controllo, in base alle esigenze.

Isolamento del piano di controllo

Se si ha isolamento a livello di piano di controllo, si garantisce che i diversi tenant non possano accedere o influire sulle risorse di ognuno, ad esempio pod e servizi. Inoltre, non possono influire sulle prestazioni delle applicazioni di altri tenant. Per altre informazioni, vedere Isolamento del piano di controllo nella documentazione di Kubernetes. Il modo migliore per implementare l'isolamento a livello del piano di controllo consiste nel separare il carico di lavoro di ogni tenant e le relative risorse Kubernetes in uno spazio dei nomi separato.

Secondo la documentazione di Kubernetes, uno spazio dei nomi è un'astrazione usata per supportare l'isolamento dei gruppi di risorse all'interno di un singolo cluster. Gli spazi dei nomi possono essere usati per isolare i carichi di lavoro tenant che condividono un cluster Kubernetes:

  • Gli spazi dei nomi consentono l'esistenza di carichi di lavoro tenant distinti nella propria area di lavoro virtuale, senza il rischio di influire sul lavoro dell'altro. I team separati all'interno di un'organizzazione possono usare spazi dei nomi per isolare i progetti tra loro, perché possono usare gli stessi nomi di risorse in spazi dei nomi diversi senza il rischio di sovrapposizione del nome.
  • I ruoli del controllo degli accessi in base al ruolo e le associazioni di ruolo sono risorse con ambito spazio dei nomi che i team possono usare per limitare gli utenti e i processi del tenant per accedere alle risorse e ai servizi solo nei relativi spazi dei nomi. Diversi team possono definire ruoli per raggruppare elenchi di autorizzazioni o capacità con un singolo nome. Assegnano quindi questi ruoli agli account utente e agli account di servizio, per assicurarsi che solo le identità autorizzate abbiano accesso alle risorse in uno spazio dei nomi specifico.
  • Le quote di risorse per CPU e memoria sono oggetti con spazio dei nomi. I team possono usarli per assicurarsi che i carichi di lavoro che condividono lo stesso cluster siano fortemente isolati da un consumo di risorse di sistema. Questo metodo può garantire che ogni applicazione tenant eseguita in uno spazio dei nomi separato disponga delle risorse necessarie per l'esecuzione ed evitare problemi di prossimità rumorosi, che potrebbero influire su altre applicazioni tenant che condividono lo stesso cluster.
  • I criteri di rete sono oggetti con spazio dei nomi che i team possono adottare per applicare il traffico di rete consentito per una determinata applicazione tenant. È possibile usare i criteri di rete per separare carichi di lavoro distinti che condividono lo stesso cluster dal punto di vista della rete.
  • Le applicazioni team eseguite in spazi dei nomi distinti possono usare account di servizio diversi, per accedere alle risorse all'interno dello stesso cluster, applicazioni esterne o servizi gestiti.
  • Usare gli spazi dei nomi per migliorare le prestazioni a livello del piano di controllo. Se i carichi di lavoro in un cluster condiviso sono organizzati in più spazi dei nomi, l'API Kubernetes include meno elementi da cercare durante l'esecuzione delle operazioni. Questa organizzazione può ridurre la latenza delle chiamate sul server API e aumentare la velocità effettiva del piano di controllo.

Per altre informazioni sull'isolamento a livello di spazio dei nomi, vedere le risorse seguenti nella documentazione di Kubernetes:

Isolamento del piano dati

L'isolamento del piano dati garantisce che i pod e i carichi di lavoro di tenant distinti siano sufficientemente isolati l'uno dall'altro. Per altre informazioni, vedere Isolamento del piano dati nella documentazione di Kubernetes.

Isolamento della rete

Quando si eseguono applicazioni moderne basate su microservizi in Kubernetes, è spesso consigliabile controllare i componenti che possono comunicare tra loro. Per impostazione predefinita, tutti i pod in un cluster del servizio Azure Kubernetes possono inviare e ricevere traffico senza restrizioni, incluse altre applicazioni che condividono lo stesso cluster. Per migliorare la sicurezza, è possibile definire regole di rete per controllare il flusso del traffico. I criteri di rete sono una specifica kubernetes che definisce i criteri di accesso per la comunicazione tra pod. È possibile usare i criteri di rete per separare le comunicazioni tra le applicazioni tenant che condividono lo stesso cluster.

servizio Azure Kubernetes (servizio Azure Kubernetes) offre due modi per implementare i criteri di rete:

  1. Azure ha la sua implementazione per i criteri di rete, denominati criteri di rete di Azure.
  2. I criteri di rete Calico sono una soluzione di rete e sicurezza di rete open source fondata da Tigera.

Entrambe le implementazioni usano Linux IPTables per applicare i criteri specificati. I criteri di rete vengono convertiti in set di coppie IP consentite e non consentite. Queste coppie vengono quindi programmate come regole del filtro IPTable. È possibile usare solo i criteri di rete di Azure con i cluster del servizio Azure Kubernetes configurati con il plug-in di rete CNI di Azure. Tuttavia, i criteri di rete Calico supportano sia Azure CNI che kubenet. Per altre informazioni, vedere Proteggere il traffico tra i pod usando i criteri di rete in servizio Azure Kubernetes.

Per altre informazioni, vedere Isolamento della rete nella documentazione di Kubernetes.

Isolamento dello spazio di archiviazione

Azure offre un set completo di repository di dati PaaS (Platform-as-a-Service), ad esempio database SQL di Azure e Azure Cosmos DB, e altri servizi di archiviazione che è possibile usare come volumi permanenti per i carichi di lavoro. Le applicazioni tenant in esecuzione in un cluster del servizio Azure Kubernetes condiviso possono condividere un database o un archivio file oppure possono usare un repository di dati dedicato e una risorsa di archiviazione. Per altre informazioni su strategie e approcci diversi per gestire i dati in uno scenario multi-tenant, vedere Approcci architetturali per l'archiviazione e i dati in soluzioni multi-tenant.

I carichi di lavoro in esecuzione in servizio Azure Kubernetes (servizio Azure Kubernetes) possono anche usare volumi permanenti per archiviare i dati. In Azure è possibile creare volumi permanenti come risorse Kubernetes supportate da Archiviazione di Azure. È possibile creare manualmente volumi di dati e assegnarli direttamente ai pod oppure creare automaticamente il servizio Azure Kubernetes usando attestazioni di volume persistente. Il servizio Azure Kubernetes offre classi di archiviazione predefinite per creare volumi persistenti supportati da Dischi di Azure, File di Azure e Azure NetApp Files. Per altre informazioni, vedere Opzioni di archiviazione per le applicazioni nel servizio Azure Kubernetes. Per motivi di sicurezza e resilienza, è consigliabile evitare di usare l'archiviazione locale nei nodi dell'agente tramite emptyDir e hostPath.

Quando le classi di archiviazione predefinite del servizio Azure Kubernetes non sono adatte a uno o più tenant, è possibile creare classi di archiviazione personalizzate per soddisfare i diversi requisiti dei tenant. Questi requisiti includono le dimensioni del volume, lo SKU di archiviazione, un contratto di servizio (SLA), i criteri di backup e il piano tariffario.

Ad esempio, è possibile configurare una classe di archiviazione personalizzata per ogni tenant. È quindi possibile usarlo per applicare tag a qualsiasi volume permanente creato nello spazio dei nomi per ricaricare i costi. Per altre informazioni su questo scenario, vedere Usare i tag di Azure in servizio Azure Kubernetes (servizio Azure Kubernetes).

Per altre informazioni, vedere Isolamento dell'archiviazione nella documentazione di Kubernetes.

Isolamento del nodo

È possibile configurare i carichi di lavoro del tenant per l'esecuzione in nodi agente separati per evitare il problema Noisy Neighbor e ridurre il rischio di divulgazione di informazioni. Nel servizio Azure Kubernetes è possibile creare un cluster separato o semplicemente un pool di nodi dedicato per i tenant con requisiti rigorosi per isolamento, sicurezza, conformità alle normative e prestazioni.

È possibile usaretaints, tolerations, node labels, node selector e node affinity per vincolare i pod dei tenant per l'esecuzione solo in un determinato set di nodi o pool di nodi.

In generale, il servizio Azure Kubernetes offre l'isolamento del carico di lavoro a vari livelli:

  • A livello di kernel, eseguendo carichi di lavoro tenant in macchine virtuali leggere nei nodi dell'agente condiviso e usando Pod Sandboxing basato su contenitori Kata.
  • A livello fisico, ospitando applicazioni tenant in cluster o pool di nodi dedicati.
  • A livello di hardware, eseguendo carichi di lavoro tenant in host dedicati di Azure che garantiscono che le macchine virtuali del nodo agente eseguano computer fisici dedicati. L'isolamento hardware garantisce che nessun'altra macchina virtuale venga inserita negli host dedicati, fornendo un ulteriore livello di isolamento per i carichi di lavoro del tenant.

È possibile combinare queste tecniche. Ad esempio, è possibile eseguire cluster e pool di nodi per tenant in un gruppo host dedicato di Azure per ottenere la separazione del carico di lavoro e l'isolamento fisico a livello di hardware. È anche possibile creare pool di nodi condivisi o per tenant che supportano fips (Federal Information Process Standard), confidential Macchine virtuali (CVM) o la crittografia basata su host.

L'isolamento dei nodi consente di associare e ricaricare facilmente il costo di un set di nodi o pool di nodi a un singolo tenant. È strettamente correlato al modello di tenancy adottato dalla soluzione.

Per altre informazioni, vedere Isolamento dei nodi nella documentazione di Kubernetes.

Modelli di tenancy

servizio Azure Kubernetes (servizio Azure Kubernetes) offre più tipi di modelli di isolamento dei nodi e tenancy.

Distribuzioni a tenant singolo automatizzate

In un modello di distribuzione a tenant singolo automatizzato si distribuisce un set dedicato di risorse per ogni tenant, come illustrato in questo esempio:

Diagramma che mostra tre tenant, ognuno con distribuzioni separate.

Ogni carico di lavoro del tenant viene eseguito in un cluster del servizio Azure Kubernetes dedicato e accede a un set distinto di risorse di Azure. In genere, le soluzioni multi-tenant create con questo modello usano ampiamente l'infrastruttura come codice (IaC). Ad esempio, Bicep, Azure Resource Manager, Terraform o le API REST di Azure Resource Manager consentono di avviare e coordinare la distribuzione su richiesta di risorse dedicate al tenant. È possibile usare questo approccio quando è necessario effettuare il provisioning di un'infrastruttura completamente separata per ognuno dei clienti. Quando si pianifica la distribuzione, è consigliabile usare il modello Stamp di distribuzione.

Vantaggi:

  • Un vantaggio fondamentale di questo approccio è che il server API di ogni cluster del servizio Azure Kubernetes tenant è separato. Questo approccio garantisce l'isolamento completo tra i tenant da un livello di sicurezza, rete e consumo di risorse. Un utente malintenzionato che riesce a ottenere il controllo di un contenitore avrà accesso solo ai contenitori e ai volumi montati che appartengono a un singolo tenant. Un modello di tenancy con isolamento completo è fondamentale per alcuni clienti con un sovraccarico elevato di conformità alle normative.
  • È improbabile che i tenant influiscano sulle prestazioni del sistema dell'altro, che consente di evitare il problema Noisy Neighbor. Questa considerazione include il traffico sul server API. Il server API è un componente condiviso e critico in qualsiasi cluster Kubernetes. I controller personalizzati, che generano traffico senza regole e volumi elevati sul server API, possono causare instabilità del cluster. Questa instabilità causa errori, timeout e tempeste di tentativi api. La funzionalità Contratto di servizio tempo di attività (contratto di servizio) consente di aumentare il piano di controllo di un cluster del servizio Azure Kubernetes per soddisfare la domanda di traffico. Tuttavia, il provisioning di un cluster dedicato può essere una soluzione migliore per i clienti con requisiti rigorosi in termini di isolamento del carico di lavoro.
  • Gli aggiornamenti e le modifiche possono essere implementati progressivamente tra i tenant, riducendo la probabilità di un'interruzione a livello di sistema. I costi di Azure possono essere addebitati facilmente ai tenant, perché ogni risorsa viene usata da un singolo tenant.

Rischi:

  • L'efficienza dei costi è bassa perché ogni tenant usa un set dedicato di risorse.
  • È probabile che la manutenzione in corso richieda molto tempo, perché deve essere replicata in più cluster del servizio Azure Kubernetes, uno per ogni tenant. Prendere in considerazione l'automazione dei processi operativi e l'applicazione progressiva delle modifiche tramite gli ambienti. Può essere utile se si considerino anche altre operazioni di distribuzione incrociata, ad esempio la creazione di report e l'analisi nell'intero patrimonio. Analogamente, assicurarsi di pianificare come eseguire query e modificare i dati tra più distribuzioni.

Distribuzioni completamente multi-tenant

In una distribuzione completamente multi-tenant, una singola applicazione gestisce le richieste di tutti i tenant e tutte le risorse di Azure vengono condivise, incluso il cluster del servizio Azure Kubernetes. In questo contesto è disponibile un solo set di infrastrutture da distribuire, monitorare e gestire. Tutti i tenant usano la risorsa, come illustrato nel diagramma seguente:

Diagramma che mostra tre tenant, tutti con una singola distribuzione condivisa.

Vantaggi:

  • Questo modello è interessante a causa del costo inferiore della gestione di una soluzione con componenti condivisi. Quando si usa questo modello di tenancy, potrebbe essere necessario distribuire un cluster del servizio Azure Kubernetes di dimensioni maggiori e adottare uno SKU superiore per qualsiasi repository di dati condiviso per sostenere il traffico generato da tutte le risorse dei tenant, ad esempio i repository di dati.

Rischi:

  • In questo contesto, una singola applicazione gestisce tutte le richieste dei tenant. È necessario progettare e implementare misure di sicurezza per impedire ai tenant di inondare l'applicazione con chiamate. Queste chiamate potrebbero rallentare l'intero sistema e influire su tutti i tenant.
  • Se il profilo di traffico è altamente variabile, è necessario configurare il ridimensionamento automatico del cluster del servizio Azure Kubernetes per variare il numero di pod e nodi agente. Basare la configurazione sull'utilizzo delle risorse di sistema, ad esempio CPU e memoria. In alternativa, è possibile aumentare e ridurre il numero di pod e nodi del cluster, in base alle metriche personalizzate. Ad esempio, è possibile esplorare il numero di richieste in sospeso o le metriche di un sistema di messaggistica esterno che usa la scalabilità automatica guidata dagli eventi di Kubernetes (KEDA).
  • Assicurarsi di separare i dati per ogni tenant e implementare misure di sicurezza per evitare perdite di dati tra tenant diversi.
  • Assicurarsi di tenere traccia e associare i costi di Azure ai singoli tenant, in base all'utilizzo effettivo. Le soluzioni di terze parti, ad esempio kubecost, consentono di calcolare e suddividere i costi tra team e tenant diversi.
  • La manutenzione può essere più semplice con una singola distribuzione, perché è necessario aggiornare un solo set di risorse di Azure e gestire una singola applicazione. Tuttavia, è anche più rischioso poiché eventuali modifiche apportate all'infrastruttura o ai componenti dell'applicazione possono influire sull'intera base dei clienti.
  • È anche consigliabile prendere in considerazione le limitazioni di scalabilità. È più probabile che si verifichino limiti di scalabilità delle risorse di Azure quando si dispone di un set condiviso di risorse. Per evitare di raggiungere un limite di quote di risorse, è consigliabile distribuire i tenant tra più sottoscrizioni di Azure.

Distribuzioni partizionate orizzontalmente

In alternativa, è possibile prendere in considerazione il partizionamento orizzontale dell'applicazione Kubernetes multi-tenant. Questo approccio consiste nella condivisione di alcuni componenti della soluzione in tutti i tenant e nella distribuzione di risorse dedicate per singoli tenant. Ad esempio, è possibile compilare una singola applicazione Kubernetes multi-tenant e quindi creare singoli database, uno per ogni tenant, come illustrato nella figura seguente:

Diagramma che mostra tre tenant, ognuno con un database dedicato e una singola applicazione Kubernetes condivisa.

Vantaggi:

  • Le distribuzioni partizionate orizzontalmente consentono di attenuare il problema Noisy Neighbor. Si consideri questo approccio, se è stato rilevato che la maggior parte del carico di traffico nell'applicazione Kubernetes è dovuta a componenti specifici, che è possibile distribuire separatamente per ogni tenant. Ad esempio, i database potrebbero assorbire la maggior parte del carico del sistema, perché il carico delle query è elevato. Se un singolo tenant invia un numero elevato di richieste alla soluzione, le prestazioni di un database potrebbero essere influenzate negativamente, ma i database di altri tenant (e i componenti condivisi, ad esempio il livello applicazione) rimangono invariati.

Rischi:

  • Con una distribuzione partizionata orizzontalmente, è comunque necessario prendere in considerazione la distribuzione e la gestione automatizzata dei componenti, in particolare i componenti usati da un singolo tenant.
  • Questo modello potrebbe non fornire il livello di isolamento richiesto per i clienti che non possono permettersi di condividere risorse con altri tenant, per motivi di conformità o criteri interni.

Distribuzioni partizionate verticalmente

È possibile sfruttare i vantaggi dei modelli a tenant singolo e completamente multi-tenant usando un modello ibrido che partiziona verticalmente i tenant in più cluster o pool di nodi del servizio Azure Kubernetes. Questo approccio offre i vantaggi seguenti rispetto ai due modelli di tenancy precedenti:

  • È possibile usare una combinazione di distribuzioni a tenant singolo e multi-tenant. Ad esempio, la maggior parte dei clienti può condividere un cluster e un database del servizio Azure Kubernetes in un'infrastruttura multi-tenant. È comunque possibile distribuire infrastrutture a tenant singolo per i clienti che richiedono prestazioni e isolamento più elevati.
  • È possibile distribuire tenant in più cluster del servizio Azure Kubernetes a livello di area, potenzialmente con configurazioni diverse. Questa tecnica è più efficace quando si dispone di tenant distribuiti in aree geografiche diverse.

È possibile implementare diverse varianti di questo modello di tenancy. Ad esempio, è possibile scegliere di offrire la soluzione multi-tenant con diversi livelli di funzionalità a un costo diverso. Il modello di determinazione prezzi può fornire più SKU, ognuno dei quali offre un livello incrementale di prestazioni e isolamento, in termini di condivisione delle risorse, prestazioni, rete e separazione dei dati. Considerare i livelli seguenti:

  • Livello Basic: le richieste di tenant vengono gestite da una singola applicazione Kubernetes multi-tenant condivisa con altri tenant. I dati vengono archiviati in uno o più database condivisi da tutti i tenant di livello Basic.
  • Livello Standard: le richieste di tenant vengono gestite da un'applicazione Kubernetes dedicata che viene eseguita in uno spazio dei nomi separato, che fornisce limiti di isolamento in termini di sicurezza, rete, consumo di risorse. Tutte le applicazioni dei tenant, una per ogni tenant, condividono lo stesso cluster del servizio Azure Kubernetes e il pool di nodi con altri clienti di livello standard.
  • Livello Premium: l'applicazione tenant viene eseguita in un pool di nodi dedicato o in un cluster del servizio Azure Kubernetes per garantire un contratto di servizio superiore, prestazioni migliori e un livello di isolamento superiore. Questo livello può fornire un modello di costo flessibile in base al numero e allo SKU dei nodi agente usati per ospitare l'applicazione tenant. È possibile usare Pod Sandboxing come soluzione alternativa all'uso di cluster o pool di nodi dedicati per isolare carichi di lavoro tenant distinti.

Il diagramma seguente illustra uno scenario in cui i tenant A e B vengono eseguiti in un cluster del servizio Azure Kubernetes condiviso, mentre il tenant C viene eseguito in un cluster del servizio Azure Kubernetes separato.

Diagramma che mostra tre tenant. I tenant A e B condividono un cluster del servizio Azure Kubernetes. Il tenant C ha un cluster del servizio Azure Kubernetes dedicato.

Analogamente, il diagramma seguente illustra uno scenario in cui i tenant A e B vengono eseguiti nello stesso pool di nodi, mentre il tenant C viene eseguito in un pool di nodi dedicato.

Diagramma che mostra tre tenant. I tenant A e B condividono un pool di nodi. Il tenant C ha un pool di nodi dedicato.

Questo modello può anche offrire contratti di servizio diversi per livelli diversi. Ad esempio, il livello Basic può offrire un tempo di attività del 99,9%, il livello standard può offrire un tempo di attività del 99,95% e il livello Premium può offrire il 99,99%. È possibile implementare un contratto di servizio superiore usando servizi e funzionalità che consentono obiettivi di disponibilità più elevati.

Vantaggi:

  • Poiché l'infrastruttura è ancora condivisa, è comunque possibile ottenere alcuni dei vantaggi derivanti dalla condivisione di distribuzioni multi-tenant. È possibile distribuire cluster e pool di nodi condivisi tra più applicazioni tenant di livello basic e di livello standard, che usano dimensioni di macchina virtuale più economiche per i nodi dell'agente. Questo approccio garantisce una migliore densità e risparmi sui costi. Per i clienti di livello Premium, è possibile distribuire cluster del servizio Azure Kubernetes e pool di nodi con dimensioni di macchina virtuale superiori e un numero massimo di repliche e nodi del pod a un prezzo superiore.
  • È possibile eseguire servizi di sistema, ad esempio CoreDNS, Konnectivity o app Azure lication Gateway Ingress Controller, in un pool di nodi dedicato in modalità sistema. È possibile usaretaints, tolerations, node labels, node selector e node affinity per eseguire un'applicazione tenant in uno o più pool di nodi in modalità utente.
  • Per eseguire risorse condivise, è possibile usaretaints, tolerations, etichette dei nodi, selettori di nodo e affinità dei nodi. Ad esempio, è possibile avere un controller di ingresso o un sistema di messaggistica in un pool di nodi dedicato, con dimensioni di macchina virtuale specifiche, impostazioni di scalabilità automatica e supporto delle zone di disponibilità.

Rischi:

  • È necessario progettare l'applicazione Kubernetes per supportare distribuzioni multi-tenant e a tenant singolo.
  • Se si prevede di consentire la migrazione tra infrastrutture, è necessario considerare come eseguire la migrazione dei clienti da una distribuzione multi-tenant alla propria distribuzione a tenant singolo.
  • È necessaria una strategia coerente e un singolo riquadro di vetro (un punto di vista) per monitorare e gestire più cluster del servizio Azure Kubernetes.

Scalabilità automatica

Per mantenere il passo con la domanda di traffico generata dalle applicazioni tenant, è possibile abilitare il ridimensionamento automatico del cluster per ridimensionare i nodi agente del servizio Azure Kubernetes (servizio Azure Kubernetes). La scalabilità automatica consente ai sistemi di rimanere reattivi nelle circostanze seguenti:

  • Il carico del traffico aumenta durante ore lavorative o periodi specifici dell'anno.
  • I carichi elevati del tenant o condivisi vengono distribuiti in un cluster.
  • I nodi dell'agente non sono disponibili a causa di interruzioni di zona.

Quando si abilita la scalabilità automatica per un pool di nodi, si specifica un numero minimo e massimo di nodi in base alle dimensioni previste del carico di lavoro. Configurando un numero massimo di nodi, è possibile garantire spazio sufficiente per tutti i pod tenant nel cluster, indipendentemente dallo spazio dei nomi in cui vengono eseguiti.

Quando il traffico aumenta, la scalabilità automatica del cluster aggiunge nuovi nodi agente per evitare che i pod entrino in uno stato in sospeso, a causa di una carenza di risorse in termini di CPU e memoria.

Analogamente, quando il carico diminuisce, la scalabilità automatica del cluster riduce il numero di nodi agente in un pool di nodi, in base ai limiti specificati, che consente di ridurre i costi operativi.

È possibile usare la scalabilità automatica dei pod per ridimensionare automaticamente i pod in base alle esigenze delle risorse. Horizontal Pod Autoscaler (HPA) ridimensiona automaticamente il numero di repliche pod, in base all'utilizzo della CPU/memoria o alle metriche personalizzate. Con la scalabilità automatica basata su eventi (KEDA) di Kubernetes, è possibile aumentare la scalabilità di qualsiasi contenitore in Kubernetes, in base al numero di eventi di sistemi esterni, ad esempio Hub eventi di Azure o bus di servizio di Azure, usati dalle applicazioni tenant.

Gestione

Per ridurre il rischio di tempi di inattività che possono influire sulle applicazioni tenant durante gli aggiornamenti del cluster o del pool di nodi, pianificare la manutenzione pianificata del servizio Azure Kubernetes durante le ore di minore attività. Manutenzione pianificata consente di pianificare finestre di manutenzione settimanali per aggiornare il piano di controllo dei cluster del servizio Azure Kubernetes che eseguono applicazioni tenant e pool di nodi, riducendo al minimo l'impatto del carico di lavoro. È possibile pianificare una o più finestre di manutenzione settimanali nel cluster specificando un giorno o un intervallo di tempo in un giorno specifico. Tutte le operazioni di manutenzione verranno eseguite durante le finestre pianificate.

Sicurezza

Accesso al cluster

Quando si condivide un cluster del servizio Azure Kubernetes tra più team all'interno di un'organizzazione, è necessario implementare il principio dei privilegi minimi per isolare tenant diversi l'uno dall'altro. In particolare, è necessario assicurarsi che gli utenti abbiano accesso solo agli spazi dei nomi e alle risorse Kubernetes quando si usano strumenti, ad esempio kubectl, Helm, Flux, Argo CD o altri tipi di strumenti.

Per altre informazioni sull'autenticazione e l'autorizzazione con il servizio Azure Kubernetes, vedere gli articoli seguenti:

Identità del carico di lavoro

Se si ospitano più applicazioni tenant in un singolo cluster del servizio Azure Kubernetes e ognuna si trova in uno spazio dei nomi separato, ogni carico di lavoro deve usare un account del servizio Kubernetes e credenziali diversi per accedere ai servizi di Azure downstream. Uno dei tipi di utenti primari in Kubernetes è account del servizio. L'API Kubernetes contiene e gestisce gli account del servizio. Le credenziali dell'account del servizio vengono archiviate come segreti Kubernetes, che consentono di usarle dai pod autorizzati per comunicare con il server API. La maggior parte delle richieste API crea un token di autenticazione per un account del servizio o un account utente normale.

I carichi di lavoro tenant distribuiti nei cluster del servizio Azure Kubernetes possono usare le credenziali dell'applicazione Microsoft Entra per accedere alle risorse protette con ID Microsoft Entra, ad esempio Azure Key Vault e Microsoft Graph. ID dei carichi di lavoro di Microsoft Entra per Kubernetes si integra con le funzionalità native di Kubernetes per la federazione con qualsiasi provider di identità esterno.

Sandboxing dei pod

Il servizio Azure Kubernetes include un meccanismo denominato Pod Sandboxing che fornisce un limite di isolamento tra l'applicazione contenitore e il kernel condiviso e le risorse di calcolo dell'host contenitore, ad esempio CPU, memoria e rete. Pod Sandboxing integra altre misure di sicurezza o controlli di protezione dei dati per aiutare i carichi di lavoro tenant a proteggere le informazioni sensibili e soddisfare i requisiti normativi, di settore o di conformità della governance, ad esempio Payment Card Industry Data Security Standard (PCI DSS), International Organization for Standardization (ISO) 27001 e Health Insurance Portability and Accountability Act (HIPAA).

La distribuzione di applicazioni in cluster o pool di nodi separati consente di isolare fortemente i carichi di lavoro tenant di team o clienti diversi. L'uso di più cluster e pool di nodi potrebbe essere adatto ai requisiti di isolamento di molte organizzazioni e soluzioni SaaS, ma esistono scenari in cui un singolo cluster con pool di nodi di macchine virtuali condivise è più efficiente, ad esempio quando si eseguono pod non attendibili e attendibili nello stesso nodo o si individuano co-individuando DaemonSet e contenitori con privilegi sullo stesso nodo per una comunicazione locale e un raggruppamento funzionale più veloci. Il pod Sandboxing consente di isolare fortemente le applicazioni tenant negli stessi nodi del cluster senza dover eseguire questi carichi di lavoro in cluster o pool di nodi separati. Per altri metodi è necessario ricompilare il codice o causare altri problemi di compatibilità, ma il sandboxing dei pod nel servizio Azure Kubernetes può eseguire qualsiasi contenitore non modificato all'interno di un limite avanzato della macchina virtuale di sicurezza.

La sandbox dei pod nel servizio Azure Kubernetes si basa su contenitori Kata eseguiti nell'host contenitore Linux di Azure per lo stack del servizio Azure Kubernetes per fornire l'isolamento imposto dall'hardware. I contenitori Kata nel servizio Azure Kubernetes sono basati su un hypervisor di Azure con protezione avanzata. L'isolamento per ogni pod viene ottenuto tramite una macchina virtuale Kata leggera annidata che usa risorse da un nodo macchina virtuale padre. In questo modello ogni pod Kata ottiene il proprio kernel in una macchina virtuale guest Kata annidata. Questo modello consente di inserire molti contenitori Kata in una singola macchina virtuale guest, continuando a eseguire i contenitori nella macchina virtuale padre. Il modello fornisce un limite di isolamento sicuro in un cluster del servizio Azure Kubernetes condiviso.

Per altre informazioni, vedi:

Host dedicato di Azure

Host dedicato di Azure è un servizio che fornisce server fisici dedicati a una singola sottoscrizione di Azure e forniscono l'isolamento hardware a livello di server fisico. È possibile effettuare il provisioning di questi host dedicati all'interno di un'area, di una zona di disponibilità e di un dominio di errore ed è possibile inserire le macchine virtuali direttamente negli host di cui è stato effettuato il provisioning.

È possibile ottenere diversi vantaggi usando l'host dedicato di Azure con il servizio Azure Kubernetes, tra cui:

  • L'isolamento hardware garantisce che nessun'altra macchina virtuale venga posizionata negli host dedicati, che fornisce un ulteriore livello di isolamento per i carichi di lavoro del tenant. Gli host dedicati vengono distribuiti negli stessi data center e condividono la stessa rete e la stessa infrastruttura di archiviazione sottostante degli altri host non isolati.

  • Host dedicato di Azure fornisce il controllo sugli eventi di manutenzione avviati dalla piattaforma Azure. È possibile scegliere una finestra di manutenzione per ridurre l'impatto sui servizi e garantire la disponibilità e la privacy dei carichi di lavoro del tenant.

L'host dedicato di Azure può aiutare i provider SaaS a garantire che le applicazioni tenant soddisfino i requisiti normativi, di settore e di conformità della governance per proteggere le informazioni riservate. Per altre informazioni, vedere Aggiungere un host dedicato di Azure a un cluster del servizio Azure Kubernetes .For more information, see Add Azure Dedicated Host to an servizio Azure Kubernetes cluster (AKS).

Macchine virtuali riservate

È possibile usare confidential Macchine virtuali (CVM) per aggiungere uno o più pool di nodi al cluster del servizio Azure Kubernetes per soddisfare i requisiti rigorosi di isolamento, privacy e sicurezza dei tenant. Le macchine virtuali usano un ambiente di esecuzione attendibile (TEE) basato su hardware. AMD Secure Encrypted Virtualization : le macchine virtuali riservate SEV-SNP (Secure Nested Paging) negano l'accesso all'hypervisor e ad altri codici di gestione host alla memoria e allo stato della macchina virtuale, aggiungendo un livello di protezione avanzata dall'accesso degli operatori. Per altre informazioni, vedere Usare cvm in un cluster del servizio Azure Kubernetes.

Standard FIPS (Federal Information Process Standards)

FIPS 140-3 è uno standard del governo degli Stati Uniti che definisce i requisiti minimi di sicurezza per i moduli crittografici nei prodotti e nei sistemi informatici. Abilitando la conformità FIPS per i pool di nodi del servizio Azure Kubernetes, è possibile migliorare l'isolamento, la privacy e la sicurezza dei carichi di lavoro del tenant. La conformità FIPS garantisce l'uso di moduli crittografici convalidati per la crittografia, l'hashing e altre operazioni correlate alla sicurezza. Con i pool di nodi del servizio Azure Kubernetes abilitati per FIPS, è possibile soddisfare i requisiti normativi e di conformità del settore usando algoritmi e meccanismi crittografici affidabili. Azure fornisce la documentazione su come abilitare FIPS per i pool di nodi del servizio Azure Kubernetes, consentendo di rafforzare il comportamento di sicurezza degli ambienti del servizio Azure Kubernetes multi-tenant. Per altre informazioni, vedere Abilitare FIPS per i pool di nodi del servizio Azure Kubernetes.

Bring Your Own Keys (BYOK) con dischi di Azure

Archiviazione di Azure crittografa tutti i dati in un account di archiviazione inattivi, inclusi il sistema operativo e i dischi dati di un cluster del servizio Azure Kubernetes. Per impostazione predefinita, i dati vengono crittografati con chiavi gestite da Microsoft. Per un maggiore controllo sulle chiavi di crittografia, è possibile fornire chiavi gestite dal cliente da usare per la crittografia inattivi del sistema operativo e dei dischi dati dei cluster del servizio Azure Kubernetes. Per altre informazioni, vedi:

Crittografia basata su host

La crittografia basata su host nel servizio Azure Kubernetes rafforza ulteriormente l'isolamento, la privacy e la sicurezza del carico di lavoro del tenant. Quando si abilita la crittografia basata su host, il servizio Azure Kubernetes crittografa i dati inattivi nei computer host sottostanti, assicurandosi che le informazioni sensibili del tenant siano protette da accessi non autorizzati. I dischi temporanei e i dischi del sistema operativo temporanei vengono crittografati inattivi con chiavi gestite dalla piattaforma quando si abilita la crittografia end-to-end.

Nel servizio Azure Kubernetes, il sistema operativo e i dischi dati usano la crittografia lato server con chiavi gestite dalla piattaforma per impostazione predefinita. Le cache di questi dischi vengono crittografate mentre sono inattivi con chiavi gestite dalla piattaforma. È possibile specificare la propria chiave di crittografia della chiave (KEK) per crittografare la chiave di protezione dei dati (DEK) usando la crittografia envelope, nota anche come wrapping. La cache per il sistema operativo e i dischi dati viene crittografata anche tramite il BYOK specificato.

La crittografia basata su host aggiunge un livello di sicurezza per gli ambienti multi-tenant. I dati di ogni tenant nella cache del sistema operativo e del disco dati vengono crittografati inattivi con chiavi gestite dal cliente o gestite dalla piattaforma, a seconda del tipo di crittografia del disco selezionato. Per altre informazioni, vedi:

Rete

Limitare l'accesso di rete al server API

In Kubernetes il server API riceve le richieste di esecuzione di azioni nel cluster, ad esempio la creazione di risorse o il ridimensionamento del numero di nodi. Quando si condivide un cluster del servizio Azure Kubernetes tra più team all'interno di un'organizzazione, proteggere l'accesso al piano di controllo usando una delle soluzioni seguenti.

Cluster del servizio Azure Kubernetes privati

Usando un cluster del servizio Azure Kubernetes privato, è possibile assicurarsi che il traffico di rete tra il server API e i pool di nodi rimanga all'interno della rete virtuale. In un cluster del servizio Azure Kubernetes privato, il piano di controllo o il server API ha un indirizzo IP interno accessibile solo tramite un endpoint privato di Azure, che si trova nella stessa rete virtuale del cluster del servizio Azure Kubernetes. Analogamente, qualsiasi macchina virtuale nella stessa rete virtuale può comunicare privatamente con il piano di controllo tramite l'endpoint privato. Per altre informazioni, vedere Creare un cluster privato del servizio Azure Kubernetes.

INDIRIZZI IP autorizzati

La seconda opzione per migliorare la sicurezza del cluster e ridurre al minimo gli attacchi consiste nell'usare indirizzi IP autorizzati. Questo approccio limita l'accesso al piano di controllo di un cluster del servizio Azure Kubernetes pubblico a un elenco noto di indirizzi IP (Internet Protocol) e ciDR (Classless Inter-Domain Routing). Quando si usano indirizzi IP autorizzati, vengono comunque esposti pubblicamente, ma l'accesso è limitato a un set di intervalli IP. Per altre informazioni, vedere Proteggere l'accesso al server API usando intervalli di indirizzi IP autorizzati in servizio Azure Kubernetes (servizio Azure Kubernetes).

collegamento privato di Azure Service (PLS) è un componente dell'infrastruttura che consente alle applicazioni di connettersi privatamente a un servizio tramite un endpoint privato di Azure (PE) definito in una rete virtuale e connesso alla configurazione IP front-end di un'istanza di Azure Load Balancer (ALB). Con collegamento privato di Azure, i provider di servizi possono fornire in modo sicuro i propri servizi ai tenant che possono connettersi da Azure o in locale, senza rischi di esfiltrazione dei dati.

È possibile usare collegamento privato di Azure'integrazione del servizio per fornire ai tenant la connettività privata ai carichi di lavoro ospitati dal servizio Azure Kubernetes in modo sicuro, senza la necessità di esporre alcun endpoint pubblico su Internet pubblico.

Per indicazioni generali su come configurare collegamento privato per una soluzione multi-tenant ospitata in Azure, vedere Multitenancy e collegamento privato di Azure.

Proxy inversi

Un proxy inverso è un servizio di bilanciamento del carico e un gateway API usato in genere davanti alle applicazioni tenant per proteggere, filtrare e inviare le richieste in ingresso. I proxy inversi più diffusi supportano funzionalità come il bilanciamento del carico, la terminazione SSL e il routing di livello 7. I proxy inversi vengono in genere implementati per migliorare la sicurezza, le prestazioni e l'affidabilità. I proxy inversi più diffusi per Kubernetes includono le implementazioni seguenti:

Quando si usa un proxy inverso ospitato dal servizio Azure Kubernetes per proteggere e gestire le richieste in ingresso a più applicazioni tenant, prendere in considerazione le raccomandazioni seguenti:

  • Ospitare il proxy inverso in un pool di nodi dedicato configurato per l'uso di una dimensione di macchina virtuale con una larghezza di banda di rete elevata e una rete accelerata abilitata.
  • Configurare il pool di nodi che ospita il proxy inverso per la scalabilità automatica.
  • Per evitare un aumento della latenza e dei timeout per le applicazioni tenant, definire un criterio di scalabilità automatica in modo che il numero di pod controller in ingresso possa espandersi e creare un contratto immediato in base alle fluttuazioni del traffico.
  • Prendere in considerazione il partizionamento orizzontale del traffico in ingresso verso le applicazioni tenant, tra più istanze del controller di ingresso, per aumentare il livello di scalabilità e separazione.

Quando si usa il controller di ingresso del gateway di app Azure lication, prendere in considerazione l'implementazione delle procedure consigliate seguenti:

  • Configurare il gateway applicazione usato dal controller di ingresso per la scalabilità automatica. Con la scalabilità automatica abilitata, gli SKU gateway applicazione e WAF v2 aumentano o aumentano il numero di istanze in base ai requisiti del traffico dell'applicazione. Questa modalità offre una migliore elasticità all'applicazione ed elimina la necessità di indovinare le dimensioni o il numero di istanze del gateway applicazione. Questa modalità consente anche di risparmiare sui costi, non richiedendo che il gateway venga eseguito alla capacità con provisioning massimo per il carico massimo di traffico previsto. È necessario specificare un numero minimo (e facoltativamente massimo) di istanze.
  • Valutare la possibilità di distribuire più istanze del controller di ingresso (AGIC) di gateway applicazione, ognuna associata a un gateway applicazione separato, quando il numero di applicazioni tenant supera la quantità massima di siti. Supponendo che ogni applicazione tenant venga eseguita in uno spazio dei nomi dedicato, usare il supporto di più spazi dei nomi per distribuire le applicazioni tenant in più istanze del controller di ingresso (AGIC) di gateway applicazione.

Integrazione con Frontdoor di Azure

Frontdoor di Azure è un servizio di bilanciamento del carico globale di livello 7 e la rete per la distribuzione di contenuti cloud (CDN) moderna di Microsoft che offre accesso rapido, affidabile e sicuro tra utenti e applicazioni Web in tutto il mondo. Frontdoor di Azure supporta funzionalità come accelerazione delle richieste, terminazione SSL, memorizzazione nella cache delle risposte, WAF nel perimetro, routing basato su URL, riscrittura e reindirizzamenti che è possibile sfruttare quando si espongono applicazioni multi-tenant ospitate dal servizio Azure Kubernetes alla rete Internet pubblica.

Ad esempio, è possibile usare un'applicazione multi-tenant ospitata dal servizio Azure Kubernetes per soddisfare tutte le richieste dei clienti. In questo contesto, è possibile usare Frontdoor di Azure per gestire più domini personalizzati, uno per ogni tenant. È possibile terminare le connessioni SSL sul perimetro e instradare tutto il traffico all'applicazione multi-tenant ospitata dal servizio Azure Kubernetes configurata con un singolo nome host.

Diagramma che illustra il modo in cui Frontdoor di Azure e servizio Azure Kubernetes si connettono.

È possibile configurare Frontdoor di Azure per modificare l'intestazione host dell'origine della richiesta in modo che corrisponda al nome di dominio dell'applicazione back-end. L'intestazione originale Host inviata dal client viene propagata tramite l'intestazione X-Forwarded-Host e il codice dell'applicazione multi-tenant può usare queste informazioni per eseguire il mapping della richiesta in ingresso al tenant corretto.

Web application firewall (WAF) di Azure, in Frontdoor di Azure, offre una protezione centralizzata per le applicazioni Web. È possibile usare Azure WAF per difendere le applicazioni tenant ospitate dal servizio Azure Kubernetes che espongono un endpoint pubblico su Internet da attacchi dannosi.

È possibile configurare Frontdoor di Azure Premium per connettersi privatamente a una o più applicazioni tenant eseguite in un cluster del servizio Azure Kubernetes tramite un'origine del servizio di bilanciamento del carico interno usando collegamento privato di Azure Servizio. Per altre informazioni, vedere Connettere Frontdoor di Azure Premium a un'origine del servizio di bilanciamento del carico interno con collegamento privato.

Connessioni in uscita

Quando le applicazioni ospitate dal servizio Azure Kubernetes si connettono a un numero elevato di database o servizi esterni, il cluster potrebbe essere a rischio di esaurimento delle porte SNAT. Le porte SNAT generano identificatori univoci usati per gestire flussi distinti avviati da applicazioni eseguite nello stesso set di risorse di calcolo. Eseguendo diverse applicazioni tenant in un cluster del servizio Azure Kubernetes servizio Azure Kubernetes condiviso, è possibile effettuare un numero elevato di chiamate in uscita, che possono causare un esaurimento delle porte SNAT. Un cluster del servizio Azure Kubernetes può gestire le connessioni in uscita in tre modi diversi:

  • Servizio di bilanciamento del carico pubblico di Azure: per impostazione predefinita, il servizio Azure Kubernetes effettua il provisioning di un servizio load balancer SKU Standard da configurare e usare per le connessioni in uscita. Tuttavia, l'installazione predefinita potrebbe non soddisfare i requisiti di tutti gli scenari, se gli indirizzi IP pubblici non sono consentiti o se sono necessari hop aggiuntivi per l'uscita. Per impostazione predefinita, il servizio di bilanciamento del carico pubblico viene creato con un indirizzo IP pubblico predefinito usato dalle regole in uscita. Le regole in uscita consentono di definire in modo esplicito SNAT (Source Network Address Translation) per un servizio di bilanciamento del carico standard pubblico. Questa configurazione consente di usare gli indirizzi IP pubblici del servizio di bilanciamento del carico per fornire connettività Internet in uscita per le istanze back-end. Se necessario, per evitare l'esaurimento delle porte SNAT, è possibile configurare le regole in uscita del servizio di bilanciamento del carico pubblico per l'uso di indirizzi IP pubblici aggiuntivi. Per altre informazioni, vedere Usare l'indirizzo IP front-end di un servizio di bilanciamento del carico per le regole in uscita tramite regole in uscita.
  • Gateway NAT di Azure: è possibile configurare un cluster del servizio Azure Kubernetes per l'uso del gateway NAT di Azure per instradare il traffico in uscita dalle applicazioni tenant. Il gateway NAT consente fino a 64.512 flussi di traffico UDP e TCP in uscita per ogni indirizzo IP pubblico, con un massimo di 16 indirizzi IP. Per evitare il rischio di esaurimento delle porte SNAT quando si usa un gateway NAT per gestire le connessioni in uscita da un cluster del servizio Azure Kubernetes, è possibile associare più indirizzi IP pubblici o un prefisso di indirizzo IP pubblico al gateway. Per altre informazioni, vedere Considerazioni sul gateway NAT di Azure per la multi-tenancy.
  • Route definita dall'utente: è possibile personalizzare la route in uscita di un cluster del servizio Azure Kubernetes per supportare scenari di rete personalizzati, ad esempio quelli che non consentono indirizzi IP pubblici e richiedono che il cluster si trovi dietro un'appliance virtuale di rete. Quando si configura un cluster per il routing definito dall'utente, il servizio Azure Kubernetes non configura automaticamente i percorsi in uscita. La configurazione in uscita deve essere eseguita da te. Ad esempio, si instrada il traffico in uscita attraverso un Firewall di Azure. Il cluster del servizio Azure Kubernetes deve essere distribuito in una rete virtuale esistente, con una subnet configurata in precedenza. Quando non si usa un'architettura SLB (Load Balancer Standard), è necessario stabilire un uscita esplicito. Di conseguenza, questa architettura richiede l'invio esplicito del traffico in uscita a un'appliance, ad esempio un firewall, un gateway o un proxy. In alternativa, l'architettura consente di eseguire NAT (Network Address Translation) da un indirizzo IP pubblico assegnato al servizio di bilanciamento del carico standard o all'appliance.

Monitoraggio

È possibile usare Monitoraggio di Azure e Informazioni dettagliate sui contenitori per monitorare le applicazioni tenant eseguite in un cluster del servizio Azure Kubernetes condiviso e per calcolare le suddivisioni dei costi in singoli spazi dei nomi. Monitoraggio di Azure consente di monitorare l'integrità e le prestazioni di servizio Azure Kubernetes (servizio Azure Kubernetes). Include la raccolta di log e metriche, analisi dei dati di telemetria e visualizzazioni dei dati raccolti, per identificare le tendenze e configurare gli avvisi per notificare in modo proattivo i problemi critici. È possibile abilitare Informazioni dettagliate sui contenitori per espandere questo monitoraggio.

È anche possibile adottare strumenti open source, ad esempio Prometheus e Grafana, ampiamente usati dalla community per il monitoraggio di Kubernetes. In alternativa, è possibile adottare altri strumenti di terze parti per il monitoraggio e l'osservabilità.

Costi

La governance dei costi è il processo continuo di implementazione di criteri per controllare i costi. Nel contesto di Kubernetes esistono diversi modi in cui le organizzazioni possono controllare e ottimizzare i costi. Questi includono strumenti Kubernetes nativi per gestire e gestire l'utilizzo e l'utilizzo delle risorse e per monitorare e ottimizzare in modo proattivo l'infrastruttura sottostante. Quando si calcolano i costi per tenant, è consigliabile considerare i costi associati a qualsiasi risorsa usata da un'applicazione tenant. L'approccio seguito per addebitare i costi ai tenant dipende dal modello di tenancy adottato dalla soluzione. Altri dettagli sono illustrati con i modelli di tenancy seguenti:

  • Completamente multi-tenant: quando una singola applicazione multi-tenant gestisce tutte le richieste del tenant, è responsabilità dell'utente tenere traccia dell'utilizzo delle risorse e del numero di richieste generate da ogni tenant. I clienti vengono quindi addebitati di conseguenza.
  • Cluster dedicato: quando un cluster è dedicato a un singolo tenant, è facile addebitare i costi delle risorse di Azure al cliente. Il costo totale di proprietà dipende da molti fattori, tra cui il numero e le dimensioni delle macchine virtuali, i costi di rete dovuti al traffico di rete, agli indirizzi IP pubblici, ai servizi di bilanciamento del carico, ai servizi di archiviazione, ad esempio dischi gestiti o file di Azure usati dalla soluzione tenant e così via. È possibile contrassegnare un cluster del servizio Azure Kubernetes e le relative risorse nel gruppo di risorse del nodo per facilitare le operazioni di addebito dei costi. Per altre informazioni, vedere Aggiungere tag al cluster.
  • Pool di nodi dedicato: è possibile applicare un tag di Azure a un pool di nodi nuovo o esistente dedicato a un singolo tenant. I tag applicati a un pool di nodi vengono applicati a ogni nodo all'interno del pool di nodi e vengono mantenuti tramite gli aggiornamenti. I tag vengono applicati anche ai nuovi nodi aggiunti a un pool di nodi durante le operazioni di scale-out. L'aggiunta di un tag può essere utile per attività come il rilevamento dei criteri o l'addebito dei costi. Per altre informazioni, vedere Aggiunta di tag ai pool di nodi.
  • Altre risorse: è possibile usare i tag per associare i costi delle risorse dedicate a un determinato tenant. In particolare, è possibile contrassegnare indirizzi IP, file e dischi pubblici usando un manifesto Kubernetes. I tag impostati in questo modo manterranno i valori di Kubernetes, anche se vengono aggiornati in un secondo momento usando un altro metodo. Quando gli indirizzi IP pubblici, i file o i dischi vengono rimossi tramite Kubernetes, tutti i tag impostati da Kubernetes vengono rimossi. I tag per le risorse non rilevate da Kubernetes rimangono invariati. Per altre informazioni, vedere Aggiungere tag usando Kubernetes.

È possibile usare strumenti open source, ad esempio KubeCost, per monitorare e gestire i costi di un cluster del servizio Azure Kubernetes. L'allocazione dei costi può essere limitata a una distribuzione, a un servizio, a un'etichetta, a un pod e a uno spazio dei nomi, che offrirà flessibilità nel modo in cui si esegue il chargeback o lo showback degli utenti del cluster. Per altre informazioni, vedere Governance dei costi con Kubecost.

Per altre informazioni sulla misurazione, l'allocazione e l'ottimizzazione dei costi per un'applicazione multi-tenant, vedere Approcci architetturali per la gestione dei costi e l'allocazione in una soluzione multi-tenant. Per indicazioni generali sull'ottimizzazione dei costi, vedere l'articolo Azure Well-Architected Framework( Panoramica del pilastro dell'ottimizzazione dei costi)

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autore principale:

Altri contributori:

Passaggi successivi

Vedere Risorse per architetti e sviluppatori di soluzioni multi-tenant.