Modifica

Condividi tramite

Considerazioni sul servizio Azure Kubernetes 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. Poiché il servizio Azure Kubernetes è un servizio Kubernetes ospitato, Azure gestisce attività critiche come il monitoraggio dell'integrità e la manutenzione e il piano di controllo.

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. Il termine multitenancy spesso descrive tutti questi tipi di condivisione. 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.

Questo articolo descrive alcune delle funzionalità del servizio Azure Kubernetes che è possibile usare quando si creano sistemi multi-tenant. Per indicazioni generali e procedure consigliate per la multi-tenancy kubernetes, vedere multi-tenancy nella documentazione di Kubernetes.

Tipi multi-tenancy

Il primo passaggio per determinare come condividere un cluster del servizio Azure Kubernetes in più tenant consiste nel valutare i modelli e gli strumenti disponibili per l'uso. In generale, la multi-tenancy nei cluster Kubernetes rientra in due categorie principali, ma 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, che sono ospitati nello stesso cluster o sono in esecuzione come servizi PaaS (Platform as a Service) 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 CDo 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, considerate tenant separati, per i clienti. 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 garantire 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 viene 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 che condividono istanze per cliente di un'applicazione SaaS.

La 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, un team potrebbe usare più della relativa condivisione equa di risorse. Gli amministratori possono usare quote di risorse per 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à del carico di lavoro, orchestrare le risorse del cluster in gruppi di utenti interni diversi e difendersi da possibili attacchi alla sicurezza.
  • La multi-tenancy rigida descrive gli scenari in cui i tenant eterogenei non si considerano attendibili tra loro, spesso dalle prospettive di sicurezza e condivisione delle risorse.

Quando si prevede di creare un cluster del servizio Azure Kubernetes multi-tenant, è consigliabile prendere in considerazione i livelli di isolamento delle risorse e multi-tenancy che Kubernetes fornisce, tra cui:

  • Grappolo
  • Namespace
  • Pool di nodi o nodo
  • Baccello
  • Contenitore

È anche consigliabile considerare le implicazioni per la sicurezza della condivisione di risorse diverse tra più tenant. Ad esempio, è possibile ridurre il numero di computer necessari nel cluster pianificando pod da tenant diversi nello stesso nodo. 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 potrebbero 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 di controllo degli accessi in base al ruolo di Kubernetes e criteri di rete per applicare l'isolamento del tenant. Ad esempio, il diagramma seguente mostra il tipico modello di provider SaaS che ospita più istanze della stessa applicazione nello stesso cluster, una per ogni tenant. Ogni applicazione si trova 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 il 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.

In base alla documentazione Kubernetes, un spazio dei nomi è un'astrazione usata per supportare l'isolamento dei gruppi di risorse all'interno di un singolo cluster. È possibile usare gli spazi dei nomi per isolare i carichi di lavoro del 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 dei nomi.
  • ruoli di controllo degli accessi in base al ruolo e associazioni di ruoli 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 garantire che solo le identità autorizzate abbiano accesso alle risorse in uno spazio dei nomi specifico.
  • 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 dal consumo di risorse di sistema. Questo metodo può garantire che ogni applicazione tenant in esecuzione in uno spazio dei nomi separato disponga delle risorse necessarie per l'esecuzione ed evitare problemi adiacente rumorosi, che può 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 del 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 si vuole controllare quali componenti 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 criteri di rete per separare le comunicazioni tra le applicazioni tenant che condividono lo stesso cluster.

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

  • Azure ha la sua implementazione per i criteri di rete, denominati criteri di rete di Azure.
  • i criteri di rete Calico è una soluzione di sicurezza di rete e di rete open source fondata da Tigera.

Entrambe le implementazioni usano iptable Linux 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 di filtro iptables. È 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 nel servizio Azure Kubernetes.

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

Isolamento dello spazio di archiviazione

Azure offre un set completo di repository di dati PaaS gestiti, ad esempio database SQL di Azure e Azure Cosmos DBe altri servizi di archiviazione che è possibile usare come volumi permanenti per i carichi di lavoro. Le applicazioni tenant eseguite in un cluster del servizio Azure Kubernetes condiviso possono condividere un database o un archivio fileoppure possono usare un archivio 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 nelle soluzioni multi-tenant.

I carichi di lavoro eseguiti nel 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 che Dischi di Azure, File di Azuree supporto di 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 il servizio Azure Kubernetes classi di archiviazione predefinite non sono adatte a uno o più tenant, è possibile creare classi di archiviazione personalizzate per soddisfare i requisiti dei diversi 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, vedere Usare i tag di Azure nel servizio Azure Kubernetes.

Per altre informazioni, vedere Isolamento 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 problemi di prossimità rumorosi 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 usare contenitori, tolerazioni, etichette dei nodi , selettori di nodi e affinità dei nodi per vincolare l'esecuzione dei pod dei tenant 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, tra cui:

  • A livello di kernel, eseguendo carichi di lavoro tenant in macchine virtuali (VM) leggere nei nodi dell'agente condiviso e usando Pod Sandboxing basato su Kata Containers.
  • 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, che fornisce 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), macchine virtuali riservateo crittografia basata su host.

Usare l'isolamento del nodo per 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

Il 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 compilate usando questo modello usano ampiamente 'infrastruttura come codice (IaC). Ad esempio, Bicep, Azure Resource Manager, Terraformo le API REST di Azure Resource Manager avviare e coordinare la distribuzione su richiesta delle 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 ha 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, quindi è possibile evitare di problemi di vicini rumorosi. 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. Usare la funzionalità del contratto di servizio tempo di attività per 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 potrebbe essere una soluzione migliore per i clienti con requisiti rigorosi in termini di isolamento del carico di lavoro.
  • È possibile implementare gli aggiornamenti e le modifiche progressivamente tra i tenant, riducendo la probabilità di un'interruzione a livello di sistema. I costi di Azure possono essere facilmente addebitati 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é è necessario ripetere le attività di manutenzione 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. Altre operazioni tra distribuzioni, ad esempio la creazione di report e l'analisi nell'intero ambiente, possono essere utili. 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 una sola infrastruttura per distribuire, monitorare e gestire. Tutti i tenant usano la risorsa, come illustrato nel diagramma seguente:

Diagramma che mostra tre tenant che usano 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. Queste modifiche consentono di 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 possono 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 usare il numero di richieste in sospeso o le metriche di un sistema di messaggistica esterno che usa scalabilità automatica basata su eventi basata su 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 non Microsoft, 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, può anche essere più rischioso perché 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 raggiungano i limiti di scalabilità delle risorse di Azure quando si dispone di un set condiviso di risorse. Per evitare di raggiungere un limite di quota di risorse, è possibile 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 condivide alcuni componenti della soluzione in tutti i tenant e distribuisce 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 usa un database dedicato e una singola applicazione Kubernetes condivisa.

vantaggi :

  • Le distribuzioni partizionate orizzontalmente consentono di ridurre problemi vicini rumorosi. Si consideri questo approccio se si identifica 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 e i componenti condivisi di altri tenant, 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 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. È anche 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 che offrono 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 e 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 che ospitano l'applicazione tenant. È possibile usare Pod Sandboxing come soluzione alternativa a 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.

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 99,9% tempo di attività, il livello standard può offrire 99,95% tempo di attività e il livello Premium può offrire un tempo di attività di 99,99%. È possibile implementare il contratto di servizio superiore usando servizi e funzionalità che consentono destinazioni di disponibilità più elevate.

vantaggi :

  • Poiché l'infrastruttura è ancora condivisa, è comunque possibile ottenere alcuni dei vantaggi dei costi 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 meno costose 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, Konnectivityo controller di ingresso del gateway applicazione di Azure, in un pool di nodi dedicato in modalità sistema. È possibile usare contenitori, tolerazioni, etichette dei nodi , selettori di nodi e affini tà dei nodi per eseguire un'applicazione tenant in uno o più pool di nodi in modalità utente.
  • È possibile usare contenitori, tolerazioni, etichette dei nodi , selettori di nodi e affinità dei nodi per eseguire le risorse condivise. Ad esempio, è possibile avere un controller di ingresso o un sistema di messaggistica in un pool di nodi dedicato con dimensioni specifiche della macchina virtuale, 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, o 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 di scalabilità automatica del cluster per ridimensionare i nodi agente del 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 più disponibili a causa di interruzioni di una zona di disponibilità.

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, il ridimensionamento automatico del cluster aggiunge nuovi nodi agente per impedire ai pod di passare a uno stato in sospeso a causa di carenza di risorse come CPU e memoria.

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, riducendo i costi operativi.

È possibile usare la scalabilità automatica dei pod per ridimensionare automaticamente i pod in base alle esigenze delle risorse. HorizontalPodAutoscaler ridimensiona automaticamente il numero di repliche pod in base all'utilizzo della CPU o della memoria o alle metriche personalizzate. Usando KEDA, è possibile ridimensionare qualsiasi contenitore in Kubernetes in base al numero di eventi provenienti da sistemi esterni, ad esempio Hub eventi di Azure o bus di servizio di Azure, usate dalle applicazioni tenant.

la scalabilità automatica verticale dei pod (VPA) consente una gestione efficiente delle risorse per i pod. Modificando la CPU e la memoria allocata ai pod, vpa consente di ridurre il numero di nodi necessari per eseguire le applicazioni tenant. La presenza di un numero inferiore di nodi riduce il costo totale di proprietà e consente di evitare problemi del vicino rumoroso.

Assegnare gruppi di prenotazioni di capacità ai pool di nodi per offrire un migliore isolamento e allocazione delle risorse per tenant diversi.

Manutenzione

Per ridurre il rischio di tempi di inattività che potrebbero influire sulle applicazioni tenant durante gli aggiornamenti del cluster o del pool di nodi, pianificare il servizio Azure Kubernetes manutenzione pianificata durante gli orari di minore attività. 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 per ridurre al minimo l'impatto sul 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 vengono eseguite durante le finestre pianificate.

Sicurezza

Le sezioni seguenti descrivono le procedure consigliate per la sicurezza per le soluzioni multi-tenant con il servizio Azure Kubernetes.

Accesso al cluster

Quando si condivide un cluster del servizio Azure Kubernetes tra più team all'interno di un'organizzazione, è necessario implementare il principio 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 come kubectl, Helm, Fluxo Argo CD.

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 ogni applicazione si trova in uno spazio dei nomi separato, ogni carico di lavoro deve usare un account del servizio Kubernetes diverso e le credenziali per accedere ai servizi downstream di Azure. Gli account del servizio sono uno dei tipi di utente principali in Kubernetes. L'API Kubernetes contiene e gestisce gli account del servizio. Le credenziali dell'account del servizio vengono archiviate come segreti Kubernetes, in modo che i pod autorizzati possano usarle per comunicare con il server API. La maggior parte delle richieste API fornisce 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 del carico di lavoro Microsoft Entra per Kubernetes si integra con le funzionalità native di Kubernetes per la federazione con qualsiasi provider di identità esterno.

Pod Sandboxing

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).

Distribuendo applicazioni in cluster o pool di nodi separati, è possibile isolare fortemente i carichi di lavoro del 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, è possibile usare un singolo cluster quando si eseguono pod non attendibili e attendibili nello stesso nodo o si concatenano DaemonSet e contenitori con privilegi nello stesso nodo per una comunicazione locale e un raggruppamento funzionale più veloci. 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.

Il sandboxing dei pod nel servizio Azure Kubernetes si basa su contenitori Kata eseguiti nell'host contenitore Linux di Azure per lo stack di 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. Ottiene l'isolamento per ogni pod tramite una macchina virtuale Kata annidata e leggera 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. Usare questo modello per inserire molti contenitori Kata in una singola macchina virtuale guest, continuando a eseguire i contenitori nella macchina virtuale padre. Questo modello fornisce un limite di isolamento sicuro in un cluster del servizio Azure Kubernetes condiviso.

Per altre informazioni, vedere:

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.

L'uso di host dedicato di Azure con il servizio Azure Kubernetes offre diversi vantaggi, tra cui:

  • L'isolamento hardware garantisce che nessun'altra macchina virtuale venga inserita 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.

Karpenter

Karpenter è un progetto di gestione del ciclo di vita dei nodi open source creato per Kubernetes. L'aggiunta di Karpenter a un cluster Kubernetes può migliorare l'efficienza e i costi di esecuzione dei carichi di lavoro in tale cluster. Karpenter controlla i pod che l'utilità di pianificazione kubernetes contrassegna come non pianificabile. Esegue anche il provisioning e la gestione dinamica dei nodi che possono soddisfare i requisiti del pod.

Karpenter offre un controllo granulare sul provisioning dei nodi e sul posizionamento del carico di lavoro in un cluster gestito. Questo controllo migliora la multi-tenancy ottimizzando l'allocazione delle risorse, garantendo l'isolamento tra le applicazioni di ogni tenant e riducendo i costi operativi. Quando si compila una soluzione multi-tenant nel servizio Azure Kubernetes, Karpenter offre funzionalità utili per gestire requisiti applicativi diversi per supportare tenant diversi. Ad esempio, potrebbe essere necessario che alcune applicazioni dei tenant vengano eseguite in pool di nodi ottimizzati per GPU e altri per l'esecuzione in pool di nodi ottimizzati per la memoria. Se l'applicazione richiede una bassa latenza per l'archiviazione, è possibile usare Karpenter per indicare che un pod richiede un nodo che viene eseguito in una zona di disponibilità specifica in modo che sia possibile condividere il livello di archiviazione e applicazione.

Il servizio Azure Kubernetes abilita il provisioning automatico dei nodi nei cluster del servizio Azure Kubernetes tramite Karpenter. La maggior parte degli utenti deve usare la modalità di provisioning automatico del nodo per abilitare Karpenter come componente aggiuntivo gestito. Per altre informazioni, vedere Il provisioning automatico di Node. Se è necessaria una personalizzazione più avanzata, è possibile scegliere di ospitare autonomamente Karpenter. Per altre informazioni, vedere il provider karpenter del servizio Azure Kubernetes .

Macchine virtuali riservate

È possibile usare macchine virtuali riservate 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. macchine virtuali riservate usare un ambiente di esecuzione attendibile basato su hardware. AMD Secure Encrypted Virtualization - Secure Nested Paging (SEV-SNP) le macchine virtuali riservate negano l'hypervisor e altri accessi del codice di gestione host alla memoria e allo stato della macchina virtuale, che aggiunge un livello di difesa e protezione avanzata dall'accesso degli operatori. Per altre informazioni, vedere Usare macchine virtuali riservate 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 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. 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, che consente 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, vedere:

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 riservate del tenant siano protette da accessi non autorizzati. I dischi temporanei e i dischi temporanei del sistema operativo 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 per questi dischi vengono crittografate inattive con chiavi gestite dalla piattaforma. È possibile specificare la propria chiave di crittografia della chiave di per crittografare la chiave di protezione dei dati 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, vedere:

Networking

Le sezioni seguenti descrivono le procedure consigliate per la rete per le soluzioni multi-tenant con il servizio Azure Kubernetes.

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 del servizio Azure Kubernetes privato.

Intervalli di indirizzi IP autorizzati

La seconda opzione per migliorare la sicurezza del cluster e ridurre al minimo gli attacchi consiste nell'usare intervalli di 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 e intervalli CIDR (Classless Inter-Domain Routing). Quando si usano indirizzi IP autorizzati, vengono comunque esposti pubblicamente, ma l'accesso è limitato a un set di intervalli. Per altre informazioni, vedere Proteggere l'accesso al server API usando intervalli di indirizzi IP autorizzati nel servizio Azure Kubernetes.

servizio collegamento privato di Azure è un componente dell'infrastruttura che consente alle applicazioni di connettersi privatamente a un servizio tramite un endpoint privato di Azure definito in una rete virtuale e connesso alla configurazione IP front-end di un'istanza di Azure Load Balancer . Con collegamento privato, 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 integrazione del servizio Collegamento privato per fornire ai tenant connettività privata ai carichi di lavoro ospitati nel servizio Azure Kubernetes in modo sicuro, senza dover esporre alcun endpoint pubblico sulla rete Internet pubblica.

Per altre informazioni su come configurare il collegamento privato per una soluzione multi-tenant ospitata in Azure, vedere Multitenancy e Collegamento privato.

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:

  • controller di ingresso NGINX è un server proxy inverso diffuso che supporta funzionalità avanzate, ad esempio bilanciamento del carico, terminazione SSL e routing di livello 7.
  • provider di ingresso Kubefik Kubernetes è un controller di ingresso Kubernetes che può essere usato per gestire l'accesso ai servizi cluster supportando la specifica in ingresso.
  • controller di ingresso kubernetes HAProxy kubernetes è ancora un altro proxy inverso per Kubernetes, che supporta funzionalità standard come la terminazione TLS, il routing basato sul percorso URL e altro ancora.
  • del controller di ingresso del gateway applicazione di Azure è un'applicazione Kubernetes, che consente ai clienti del servizio Azure Kubernetes di usare un gateway applicazione nativo di Azure L7 per esporre le applicazioni tenant a Internet pubblico o internamente ad altri sistemi eseguiti in una rete virtuale.

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 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 ilcontroller di ingresso del gateway applicazione di Azure , è consigliabile implementare le procedure consigliate seguenti:

  • Configurare il gateway applicazione usato dal controller di ingresso per la scalabilità automatica. Con la scalabilità automatica abilitata, gli SKU del gateway applicazione e del web application firewall (WAF) v2 aumentano o in, in base ai requisiti del traffico dell'applicazione. Questa modalità offre una migliore elasticità all'applicazione ed elimina la necessità di indovinare le dimensioni del gateway applicazione o il numero di istanze. Questa modalità consente anche di risparmiare sui costi non richiedendo che il gateway venga eseguito con 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 delAGIC , 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 più spazi dei nomi per distribuire le applicazioni tenant in più istanze del AGIC.

Integrazione con Frontdoor di Azure

frontdoor di Azure è un servizio di bilanciamento del carico globale di livello 7 e una rete di distribuzione di contenuti cloud moderna (CDN) di Microsoft che offre accesso rapido, affidabile e sicuro tra utenti e applicazioni Web in tutto il mondo. Frontdoor di Azure supporta funzionalità come l'accelerazione delle richieste, la terminazione SSL, la memorizzazione nella cache delle risposte, il WAF nella rete perimetrale, il routing basato su URL, la riscrittura e i reindirizzamenti che è possibile usare 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 dell'host di origine della richiesta in modo che corrisponda al nome di dominio dell'applicazione back-end. L'intestazione Host originale 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 di Azure, in Frontdoor di Azure, offre una protezione centralizzata per le applicazioni Web. Web application firewall di Azure consente di 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. 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 (Network Address Translation) di origine. porte SNAT generare identificatori univoci usati per mantenere flussi distinti avviati dalle applicazioni eseguite nello stesso set di risorse di calcolo. Eseguendo diverse applicazioni tenant in un cluster del 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:

  • Azure Load Balancer: per impostazione predefinita, il servizio Azure Kubernetes effettua il provisioning di un servizio di bilanciamento del carico standard per la configurazione e l'uso 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 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. Quando necessario, per evitare esaurimento delle porte SNAT, è possibile configurare le regole in uscita del servizio di bilanciamento del carico pubblico per usare più indirizzi IP pubblici. Per altre informazioni, vedere Usare l'indirizzo IP front-end di un servizio di bilanciamento del carico per le 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 (UDR): è 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 routing definito dall'utente, il servizio Azure Kubernetes non configura automaticamente i percorsi in uscita. È necessario completare la configurazione in uscita. Ad esempio, si instrada il traffico in uscita attraverso un Firewall di Azure. È necessario distribuire il cluster del servizio Azure Kubernetes in una rete virtuale esistente con una subnet configurata in precedenza. Quando non si usa un'architettura di bilanciamento del carico 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. Usare Monitoraggio di Azure per monitorare l'integrità e le prestazioni del servizio Azure Kubernetes. Include la raccolta di log e metriche di , l'analisi dei dati di telemetria e le visualizzazioni dei dati raccolti per identificare le tendenze e configurare gli avvisi che notificano in modo proattivo i problemi critici. È possibile abilitare informazioni dettagliate sui contenitori per espandersi su questo monitoraggio.

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

Costi

La governance dei costi è il processo continuo di implementazione dei criteri per controllare i costi. Nel contesto Kubernetes esistono diversi metodi che le organizzazioni possono usare per controllare e ottimizzare i costi. Questi metodi includono l'uso di 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, è necessario 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. L'elenco seguente descrive in modo più dettagliato i modelli di tenancy:

  • 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 del traffico di rete, gli indirizzi IP pubblici, i servizi di bilanciamento del carico e i servizi di archiviazione, ad esempio dischi gestiti o file di Azure usati dalla soluzione tenant. È 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 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 scalabilità orizzontale. 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 pubblici, file e dischi usando un manifesto Kubernetes. I tag impostati in questo modo mantengono 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 sulle risorse che Kubernetes non rilevano rimangono interessati. Per altre informazioni, vedere Aggiungere tag usando Kubernetes.

È possibile usare strumenti open source, ad esempio KubeCost, per monitorare e gestire il costo di un cluster del servizio Azure Kubernetes. È possibile definire l'ambito dell'allocazione dei costi a una distribuzione, a un servizio, a un'etichetta, a un pod e a uno spazio dei nomi, che offre flessibilità nel modo in cui si esegue il chargeback o visualizzare gli 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 Ottimizzazione costi.

Governance

Quando più tenant condividono la stessa infrastruttura, la gestione della privacy dei dati, la conformità e i requisiti normativi possono diventare complicati. È necessario implementare misure di sicurezza avanzate e criteri di governance dei dati. I cluster del servizio Azure Kubernetes condivisi presentano un rischio maggiore di violazioni dei dati, accesso non autorizzato e non conformità alle normative sulla protezione dei dati. Ogni tenant potrebbe avere requisiti di governance dei dati e criteri di conformità univoci, che rendono difficile garantire la sicurezza e la privacy dei dati.

microsoft Defender per contenitori è una soluzione di sicurezza dei contenitori nativa del cloud che fornisce funzionalità di rilevamento e protezione delle minacce per gli ambienti Kubernetes. Usando Defender per contenitori, è possibile migliorare il comportamento di governance e conformità dei dati quando si ospitano più tenant in un cluster Kubernetes. Usare Defender per contenitori per proteggere i dati sensibili, rilevare e rispondere alle minacce analizzando il comportamento dei contenitori e il traffico di rete e soddisfare i requisiti normativi. Offre funzionalità di controllo, gestione dei log e generazione di report per dimostrare la conformità ai revisori e alle autorità di regolamentazione.

Contributori

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

Autore principale:

Altri collaboratori: