Usare Application Gateway for Containers con un cluster di servizio Azure Kubernetes multitenant

Questa soluzione utilizza Application Gateway for Containers come ingress condiviso per un cluster multi-tenant di Servizio Azure Kubernetes (AKS). Web application firewall di Azure fornisce protezione centralizzata da exploit Web comuni.

Application Gateway for Containers è una risorsa di Azure a tenant singolo. Un'istanza ha un proprietario e una superficie di configurazione. La multi-tenancy in questa architettura risiede all'interno del cluster AKS. Ogni tenant ha un proprio spazio dei nomi, le proprie risorse gateway Kubernetes e HTTPRoute e il proprio certificato TLS (Transport Layer Security). Una sola istanza di Application Gateway for Containers li serve tutti. Il team della piattaforma mantiene la sola proprietà della risorsa Azure sottostante. I tenant non devono accedervi per gestire il proprio routing.

È possibile associare un criterio WAF ad Application Gateway for Containers per contribuire a proteggere le applicazioni Web da attacchi dannosi, ad esempio l'iniezione SQL e il cross-site scripting. Questo approccio protegge le applicazioni web in esecuzione in un AKS cluster ed esposte tramite Application Gateway for Containers. Il criterio WAF usa il set di regole predefinito (DRS) 2.1 e supporta regole personalizzate.

Architettura

Scaricare un file di Visio di questa architettura.

Flusso di lavoro

• Questa architettura usa un modello di Azure Resource Manager complementare per distribuire una nuova rete virtuale con quattro subnet:

  • AksSubnet ospita il cluster AKS.

  • VmSubnet ospita endpoint privati e, facoltativamente, una macchina virtuale dell'operatore per le attività di amministrazione del cluster che richiedono strumenti locali.

  • AppGatewaySubnet ospita la subnet delegata di Application Gateway for Containers. Questa subnet richiede la delega Microsoft.ServiceNetworking/trafficControllers e uno spazio di indirizzi /24 o maggiore (almeno 256 indirizzi disponibili).

  • AzureBastionSubnet ospita Azure Bastion.

• Il cluster AKS utilizza un'identità gestita definita dall'utente per creare ulteriori risorse in Azure, come bilanciatori di carico e dischi gestiti. È possibile usare il modello ARM per distribuire un cluster AKS con le funzionalità seguenti:

  • Driver CSI (Container Storage Interface) per dischi di Azure e File di Azure
  • Integrazione di Microsoft Entra gestita da AKS
  • Controllo degli accessi basato sui ruoli di Azure per l'autorizzazione di Kubernetes
  • Identità gestita al posto di un'entità servizio
  • ID dei carichi di lavoro di Microsoft Entra
  • Criteri di rete di Azure
  • componente aggiuntivo di Monitoraggio di Azure Container Insights
  • Supporto del componente aggiuntivo AKS per Application Gateway for Containers
  • Allocazione dinamica di indirizzi IP e supporto avanzato della subnet

• Il cluster AKS ha i seguenti pool di nodi:

  • Il pool di nodi di sistema ospita solo pod e servizi di sistema critici. I nodi di lavoro hanno taint dei nodi che impediscono che i pod dell'applicazione vengano pianificati in questo pool di nodi.

  • Il pool di nodi utente ospita carichi di lavoro e artefatti utente.

• Una macchina virtuale viene distribuita nella stessa rete virtuale che ospita il cluster del servizio Azure Kubernetes. Quando si distribuisce AKS come cluster privato, gli amministratori di sistema possono usare questa macchina virtuale per gestire il cluster tramite lo strumento da riga di comando di Kubernetes. I log di diagnostica di avvio della macchina virtuale vengono archiviati in un account Archiviazione di Azure.

• Azure Bastion connette gli amministratori direttamente al server API del cluster AKS privato tramite l'integrazione nativa dei cluster AKS privati. Questo approccio elimina la necessità di un jump box dedicato nella maggior parte degli scenari. Quando gli operatori richiedono una workstation con strumenti come kubectl o Helm installati, è possibile connettersi a una macchina virtuale facoltativa in VmSubnet tramite Azure Bastion. Questa soluzione utilizza Registro Azure Container per compilare, archiviare e gestire immagini e artefatti dei container, ad esempio chart Helm.

• Questa architettura include Application Gateway for Containers. Application Gateway for Containers viene distribuito in una subnet dedicata ed esposto a Internet pubblica tramite un indirizzo IP pubblico condiviso da tutti i carichi di lavoro del tenant. Un criterio WAF protegge i carichi di lavoro del tenant da attacchi dannosi.

  WAF per Application Gateway for Containers si configura tramite una risorsa di criteri di sicurezza, che corrisponde a un criterio di Web application firewall di Azure. È possibile configurare i criteri in modalità di prevenzione con DRS 2.1 per bloccare intrusioni e attacchi rilevati dalle regole. L'utente malintenzionato riceve una risposta 403 Non consentito e la connessione viene chiusa. La modalità di prevenzione registra questi attacchi nei log di WAF.

• I carichi di lavoro eseguiti su AKS utilizzano un Key Vault come archivio segreto per recuperare chiavi, certificati e segreti tramite una libreria client, il Secrets Store CSI Driver, o Dapr. collegamento privato di Azure consente ai carichi di lavoro di AKS accedere alle soluzioni PaaS (Piattaforma come servizio), ad esempio Azure Key Vault, tramite un endpoint privato nella rete virtuale.

• Questa architettura include endpoint privati per i componenti seguenti:

  • L'account di archiviazione di Azure Blob
  • Container Registry
  • Key Vault
  • Il server API del cluster Kubernetes, se si utilizza un cluster privato di Azure Kubernetes Service (AKS)

• L'architettura include anche zone DNS (Domain Name System) private per risolvere il nome di dominio completo (FQDN) di un servizio PaaS nell'indirizzo IP privato dell'endpoint privato associato. Questa architettura comprende zone DNS private che risolvono gli endpoint privati ai seguenti componenti:

  • Account di archiviazione Blob
  • Container Registry
  • Key Vault
  • API del server Kubernetes, se si distribuisce il cluster come privato

• Esiste un collegamento di rete virtuale tra la rete virtuale che ospita il cluster AKS e le zone DNS private collegate. Un'area di lavoro Log Analytics raccoglie i log di diagnostica e le metriche dalle origini seguenti:

  • Cluster AKS
  • La VM facoltativa dell’operatore, se distribuita
  • Gateway applicazione per contenitori
  • Key Vault
  • Azure gruppi di sicurezza di rete

Components

• Container Registry è un servizio di registro Docker gestito e privato basato sulla registrazione open source Docker Registry 2.0. È possibile usare i registri contenitori di Azure con le pipeline di sviluppo e distribuzione di contenitori esistenti. In alternativa, è possibile usare le attività del Registro Container per compilare immagini del contenitore in Azure. È possibile compilare immagini del contenitore su richiesta o automatizzare completamente le compilazioni con trigger, ad esempio i commit del codice sorgente e gli aggiornamenti delle immagini di base. In questa architettura, Container Registry archivia e gestisce immagini e artefatti di contenitore, come i chart Helm, per la distribuzione nel cluster AKS.

• AKS è un servizio Kubernetes gestito che semplifica la distribuzione di un cluster Kubernetes in Azure delegando ad Azure il carico operativo. In qualità di servizio Kubernetes gestito, Azure gestisce attività critiche, come il monitoraggio dello stato e la manutenzione. Azure gestisce i nodi del piano di controllo Kubernetes, così sei responsabile solo della gestione e manutenzione dei nodi dell'agente. In questa architettura, AKS ospita i carichi di lavoro multitenant in namespace separati, con pool di nodi di sistema e utente che isolano i servizi di sistema critici dalle applicazioni dei tenant.

• Key Vault è un servizio cloud che archivia e controlla in modo sicuro l'accesso ai segreti, ad esempio chiavi API, password e chiavi crittografiche. I carichi di lavoro in AKS possono recuperare i segreti di Key Vault usando il Secrets Store CSI Driver o Dapr. In questa architettura, Key Vault fornisce un archivio centralizzato dei segreti a cui accedono i carichi di lavoro tramite un endpoint privato utilizzando Secrets Store CSI Driver o Dapr.

  Note

  Application Gateway for Containers non supporta l'integrazione dei certificati di Key Vault. Archiviare i certificati per Application Gateway per i container come segreti di Kubernetes.

• Gateway applicazione per contenitori è una soluzione di bilanciamento del carico e di ingresso di livello 7 gestita da Azure per AKS. È costituito da una risorsa Gateway applicazione per contenitori gestita da Azure e dal controller del bilanciamento del carico dell'applicazione. Il controller di Application Load Balancer è un componente del cluster che monitora le risorse Kubernetes Gateway API e Ingress e configura Application Gateway for Containers di conseguenza. Il traffico viene elaborato a livello di rete di Azure, all'esterno del pool di nodi di AKS, quindi la capacità di ingresso si dimensiona in modo indipendente dai nodi del cluster. Application Gateway per contenitori supporta il routing tra namespace multipli, la terminazione SSL/TLS, l'affinità di sessione e l'integrazione con WAF tramite risorse dei criteri di sicurezza. In questa architettura, Application Gateway for Containers offre un ingresso condiviso per i carichi di lavoro di tutti i tenant e instrada il traffico al namespace appropriato in base alle risorse Gateway e HTTPRoute.

• Web application firewall (WAF) in Application Gateway for Containers è una funzionalità WAF che fornisce una protezione centralizzata delle applicazioni Web ospitate in AKS da vulnerabilità ed exploit comuni. WAF viene fornito tramite una risorsa criterio di sicurezza di Application Gateway for Containers associata a un Gateway o a un HTTPRoute. Utilizza regole del OWASP Core Rule Set (CRS) e supporta regole personalizzate che vengono valutate per ogni richiesta. In questa architettura, WAF applica le regole DRS 2.1 in base alla route specifica a tutti i workload dei tenant tramite una risorsa dei criteri di sicurezza associata ad Application Gateway for Containers.

• Azure Bastion è un paaS completamente gestito di cui si effettua il provisioning all'interno della rete virtuale. Azure Bastion fornisce connettività RDP (Desktop remoto Protocol) e SSH alle macchine virtuali nella rete virtuale, direttamente dal portale di Azure tramite TLS. In questa architettura, Azure Bastion fornisce un accesso amministrativo sicuro al server API del cluster AKS privato e alla VM facoltativa dell’operatore, senza esporli a Internet pubblico.

• Macchine virtuali di Azure è un'offerta IaaS (Infrastructure as a Service) che offre risorse di calcolo su richiesta e scalabili che offrono la flessibilità di virtualizzazione senza che sia necessario acquistare e gestire l'hardware fisico. In questa architettura, una macchina virtuale facoltativa funge da workstation operatore per le attività di amministrazione del cluster che richiedono strumenti locali, ad esempio kubectl o Helm.

• Rete virtuale di Azure è il blocco fondamentale per le reti private di Azure. Con Rete virtuale, Azure risorse, ad esempio macchine virtuali, possono comunicare tra loro, Internet e reti locali. Una rete virtuale Azure è simile a una rete locale tradizionale, ma include Azure vantaggi dell'infrastruttura, ad esempio scalabilità, disponibilità e isolamento. In questa architettura, la rete virtuale fornisce isolamento e connettività di rete per il cluster AKS, Application Gateway for Containers, gli endpoint privati e l'infrastruttura di supporto in subnet dedicate.

• Le interfacce di rete virtuale sono schede di rete che stabiliscono la comunicazione tra macchine virtuali Azure e Internet, Azure e risorse locali. È possibile aggiungere diverse NIC a una VM di Azure in modo che le VM figlio possano avere dispositivi di interfaccia di rete e indirizzi IP dedicati. In questa architettura le interfacce di rete connettono la macchina virtuale dell'operatore facoltativa alla rete virtuale per le operazioni di gestione del cluster.

• I dischi gestiti di Azure sono volumi di archiviazione a livello di blocco gestiti da Azure nelle macchine virtuali di Azure. I tipi di disco includono Azure Ultra protezione del contenuto, Azure SSD Premium e Azure SSD Standard. In questa architettura, i dischi gestiti forniscono l'archiviazione persistente per la VM operatore facoltativa e per le VM del pool di nodi di AKS.

• gestione rete virtuale di Azure è una soluzione di archiviazione oggetti Microsoft per il cloud. gestione rete virtuale di Azure è ottimizzato per l'archiviazione di grandi quantità di dati non strutturati. I dati non strutturati sono dati che non rispettano un modello di dati o una definizione specifici, ad esempio dati di testo o dati binari. In questa architettura gestione rete virtuale di Azure archivia i log di diagnostica di avvio per la macchina virtuale dell'operatore facoltativo.

• collegamento privato è un servizio di rete Azure che fornisce un endpoint privato nella rete virtuale in modo che sia possibile accedere ai servizi PaaS Azure, ad esempio gestione rete virtuale di Azure e Key Vault e accedere ai servizi Azure ospitati, di proprietà del cliente o dei partner. In questa architettura, collegamento privato fornisce una connettività privata e sicura dal cluster AKS ad Azure Container Registry, Key Vault e gestione rete virtuale di Azure senza transitare attraverso la rete Internet pubblica.

Come funziona Application Gateway for Containers

Questa architettura utilizza Application Gateway for Containers. Quando si crea un nuovo cluster AKS o una nuova distribuzione di Application Gateway for Containers, è possibile installare il componente aggiuntivo AKS di Application Gateway for Containers usando l'interfaccia della riga di comando di Azure. È anche possibile installare il controller di bilanciamento del carico dell'applicazione usando Helm.

Application Gateway per contenitori supporta due modelli di gestione per le proprie risorse di Azure: bring-your-own (BYO) e gestito dal controller di Application Load Balancer.

• Nel modello BYO, le risorse di Azure Application Gateway for Containers vengono create e gestite direttamente in Azure utilizzando strumenti come Bicep, Terraform o il portale di Azure. È quindi possibile fare riferimento a queste risorse da Kubernetes usando i relativi ID risorsa.

• Nel modello gestito dal controller di bilanciamento del carico dell'applicazione le risorse Kubernetes determinano il ciclo di vita delle risorse Azure. Ogni ApplicationLoadBalancer risorsa personalizzata esegue il provisioning della propria risorsa di Azure Application Gateway for Containers. La creazione, l'eliminazione e gli aggiornamenti di tale Azure risorsa sono basati interamente sulla configurazione di Kubernetes.

Il controller del bilanciatore del carico dell'applicazione viene distribuito nel cluster AKS e gestisce la risorsa Application Gateway for Containers in Azure. Application Gateway per i contenitori supporta sia l'API Ingress di Kubernetes sia la Gateway API. Le funzionalità principali includono:

• Supporto per l'API Gateway di Kubernetes: Application Gateway for Containers implementa la specifica Gateway API. Questa specifica consente il routing tra spazi dei nomi e la separazione della configurazione basata sui ruoli tra gli operatori dell'infrastruttura e gli sviluppatori di applicazioni.

• Piano dati gestito da Azure: L'elaborazione del traffico avviene nell'infrastruttura gestita da Azure, esterna al pool di nodi di AKS, quindi la capacità di ingresso viene scalata indipendentemente dai nodi del cluster.

• Instradamento tra più namespace: Una singola distribuzione di Application Gateway for Containers instrada il traffico tra più namespace Kubernetes, con l'accesso tra namespace controllato tramite le risorse ReferenceGrant.

• Integrazione WAF: Application Gateway for Containers si integra con Web application firewall di Azure tramite le risorse dei criteri di sicurezza, offrendo una protezione basata su DRS 2.1 e il supporto per regole personalizzate.

Le alternative

Quando si espongono carichi di lavoro ospitati in un cluster del servizio Azure Kubernetes, sono disponibili diverse soluzioni da considerare. È anche possibile usare l'API del gateway Kubernetes con il componente aggiuntivo di routing dell'applicazione come alternativa. Queste soluzioni offrono funzionalità diverse per gestire e proteggere il traffico verso il cluster AKS.

Dettagli dello scenario

Questa architettura condivide un cluster Kubernetes multi-tenant tra più utenti e carichi di lavoro comunemente definiti tenant. Questa definizione include team o divisioni diversi all'interno di un'organizzazione che condividono cluster Kubernetes. Include anche cluster che condividono le 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, un team potrebbe usare più risorse di quelle necessarie. Gli amministratori possono usare le quote di risorse per risolvere questo problema.

Quando si pianifica di creare un cluster AKS multi-tenant, è consigliabile prendere in considerazione i livelli di isolamento delle risorse forniti da Kubernetes, tra cui cluster, namespace, nodo, pod e isolamento dei contenitori. È anche necessario considerare le implicazioni per la sicurezza che derivano dalla condivisione di diversi tipi di risorse tra più tenant. Ad esempio, se si pianificano pod da tenant diversi nello stesso nodo, è possibile ridurre il numero di computer necessari nel cluster. Tuttavia, potrebbe essere necessario impedire che determinati carichi di lavoro vengano raggruppati. Ad esempio, potrebbe non consentire l'esecuzione di codice non attendibile dall'esterno dell'organizzazione nello stesso nodo dei contenitori che elaborano informazioni riservate. Puoi usare Criteri di Azure affinché solo i registri attendibili possano eseguire distribuzioni su AKS.

Kubernetes non isola completamente i tenant l'uno dall'altro, ma fornisce funzionalità di isolamento che soddisfano i requisiti comuni di multi-tenancy. Come procedura consigliata, è opportuno separare ogni tenant e le relative risorse Kubernetes nei rispettivi spazi dei nomi. È quindi possibile usare Kubernetes RBAC e network policies per contribuire a imporre l'isolamento dei tenant. In un modello di provider SaaS tipico, il cluster ospita più istanze della stessa applicazione, una per tenant, con ogni applicazione in uno spazio dei nomi separato. Quando i tenant necessitano di un livello superiore di isolamento fisico e prestazioni prevedibili, i carichi di lavoro possono essere distribuiti in un set dedicato di nodi, un pool dedicato o un cluster dedicato.

Application Gateway for Containers è una soluzione di bilanciamento del carico e gestione dell'ingress gestita da Azure per AKS. È costituito da una risorsa Application Gateway for Containers gestita da Azure e dal controller dell'utilità di bilanciamento del carico dell'applicazione, che viene eseguito come deployment nel cluster AKS. Il controller di Application Load Balancer monitora le risorse Kubernetes Ingress e Gateway API alla ricerca di modifiche e traduce lo stato del cluster nella configurazione di Application Gateway for Containers. Questa architettura descrive le best practice comprovate per distribuire un cluster AKS pubblico o privato con Application Gateway for Containers.

La multi-tenancy in questa architettura risiede all'interno del cluster AKS. Application Gateway for Containers è una risorsa di Azure a tenant singolo, quindi un'istanza ha un solo proprietario e un'unica interfaccia di configurazione. Il confine multi-tenant si trova nel cluster, che include namespace, HTTPRoutes e carichi di lavoro dei tenant. Una singola istanza di Application Gateway for Containers fornisce un ingress condiviso per tutti i contenitori. Un singolo controller dell'Application Load Balancer può acquisire eventi da più namespace Kubernetes. Questa funzionalità di Application Gateway for Containers è ciò che consente questo modello.

Casi d'uso potenziali

Application Gateway for Containers è particolarmente adatto ai cluster AKS multitenant per diversi motivi:

• Isolamento per namespace tramite l'API Gateway di Kubernetes: Le risorse Gateway e HTTPRoute di ogni tenant risiedono nel namespace del tenant stesso. L'ingress condiviso usa ReferenceGrant per controllare l'accesso tra namespace. Questa risorsa Kubernetes garantisce che i tenant non possano indirizzare accidentalmente il traffico verso i servizi degli altri tenant.

• TLS per tenant senza materiale crittografico condiviso: Ogni tenant fornisce il proprio certificato come secret Kubernetes nel proprio namespace, quindi i tenant non condividono chiavi private e possono rinnovare i propri certificati in modo indipendente.

• RBAC con ambito namespace per il self-service: I tenant possono gestire le proprie risorse Gateway, HTTPRoute e secret dei certificati nei rispettivi namespace senza dover accedere alla risorsa Azure Application Gateway for Containers condivisa, di proprietà del team della piattaforma.

• Ingress condiviso con nomi host o percorsi per tenant: Un singolo front-end di Application Gateway for Containers può ospitare molti domini dei tenant o prefissi di percorso, mantenendo basso il costo base per tenant e rendendo gestibili, per il team della piattaforma, l'indirizzo IP pubblico e la superficie DNS.

• Criteri WAF per singolo tenant: le risorse dei criteri di sicurezza di Application Gateway for Containers vengono associate al livello del gateway o di HTTPRoute, in modo che tenant diversi possano usare set di regole, esclusioni o regole personalizzate diversi nella stessa istanza condivisa di Application Gateway for Containers.

• Osservabilità consapevole del tenant: Le identità di HTTPRoute e del back-end confluiscono nelle metriche Prometheus del controller dell'Application Load Balancer. Questi dati offrono una visualizzazione per tenant del volume delle richieste, della latenza e degli errori senza strumentazione personalizzata.

Usare Application Gateway for Containers per esporre e proteggere i carichi di lavoro esposti a Internet che vengono eseguiti in un ambiente multi-tenant su un cluster AKS.

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Well-Architected Framework.

Alcune considerazioni non sono direttamente correlate alla multitenancy in AKS, ma sono requisiti essenziali per questa soluzione. Queste considerazioni includono sicurezza, prestazioni, disponibilità, affidabilità, archiviazione, scheduler, service mesh e linee guida per il monitoraggio.

Reliability

L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni assunti dai clienti. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'affidabilità.

Considera i seguenti metodi per ottimizzare la disponibilità per il tuo cluster AKS e i carichi di lavoro.

Containers

• Usare i probe di integrità di Kubernetes per assicurarsi che i contenitori siano attivi e integri:

  • Il livenessProbe (probe di attività) indica se il contenitore è in esecuzione. Se la sonda di vitalità fallisce, kubelet termina il contenitore e il contenitore segue la sua politica di riavvio.

  • Il readinessProbe (probe di idoneità) indica se il contenitore è pronto a rispondere alle richieste. Se la sonda di disponibilità non riesce, il controller dell'endpoint rimuove l'indirizzo IP del pod dagli endpoint di tutti i servizi che corrispondono al pod stesso. Lo stato predefinito di prontezza prima che il ritardo iniziale è fallimento.

  • StartupProbe indica se l'applicazione all'interno del contenitore viene avviata. Se è configurata una probe di avvio, tutte le altre probe sono disattivate finché la probe di avvio non ha esito positivo. Se la sonda di avvio ha esito negativo, kubelet termina il contenitore ed è soggetto alla sua politica di riavvio.

• La contesa di risorse può influire sulla disponibilità del servizio. Definire vincoli per le risorse dei contenitori in modo che nessun contenitore possa sovraccaricare la memoria del cluster e le risorse della CPU. È possibile usare la diagnostica del servizio Azure Kubernetes per identificare eventuali problemi nel cluster.

• Usare il limite di risorse per limitare le risorse totali allocate a un contenitore in modo che un contenitore non possa privare altri utenti.

Container Registry

• Archiviare le immagini del contenitore in Registro Contenitori. Usare la geo-replica del Container Registry per replicare geograficamente il registro in ciascuna regione AKS. La replica geografica è una funzionalità di Registro Container Premium.

• Analizzare le immagini del contenitore per le vulnerabilità. Distribuisci solo immagini che superano la convalida. Aggiorna regolarmente le immagini di base e il runtime dell'applicazione, quindi ridistribuisci i carichi di lavoro nel cluster AKS.

• Limitare i registri di immagini che possono essere usati da pod e distribuzioni. Limitare l'accesso ai registri attendibili in cui è possibile convalidare e controllare le immagini disponibili.

• Analizzare le immagini del contenitore per individuare le vulnerabilità nell'ambito di una pipeline di integrazione continua e recapito continuo (CI/CD) prima di pubblicare immagini nel Registro Container. Quando si usano immagini di base per le immagini dell'applicazione, usare l'automazione per creare nuove immagini quando si aggiorna l'immagine di base. Le immagini di base in genere includono correzioni di sicurezza, pertanto è necessario aggiornare tutte le immagini del contenitore dell'applicazione downstream. È consigliabile integrare Microsoft Defender per contenitori nei flussi di lavoro CI/CD. Per ulteriori informazioni, vedere Automatizzare la creazione di immagini dei contenitori.

• Usare le attività del Registro Container per automatizzare l'applicazione di patch del sistema operativo e del framework per i contenitori Docker. Le attività del Registro Container supportano un processo di compilazione automatizzato quando si aggiorna l'immagine di base di un contenitore. Ad esempio, è possibile applicare patch al framework del sistema operativo o dell'applicazione in una delle immagini di base.

Resilienza intraregion

• Valutare la possibilità di distribuire i pool di nodi del cluster del servizio Azure Kubernetes in tutte le zone di disponibilità all'interno di un'area. Usare Azure Load Balancer o Application Gateway davanti ai pool di nodi. Questa topologia offre una migliore resilienza se si verifica una singola interruzione del data center. Questo metodo distribuisce i nodi del cluster in più data center che si trovano in tre zone di disponibilità separate all'interno di un'area.

• Abilita la ridondanza della zona in Container Registry per la resilienza intra-area e l'alta disponibilità (HA).

• Usare vincoli di distribuzione della topologia dei pod per controllare la distribuzione dei pod nel cluster AKS tra domini di errore, come regioni, zone di disponibilità e nodi.

• Usare un accordo sul livello di servizio (SLA) per il tempo di attività per i cluster AKS che ospitano workload di produzione. Un SLA sul tempo di attività è una funzionalità facoltativa per abilitare un SLA più elevato e supportato finanziariamente per un cluster. Per gli specifici obiettivi e le condizioni di disponibilità, vedere la documentazione sul contratto di servizio (SLA) del tempo di attività di AKS e il contratto di servizio (SLA) di Azure per AKS. AKS usa repliche dei nodi del piano di controllo distribuite tra domini di aggiornamento e domini di errore per contribuire a soddisfare questi obiettivi del contratto di servizio (SLA).

Continuità aziendale e ripristino di emergenza

• È consigliabile distribuire la soluzione in almeno due aree di Azure abbinate all'interno di un'area geografica. È anche consigliabile adottare un servizio di bilanciamento del carico globale, ad esempio Gestione traffico di Azure o Frontdoor di Azure. Combinare il servizio di bilanciamento del carico con un metodo di routing attivo-attivo o attivo-passivo per supportare la continuità aziendale e il ripristino di emergenza (BC/DR).

• Creare script, documentare e testare periodicamente i processi di failover regionali in un ambiente di controllo qualità (QA). I processi di failover consentono di evitare problemi imprevedibili se un'interruzione nell'area primaria influisce su un servizio principale.

• Usare i test del processo di failover per verificare se l'approccio di disaster recovery soddisfa gli obiettivi di recovery point objective (RPO) e recovery time objective (RTO). Includere processi e interventi manuali nella verifica.

• Testare le procedure di failback per assicurarsi che funzionino come previsto.

• Archiviare le immagini del contenitore in Registro Container. Replicare geograficamente il registro in ogni area AKS. Per altre informazioni, vedere Replica geografica in Registro Contenitori.

• Evitare di archiviare lo stato del servizio all'interno di un contenitore, se possibile. Usare invece un Azure PaaS che supporta la replica a più aree.

• Preparare e testare come eseguire la migrazione dell'archiviazione dall'area primaria all'area di backup se si usa Archiviazione.

• Prendere in considerazione l'uso di GitOps per distribuire la configurazione del cluster. GitOps offre uniformità tra i cluster primario e di ripristino di emergenza e offre anche un modo rapido per ricompilare un nuovo cluster, se non ne è disponibile uno.

• Valutare la possibilità di eseguire il backup e il ripristino della configurazione del cluster utilizzando strumenti come AKS backup o Velero.

Mesh del servizio

• Valuta l'uso di una service mesh open source, ad esempio Istio, Linkerd o Consul, nel tuo cluster AKS. Una mesh di servizi usa TLS mutuo per migliorare l'osservabilità, l'affidabilità e la sicurezza dei tuoi microservizi. È anche possibile implementare strategie di suddivisione del traffico, ad esempio distribuzioni blu-verde e distribuzioni canary. Una mesh di servizi è un livello di infrastruttura dedicato che consente di rendere la comunicazione da servizio a servizio più sicura, più veloce e affidabile. Per ulteriori informazioni, vedere Istio service mesh AKS add-on.

• Valuta l'adozione di Dapr per creare applicazioni resilienti basate su microservizi, che siano senza stato o con stato. È possibile usare qualsiasi linguaggio di programmazione e framework di sviluppo.

Security

La sicurezza offre garanzie contro attacchi intenzionali e l'uso improprio dei dati e dei sistemi preziosi. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per la sicurezza.

Multi-tenancy

• Progettare i cluster del servizio Azure Kubernetes per un'architettura multi-tenancy. Kubernetes offre funzionalità che è possibile usare per isolare logicamente team e carichi di lavoro nello stesso cluster. Fornire il minor numero di privilegi alle risorse necessarie per ogni team. Uno spazio dei nomi in Kubernetes crea un limite di isolamento logico.

• Usare l'isolamento logico per separare team e progetti. Ridurre al minimo il numero di cluster AKS fisici distribuiti per isolare team o applicazioni. La separazione logica dei cluster fornisce in genere una maggiore densità dei pod rispetto ai cluster isolati fisicamente.

• Usa pool di nodi dedicati o cluster AKS dedicati quando è necessario garantire un rigoroso isolamento fisico. Ad esempio, è possibile dedicare un pool di nodi di lavoro o un intero cluster a un team o a un tenant in un ambiente multi-tenant.

  Usare una combinazione di taints e tolerations per controllare la distribuzione dei pod in un pool di nodi specifico. Si può taintare un nodo solo in AKS durante la creazione del pool di nodi. In alternativa, è possibile usare etichette e selettori nodePool per distribuire il carico di lavoro solo in pool di nodi specifici.

Sicurezza di rete

• Creare un endpoint privato per qualsiasi servizio PaaS utilizzato dai carichi di lavoro AKS, come Key Vault, bus di servizio di Azure o database SQL di Azure. Un endpoint privato garantisce che il traffico tra le applicazioni e questi servizi non sia esposto alla rete Internet pubblica. Per altre informazioni, vedi panoramica di collegamento privato.

• Configurare la risorsa di ingresso kubernetes per esporre i carichi di lavoro tramite HTTPS. Usare un sottodominio separato e un certificato digitale per ogni tenant. Configurare la terminazione SSL/TLS nel front-end di Application Gateway for Containers tramite la configurazione del listener dell'API Gateway. I certificati devono essere archiviati come segreti Kubernetes. Application Gateway for Containers non supporta l'integrazione dei certificati di Key Vault tramite il driver CSI di Secrets Store perché richiede che i certificati siano locali al cluster. Per la gestione automatica del ciclo di vita dei certificati, è consigliabile usare cert-manager con un'autorità emittente adatta all'ambiente, ad esempio Let's Encrypt for nonproduction o development scenarios, oppure l'autorità di certificazione interna dell'organizzazione o un certificato rilasciato Key Vault archiviato come segreto Kubernetes per carichi di lavoro di produzione aziendali.

• Configurare Application Gateway for Containers per usare un criterio WAF e contribuire a proteggere i carichi di lavoro esposti pubblicamente in esecuzione su AKS da attacchi malevoli. Il WAF per Application Gateway per i contenitori è configurato tramite una risorsa dei criteri di sicurezza associata a un criterio di Web application firewall di Azure. Associa i criteri di sicurezza al Gateway di Application Gateway for Containers o alla configurazione HTTPRoute per applicare la protezione basata su DRS 2.1 e le regole personalizzate in tutti i namespace del tenant.

• Usare il networking CNI di Azure in AKS per integrarsi con reti virtuali esistenti o reti on-premises. Questo modello di rete consente inoltre una maggiore separazione delle risorse e dei controlli in un ambiente aziendale.

• Usare i criteri di rete per separare e proteggere le comunicazioni intraservizie controllando quali componenti possono comunicare tra loro. Per impostazione predefinita, tutti i pod in Kubernetes possono inviare e ricevere traffico senza limitazioni. Per migliorare la sicurezza, è possibile usare Criteri di rete di Azure o Criteri di rete Calico per definire regole che controllano il flusso del traffico tra microservizi diversi. Per altre informazioni, vedere Criteri di rete.

• Non esporre la connettività remota ai nodi AKS. Usa l'integrazione nativa del cluster privato AKS con Azure Bastion per l'accesso amministrativo diretto al server API del cluster. Per le attività operative che richiedono molti strumenti, instradarle attraverso una VM operatore accessibile tramite Bastion in una subnet di gestione.

• Prendere in considerazione l'uso di intervalli di indirizzi IP autorizzati nel servizio Azure Kubernetes per creare un cluster del servizio Azure Kubernetes privato nell'ambiente di produzione. Se non è possibile usare un cluster privato di Azure Kubernetes Service (AKS), assicurati almeno di mettere in sicurezza l'accesso al server API.

• Combinare Azure protezione DDoS con le procedure consigliate per la progettazione delle applicazioni per aggiungere un altro livello di difesa contro gli attacchi DDoS. Abilitare la Protezione DDoS nelle reti virtuali perimetrali.

Autenticazione e autorizzazione

• Distribuire i cluster AKS con l'integrazione di Microsoft Entra. Per ulteriori informazioni, vedere Integrazione Microsoft Entra gestita da AKS. Microsoft Entra ID centralizza il componente di gestione delle identità.

• Usare Kubernetes RBAC per definire le autorizzazioni che utenti o gruppi hanno relativamente alle risorse del cluster. Usare Ruoli o ClusterRoles e associazioni per limitare gli utenti o i gruppi al minor numero di autorizzazioni necessarie. Integra Kubernetes RBAC con Microsoft Entra ID affinché qualsiasi modifica dello stato utente o dei gruppi aggiorni automaticamente l'accesso alle risorse del cluster. Per altre informazioni, vedere Kubernetes RBAC.

• Utilizzare Azure RBAC per definire le autorizzazioni minime necessarie che utenti o gruppi devono avere sulle risorse AKS in una o più sottoscrizioni. Per altre informazioni, vedere Usare il controllo degli accessi in base al ruolo di Azure per l'autorizzazione di Kubernetes.

• Usare ID dei carichi di lavoro di Microsoft Entra per assegnare un'identità gestita a singoli microservizi per l'accesso alle risorse Azure. Il microservizio può quindi accedere a risorse gestite, ad esempio Key Vault, database SQL, bus di servizio e Azure Cosmos DB. Il microservizio non deve archiviare e recuperare stringa di connessione o credenziali dai segreti Kubernetes.

• Usare il Secrets Store CSI Driver per Key Vault per accedere ai segreti, ad esempio credenziali e stringhe di connessione, da Key Vault anziché dai segreti di Kubernetes.

• Combinare il blocco costitutivo dell'archivio dei segreti Dapr con l'archivio Key Vault e le identità gestite su Kubernetes per recuperare segreti, come credenziali e stringhe di connessione, da Key Vault.

Carico di lavoro e cluster

• Proteggere l'accesso al server API Kubernetes per proteggere il cluster. Integrare RBAC di Kubernetes con Microsoft Entra ID per controllare l'accesso al server API. Usa questi controlli per aiutare a proteggere AKS nello stesso modo in cui proteggi l'accesso alla sottoscrizione di Azure.

• Limitare l'accesso alle azioni che i contenitori possono eseguire. Usare la funzionalità di ammissione alla sicurezza dei pod per abilitare l'autorizzazione con granularità fine della creazione e aggiornamenti dei pod. Concedere il minor numero possibile di permessi ed evitare l'uso di root o l'escalation dei privilegi. Per altre informazioni, vedere Proteggere l'accesso dei pod alle risorse.

• Evitare di eseguire i contenitori con l'utente root quando possibile.

• Usare il modulo di protezione del kernel di Linux AppArmor per limitare le azioni che possono essere eseguite dai contenitori.

• Aggiornare regolarmente i cluster del servizio Azure Kubernetes alla versione più recente di Kubernetes per sfruttare le nuove funzionalità e le correzioni di bug.

• Usa il DaemonSet kured per monitorare i riavvii in attesa, isolare e svuotare i nodi e applicare gli aggiornamenti. AKS scarica e installa automaticamente le correzioni di sicurezza su ciascun nodo Linux, ma non riavvia automaticamente il nodo se necessario. Per i nodi Windows Server, eseguire regolarmente un'operazione di aggiornamento di AKS per cordonare e svuotare in modo sicuro i pod e distribuire i nodi aggiornati.

• Prendere in considerazione l'uso di protocolli di trasporto sicuri HTTPS e gRPC per tutte le comunicazioni intra-pod. Usare un meccanismo di autenticazione più avanzato che non richiede l'invio delle credenziali semplici in ogni richiesta, ad esempio Open Authorization (OAuth) o JSON Web Token (JWT). Stabilire comunicazioni intraservizie più sicure usando una mesh di servizi, ad esempio Istio, Linkerd o Consul. In alternativa, è possibile usare Dapr.

Container Registry

Analizzare le immagini del contenitore per individuare le vulnerabilità e distribuire solo immagini che superano la convalida. Aggiornare regolarmente le immagini di base e il runtime dell'applicazione. Ridistribuire quindi i carichi di lavoro nel cluster di Azure Kubernetes Service. Il flusso di lavoro di distribuzione CI/CD deve includere un processo per analizzare le immagini del contenitore. È possibile usare Microsoft Defender per la sicurezza di DevOps per analizzare il codice per individuare le vulnerabilità nelle pipeline automatizzate durante le fasi di compilazione e distribuzione. In alternativa, è possibile usare strumenti come Prisma Cloud o Aqua per analizzare e consentire la distribuzione solo di immagini verificate.

Ottimizzazione dei costi

L'ottimizzazione dei costi è incentrata sui modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'ottimizzazione dei costi.

Il costo di questa architettura dipende da specifiche di configurazione, ad esempio i componenti seguenti:

• Livelli di servizio

• Scalabilità o il numero di istanze che i servizi allocano dinamicamente per supportare un livello specifico di domanda

• Script di automazione

• Il tuo livello DR

Dopo aver valutato questi dettagli, usare il calcolatore prezzi Azure per stimare i costi. Per altre informazioni, vedere i principi del Well-Architected Framework di Ottimizzazione dei costi.

Eccellenza operativa

L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e lo mantengono nell'ambiente di produzione. Per ulteriori informazioni, vedere Lista di controllo per la revisione del design per l'Eccellenza Operativa.

Archiviazione

• Valutare la possibilità di distribuire il cluster AKS con dischi OS effimeri che offrono una latenza di lettura e scrittura inferiore, oltre a un ridimensionamento più rapido dei nodi e aggiornamenti del cluster.

• Comprendere le esigenze dell'applicazione in modo da poter scegliere la risorsa di archiviazione corretta. Usare l'archiviazione con supporto SSD ad alte prestazioni per i carichi di lavoro di produzione. Pianificare un sistema di archiviazione basato su rete, ad esempio File di Azure, quando più pod devono accedere contemporaneamente agli stessi file. Per ulteriori informazioni, vedere opzioni di archiviazione per le applicazioni in AKS.

• Pianificare le richieste dell'applicazione in modo da distribuire le dimensioni appropriate dei nodi. Ogni dimensione di nodo supporta un numero massimo di dischi. Dimensioni diverse forniscono quantità diverse di spazio di archiviazione locale e larghezza di banda della rete.

• Usare invece il provisioning dinamico. Per ridurre il sovraccarico di gestione e abilitare il ridimensionamento, non creare e assegnare volumi persistenti in modo statico. Nelle classi di archiviazione definire i criteri di recupero appropriati per ridurre al minimo i costi di archiviazione non necessari dopo l'eliminazione dei pod.

DevOps

• Usare un sistema DevOps, ad esempio GitHub Actions o Azure DevOps, per distribuire i carichi di lavoro su AKS tramite un chart Helm in una pipeline CI/CD. Per ulteriori informazioni, vedere Compilare e distribuire in AKS.

• Introduce i test A/B e le distribuzioni in canary nella gestione del ciclo di vita dell'applicazione per testare correttamente un'applicazione prima di presentarla a tutti gli utenti. È possibile usare varie tecniche per suddividere il traffico tra versioni diverse dello stesso servizio.

• In alternativa, è possibile usare le funzionalità di gestione del traffico fornite da una mesh di servizi. Per altre informazioni, vedere Gestione del traffico Istio.

• Usare un registro di container o un altro archivio di registri, come Docker Hub, per catalogare e servire le immagini Docker private che distribuisci nel cluster. AKS può utilizzare l'identità Microsoft Entra per autenticarsi con il Registro di Container.

• Se devi modificare le impostazioni di Application Gateway for Containers, apporta le modifiche usando la Gateway API di Kubernetes supportata o le risorse dell'API Ingress, incluse le annotazioni documentate. Dopo aver eseguito la migrazione da AGIC ad Application Gateway for Containers, il controller del bilanciamento del carico dell'applicazione allinea la configurazione di Application Gateway for Containers in base a queste risorse Kubernetes.

Monitoring

• Prendere in considerazione le opzioni di monitoraggio integrate di Azure per monitorare lo stato di integrità del cluster AKS e dei relativi carichi di lavoro.

• Abilitare il servizio gestito di Monitoraggio di Azure per Prometheus nel cluster AKS per raccogliere le metriche dal controller del bilanciamento del carico dell'applicazione e dai pod del carico di lavoro. Il controller di bilanciamento del carico dell'applicazione espone le metriche in formato Prometheus, inclusi i conteggi delle richieste, gli istogrammi di latenza e lo stato della connessione per ogni regola di routing front-end e back-end. Usare regole di registrazione per preaggregare le metriche di Application Gateway for Containers ad alta cardinalità per query efficienti.

• Usa Grafana con gestione Azure per visualizzare Application Gateway for Containers e le metriche di AKS raccolte da Prometheus gestito di Monitoraggio di Azure. Importare il dashboard di monitoraggio dei nodi del servizio Azure Kubernetes per tenere traccia dell'utilizzo della CPU, della memoria, del disco e della rete a livello di nodo nel cluster. Creare dashboard Grafana personalizzati che combinano le metriche delle richieste del controller dell'Application Load Balancer, i conteggi delle corrispondenze delle regole WAF e i segnali di prontezza dei pod AKS in un'unica vista operativa.

• Inviare i log e le metriche della risorsa Application Gateway per contenitori a un'area di lavoro Log Analytics abilitando le impostazioni di diagnostica sulla risorsa Application Gateway per contenitori. Utilizzare query KQL di esempio per AGCAccessLogs per analizzare gli andamenti del traffico, rilevare picchi di errori 4xx/5xx per namespace del tenant e correlare gli eventi di blocco del WAF con lo stato di salute dei pod upstream.

• Configurare tutti i servizi PaaS, ad esempio Registro Container e Key Vault, per raccogliere log e metriche di diagnostica e inviarli a Log Analytics.

• Configura gli avvisi di Monitoraggio di Azure per le metriche chiave di Application Gateway for Containers: numero di back-end non integri, frequenza delle richieste bloccate dal WAF ed errori di connessione front-end. Instradare le notifiche di avviso al team di chiamata appropriato usando i gruppi di azioni.

Efficienza prestazionale

L'efficienza delle prestazioni si riferisce alla capacità del carico di lavoro di ridimensionarsi per soddisfare in modo efficiente le esigenze degli utenti. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'efficienza delle prestazioni.

Prendere in considerazione i consigli sulle prestazioni seguenti:

• Per i carichi di lavoro a bassa latenza, valutare la possibilità di distribuire un pool di nodi dedicato in un gruppo di posizionamento di prossimità (PPG). Quando si distribuisce l'applicazione in Azure, le istanze di macchine virtuali distribuite tra aree o zone di disponibilità creano latenza di rete, che potrebbe influire sulle prestazioni complessive dell'applicazione. Un PPG è un raggruppamento logico che è possibile usare per assicurarsi che Azure risorse di calcolo si trovino fisicamente vicino l'uno all'altro. Alcuni casi d'uso, ad esempio giochi, simulazioni di ingegneria e trading ad alta frequenza, richiedono bassa latenza e attività che vengono completate rapidamente. Per scenari di calcolo ad alte prestazioni (HPC) come questi, valuta l'uso di PPG per i pool di nodi del cluster.

• Usare immagini contenitore più piccole, se possibile, per ridurre i tempi di compilazione e ridurre la superficie di attacco.

• Usare la scalabilità automatica di Kubernetes per aumentare in modo dinamico il numero di nodi di lavoro in un cluster del servizio Azure Kubernetes quando aumenta il traffico. Con Horizontal Pod Autoscaler (HPA) e l'autoscaler del cluster, il numero di nodi e pod viene regolato dinamicamente in tempo reale in base alle condizioni del traffico, per evitare tempi di inattività dovuti a problemi di capacità. Per ulteriori informazioni, consultare Usare il ridimensionamento automatico del cluster in AKS.

Scheduler

• Esaminare e implementare le best practice per gli operatori del cluster e gli sviluppatori di applicazioni per creare ed eseguire correttamente applicazioni su AKS.

• Pianificare e applicare quote risorse a livello di namespace per tutti i namespace. Se i pod non definiscono le richieste di risorse e i limiti, rifiuta la distribuzione. Monitorare l'utilizzo delle risorse e quindi modificare le quote in base alle esigenze. Quando più team o tenant condividono un cluster del servizio Azure Kubernetes con un numero fisso di nodi, è possibile usare le quote di risorse per assegnare una condivisione equa di risorse a ogni team o tenant.

• Adottare intervalli di limiti per vincolare le allocazioni di risorse ai pod o ai contenitori in uno spazio dei nomi, in termini di CPU e memoria.

• Definire le richieste di risorse e i limiti in modo esplicito per l'utilizzo della CPU e della memoria per i pod nei manifesti YAML o nei grafici Helm usati per distribuire le applicazioni. Quando si specifica la richiesta di risorse per i contenitori in un pod, l'utilità di pianificazione di Kubernetes usa queste informazioni per decidere su quale nodo posizionare il pod. Quando si specificano i limiti delle risorse per un contenitore, ad esempio la CPU o la memoria, kubelet applica tali limiti in modo che il contenitore in esecuzione non possa superare i limiti impostati.

• Mantenere la disponibilità delle applicazioni definendo i budget di interruzione dei pod per assicurarsi che nel cluster siano disponibili un numero minimo di pod.

• Usare le classi di priorità per indicare l'importanza di un pod. Se lo scheduler non riesce a schedulare un pod, tenta di effettuare la preemption, ovvero di espellere i pod con priorità inferiore, in modo da poter schedulare il pod in attesa.

• Usare i contenitori e le tolleranze di Kubernetes per posizionare applicazioni a elevato utilizzo di risorse in nodi dedicati in modo che non si contendono altri carichi di lavoro per CPU e memoria. Mantenere disponibili le risorse del nodo per i carichi di lavoro che li richiedono e impedire la pianificazione di altri carichi di lavoro negli stessi nodi.

• Usare selettori di nodo, affinità dei nodi o affinità tra pod per controllare la pianificazione dei pod nei nodi. Usare le impostazioni di affinità e anti-affinità tra i pod per collocare i pod che hanno comunicazioni frequenti e per distribuire i pod su nodi differenti, evitando di eseguire più istanze dello stesso tipo di pod sullo stesso nodo.

Contributori

Microsoft gestisce questo articolo. I seguenti collaboratori hanno scritto questo articolo.

Autori principali:

• Vyshnavi Namani | Product Manager, Gateway applicativo per contenitori
• Paolo Salvatori | Ingegnere del servizio principale

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

• Pratiche migliori per i cluster AKS
• Procedure consigliate per le funzionalità di base dell'utilità di pianificazione su AKS
• Creare un cluster AKS privato
• Distribuisci il componente aggiuntivo del controller del bilanciatore del carico dell'applicazione Application Gateway for Containers
• Come funziona un gateway applicativo

Risorsa collegata

• Architettura di base per un cluster AKS