Baseline di AKS per cluster multiarea

Questa architettura illustra in dettaglio come eseguire più istanze di un cluster Servizio Azure Kubernetes (AKS) in aree multiple in una configurazione attiva/attiva e a disponibilità elevata.

Questa architettura si basa sull'architettura di base AKS, punto di partenza consigliato da Microsoft per l'infrastruttura del Servizio Azure Kubernetes. La baseline di AKS illustra in dettaglio le funzionalità infrastrutturali, ad esempio le ID dei carichi di lavoro di Microsoft Entra, le restrizioni in ingresso e uscita, i limiti delle risorse e altre configurazioni dell'infrastruttura del Servizio Azure Kubernetes sicure. Questi dettagli infrastrutturali non sono trattati in questo documento. È consigliabile acquisire familiarità con la baseline del Servizio Azure Kubernetes prima di procedere con il contenuto in aree multiple.

Architettura

Scaricare un file di Visio di questa architettura.

Componenti

Molti componenti e servizi di Azure vengono usati in questa architettura del servizio Azure Kubernetes multiarea. Di seguito sono elencati solo i componenti con univocità per questa architettura multi-cluster. Per il resto, fare riferimento all'architettura baseline di AKS.

• Cluster di AKS a livello di area: vengono distribuiti cluster multipli del Servizio Azure Kubernetes, ognuno in un'area di Azure separata. Durante il normale funzionamento, il traffico di rete viene indirizzato tra tutte le aree. Se un'area non è più disponibile, il traffico viene instradato a un'area più vicina all'utente che ha inviato la richiesta.
• Reti hub-spoke a livello di area: viene distribuita una coppia di reti hub-spoke a livello di area per ogni istanza del Servizio Azure Kubernetes a livello di area. I criteri di Gestione firewall di Azure vengono usati per gestire i criteri del firewall in tutte le aree.
• Insieme di credenziali delle chiavi a livello di area: viene effettuato il provisioning di Azure Key Vault in ogni area. Gli insiemi di credenziali delle chiavi vengono usati per archiviare valori sensibili e chiavi specifiche per il cluster di AKS e per i servizi di supporto presenti in tale area.
• Aree di lavoro log multiple: le aree di lavoro Analisi dei log a livello di area vengono usate per archiviare le metriche di rete a livello di area e i log di diagnostica. Inoltre, un'istanza di Analisi dei log condivisa viene usata per archiviare metriche e log di diagnostica per tutte le istanze di AKS.
• Profilo globale di Frontdoor di Azure: Frontdoor di Azure viene usato per bilanciare il carico e instradare il traffico a un'istanza del gateway applicazione di Azure a livello di area, che si trova davanti a ogni cluster di AKS. Frontdoor di Azure consente il routing globale di livello 7, entrambi necessari per questa architettura.
• Registro contenitori globale: le immagini del contenitore per il carico di lavoro vengono archiviate in un registro contenitori gestito. In questa architettura, viene usato un singolo Registro contenitori di Azure per tutte le istanze di Kubernetes nel cluster. La replica geografica per Registro contenitori di Azure consente di replicare le immagini nelle aree di Azure selezionate e di fornire l'accesso continuo alle immagini anche in caso di interruzione di un'area.

Schemi progettuali

Questa architettura usa due modelli di progettazione cloud:

• Geodes (nodi geografici), in cui qualsiasi area può supportare qualsiasi richiesta.
• Stamp di distribuzione, in cui più copie indipendenti di un'applicazione o di un componente dell'applicazione vengono distribuite da un'unica origine, ad esempio un modello di distribuzione.

Considerazioni sul modello del nodo geografico

Quando si selezionano aree per distribuire ogni cluster di AKS, prendere in considerazione le aree vicine al consumer del carico di lavoro o ai clienti. Prendere in considerazione anche l'uso della replica tra aree. La replica tra aree ripete in modo asincrono le stesse applicazioni e i dati in altre aree di Azure per la protezione del ripristino di emergenza. Man mano che il cluster viene ridimensionato oltre due aree, continuare a pianificare la replica tra aree per ogni coppia di cluster di AKS.

All'interno di ogni area, i nodi nei pool di nodi di AKS vengono distribuiti in più zone di disponibilità per evitare problemi causati da errori di zona. Le zone di disponibilità sono supportate in un set limitato di aree, che influisce sul posizionamento del cluster a livello di area. Per maggiori informazioni su AKS e sulle zone di disponibilità, incluso un elenco di aree supportate, vedere la sezione Zone di disponibilità AKS.

Considerazioni sugli stamp di distribuzione

Quando si gestisce una soluzione AKS multiarea, si distribuiscono più cluster di AKS in più aree. Ognuno di questi cluster è considerato uno stamp. Se si verifica un errore a livello di area o se è necessario aggiungere più capacità o presenza a livello di area per i cluster, potrebbe essere necessario creare una nuova istanza di stamp. Quando si seleziona un processo per la creazione e la gestione degli stamp di distribuzione, è importante considerare quanto segue:

• Selezionare la tecnologia appropriata per le definizioni di stamp che consente la configurazione generalizzata. Ad esempio, è possibile usare Bicep per definire l'infrastruttura come codice.
• Specificare valori specifici dell'istanza usando un meccanismo di input della distribuzione, ad esempio variabili o file di parametri.
• Selezionare gli strumenti di distribuzione che consentono la distribuzione flessibile, ripetibile e idempotente.
• In una configurazione di stamp attiva/attiva, considerare il modo in cui il traffico viene bilanciato tra ogni timbro. Questa architettura usa Frontdoor di Azure per il bilanciamento del carico globale.
• Man mano che vengono aggiunti e rimossi gli stamp dalla raccolta, prendere in considerazione problemi di capacità e costi.
• Considerare come ottenere visibilità e monitorare la raccolta di stamp come singola unità.

Ognuno di questi elementi è dettagliato con indicazioni specifiche nelle sezioni seguenti.

Gestione della flotta

Questa soluzione rappresenta una topologia multi-cluster e multiarea, senza l'inclusione di un agente di orchestrazione avanzato per trattare tutti i cluster come parte di una flotta unificata. Quando aumenta il numero di cluster, valutare la possibilità di registrare i membri in Gestione flotta Kubernetes di Azure per una migliore gestione su larga scala dei cluster partecipanti. L'architettura dell'infrastruttura presentata qui non cambia fondamentalmente con la registrazione in Fleet Manager, ma le operazioni del giorno 2 e attività simili traggono vantaggio da un piano di controllo che può essere destinato a più cluster contemporaneamente.

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 Microsoft Azure Well-Architected Framework.

Distribuzione del cluster e bootstrap

Quando si distribuiscono cluster Kubernetes multipli in configurazioni a disponibilità elevata e distribuite geograficamente, è essenziale considerare la somma di ogni cluster Kubernetes come unità abbinata. È possibile sviluppare strategie guidate dal codice per la distribuzione e la configurazione automatizzate per assicurarsi che ogni istanza Kubernetes sia il più possibile identica. Prendere in considerazione le strategie per la scalabilità orizzontale e verticale, inclusa l'aggiunta o la rimozione di altri cluster Kubernetes. Il piano di progettazione, distribuzione e configurazione deve tenere conto delle interruzioni della zona di disponibilità, degli errori a livello di area e di altri scenari comuni.

Definizione cluster

Sono disponibili molte opzioni per la distribuzione di un cluster Servizio Azure Kubernetes. Il portale di Azure, CLI di Azure e il modulo Azure PowerShell sono tutte opzioni decenti per la distribuzione di cluster AKS singoli o non associati. Questi metodi, tuttavia, possono presentare problemi quando si lavora con molti cluster AKS strettamente associati. Ad esempio, l'uso del portale di Azure offre l'opportunità di errori di configurazione a causa di passaggi mancanti od opzioni di configurazione non disponibili. La distribuzione e la configurazione di molti cluster che usano il portale è un processo dispendioso in termini di tempo e richiede l'attenzione di uno o più tecnici. Se si usa CLI di Azure o Azure PowerShell, è possibile creare un processo ripetibile e automatizzato usando gli strumenti da riga di comando. Tuttavia, la responsabilità dell'idempotenza, del controllo degli errori di distribuzione e del ripristino degli errori riguarda l'utente e gli script compilati.

Quando si usano istanze AKS multiple, è consigliabile prendere in considerazione l'infrastruttura come soluzioni di codice, ad esempio Bicep, modelli di Azure Resource Manager o Terraform. L'infrastruttura come soluzione di codice offre una soluzione di distribuzione automatizzata, scalabile e idempotente. Ad esempio, è possibile usare un file Bicep per i servizi condivisi della soluzione e un altro per i cluster AKS e altri servizi a livello di area. Se si usa l'infrastruttura come codice, è possibile definire uno stamp di distribuzione con configurazioni generalizzate, ad esempio rete, autorizzazione e diagnostica. È possibile specificare un file di parametri di distribuzione con valori specifici dell'area. Con questa configurazione, è possibile usare un singolo modello per distribuire uno stamp quasi identico in qualsiasi area.

Il costo dello sviluppo e della gestione dell'infrastruttura come asset di codice può essere elevato. In alcuni casi, il sovraccarico della definizione dell'infrastruttura come codice potrebbe superare i vantaggi, ad esempio, quando si dispone di un numero molto ridotto (ad esempio, 2 o 3) e di un numero non modificabile di istanze AKS. In questi casi, è accettabile usare un approccio più imperativo, ad esempio con gli strumenti da riga di comando o anche gli approcci manuali con il portale di Azure.

Distribuzione cluster

Dopo aver definito lo stamp del cluster, sono disponibili molte opzioni per la distribuzione di istanze singole o multiple di stamp. È consigliabile usare la tecnologia di integrazione continua moderna, ad esempio GitHub Actions o Azure Pipelines. I vantaggi delle soluzioni di distribuzione basate sull'integrazione continua includono:

• Distribuzioni basate su codice che consentono l'aggiunta e la rimozione di stamp tramite codice
• Funzionalità di test integrate
• Funzionalità integrate di ambiente e gestione temporanea
• Soluzioni di gestione integrata dei segreti
• Integrazione con il controllo del codice sorgente, sia per il codice dell'applicazione che per gli script e i modelli di distribuzione
• Cronologia e registrazione della distribuzione
• Funzionalità di controllo e controllo di accesso, per controllare chi può apportare modifiche e in quali condizioni

Man mano che vengono aggiunti o rimossi nuovi stamp dal cluster globale, la pipeline di distribuzione deve essere aggiornata per mantenere la coerenza. Un approccio consiste nel distribuire le risorse di ogni area come singolo passaggio all'interno di un flusso di lavoro di GitHub Actions. Questa configurazione è semplice perché ogni istanza del cluster è chiaramente definita all'interno della pipeline di distribuzione. Questa configurazione include un sovraccarico amministrativo nell'aggiunta e nella rimozione di cluster dalla distribuzione.

Un'altra opzione consiste nel creare logica di business per creare cluster in base a un elenco di posizioni desiderate o ad altri punti dati. Ad esempio, la pipeline di distribuzione potrebbe contenere un elenco di aree desiderate; un passaggio all'interno della pipeline potrebbe quindi scorrere l'elenco, distribuendo un cluster in ogni area presente nell'elenco. Lo svantaggio di questa configurazione è la complessità della generalizzazione della distribuzione e il fatto che ogni stamp del cluster non è descritto in modo esplicito nella pipeline di distribuzione. Il vantaggio positivo è il fatto che l'aggiunta o la rimozione di indicatori cluster dalla pipeline diventa un semplice aggiornamento all'elenco delle aree desiderate.

Inoltre, la rimozione di uno stamp cluster dalla pipeline di distribuzione non sempre rimuove le risorse dello stamp. A seconda della soluzione di distribuzione e della configurazione, potrebbe essere necessario un passaggio aggiuntivo per rimuovere le istanze AKS e altre risorse di Azure. È consigliabile usare gli stack di distribuzione per abilitare la gestione completa del ciclo di vita delle risorse di Azure, inclusa la pulizia quando non sono più necessarie.

Bootstrapping del cluster

Dopo la distribuzione di ogni istanza o stamp di Kubernetes, è necessario distribuire e configurare componenti del cluster, ad esempio controller di ingresso, soluzioni di identità e componenti del carico di lavoro. È inoltre necessario prendere in considerazione l'applicazione di criteri di sicurezza, accesso e governance nel cluster.

Analogamente alla distribuzione, queste configurazioni possono diventare difficili da gestire in diverse istanze di Kubernetes manualmente. Prendere invece in considerazione le opzioni seguenti per la configurazione e i criteri su larga scala.

GitOps

Anziché configurare manualmente i componenti Kubernetes, è consigliabile usare metodi automatizzati per applicare configurazioni a un cluster Kubernetes, perché queste configurazioni vengono archiviate in un repository di origine. Questo processo viene spesso definito GitOps, e le soluzioni GitOps più diffuse per Kubernetes includono Flux e Argo CD. Ad esempio, l'estensione Flux per AKS abilita il bootstrapping dei cluster automaticamente e immediatamente dopo la distribuzione dei cluster.

Per maggiori dettagli su GitOps, consultare la sezione Architettura di riferimento baseline di AKS. Usando un approccio basato su GitOps alla configurazione, assicurarsi che ogni istanza di Kubernetes sia configurata in modo analogo senza sforzo bespoke. Un processo di configurazione semplificato diventa ancora più importante man mano che le dimensioni della flotta aumentano.

Criteri di Azure

Man mano che vengono aggiunte istanze di Kubernetes multiple, il vantaggio della governance, della conformità e della configurazione basata su criteri aumenta. L'utilizzo di criteri, in particolare dei Criteri di Azure, fornisce un metodo centralizzato e scalabile per il controllo del cluster. Il vantaggio dei criteri AKS è descritto più in dettaglio nella sezione Architettura di riferimento baseline di AKS.

Criteri di Azure deve essere abilitato quando vengono creati i cluster di AKS. Le iniziative devono essere assegnate in modalità di controllo per ottenere visibilità sulla non conformità. È anche possibile impostare altri criteri che non fanno parte di alcuna iniziativa predefinita. Questi criteri vengono impostati in modalità Deny. È, ad esempio, disponibile un criterio per assicurarsi che nel cluster vengano eseguite solo le immagini del contenitore approvate. Prendere in considerazione la creazione di iniziative personalizzate. Combinare i criteri applicabili per il carico di lavoro in una singola assegnazione.

L'ambito dei criteri fa riferimento alla destinazione di ogni criterio e iniziativa di criteri. È possibile usare Bicep per assegnare criteri al gruppo di risorse in cui viene distribuito ogni cluster AKS. Man mano che aumenta il footprint del cluster globale, si ottengono molti criteri duplicati. È inoltre possibile definire l'ambito dei criteri per una sottoscrizione di Azure o un gruppo di gestione di Azure. Questo metodo consente di applicare un singolo set di criteri a tutti i cluster AKS nell'ambito di una sottoscrizione o a tutte le sottoscrizioni presenti in un gruppo di gestione.

Quando si progettano criteri per cluster AKS multipli, prendere in considerazione gli elementi seguenti:

• Applicare criteri che devono essere applicati a livello globale a tutte le istanze AKS a un gruppo di gestione o a una sottoscrizione.
• Posizionare ogni cluster a livello di area nel proprio gruppo di risorse, che consente l'applicazione di criteri specifici dell'area al gruppo di risorse.

Consultare la sezione Organizzazione delle risorse di Cloud Adoption Framework per i materiali che consentono di definire una strategia di gestione dei criteri.

Distribuzione del carico di lavoro

Oltre alla configurazione dell'istanza AKS, prendere in considerazione il carico di lavoro distribuito in ogni istanza o stamp a livello di area. Le soluzioni di distribuzione o le pipeline richiedono la configurazione per ogni stamp a livello di area. Man mano che vengono aggiunti più stamp al cluster globale, il processo di distribuzione deve essere esteso o deve essere sufficientemente flessibile per supportare le nuove istanze a livello di area.

Quando si pianifica la distribuzione del carico di lavoro, prendere in considerazione gli elementi seguenti.

• Generalizzare la distribuzione, ad esempio, con un grafico Helm, per assicurarsi che una singola configurazione di distribuzione possa essere usata in stamp del cluster multipli.
• Usare una singola pipeline di distribuzione continua configurata per distribuire il carico di lavoro in tutti gli stamp del cluster.
• Specificare i dettagli dell'istanza specifica dello stamp come parametri di distribuzione.
• Valutare il modo in cui sono configurate la registrazione diagnostica dell'applicazione e la traccia distribuita per l'osservabilità a livello di applicazione.

Disponibilità e failover

Una motivazione significativa per la scelta di un'architettura Kubernetes multiarea è la disponibilità del servizio. In altre parole, se un servizio o un componente del servizio, non è più disponibile in un'area, il traffico deve essere instradato a un'area in cui è ancora disponibile un'altra istanza di tale servizio. Un'architettura in più aree include molti punti di errore diversi. In questa sezione, viene illustrato ognuno di questi potenziali punti di errore.

Errori pod di applicazione

Un oggetto Kubernetes Deployment viene utilizzato per creare un ReplicaSet, che gestisce più repliche di un pod. Se un pod non è disponibile, il traffico viene instradato tra i rimanenti. Il ReplicaSet Kubernetes tenta di mantenere operativo il numero specificato di repliche. Se un'istanza diventa inattiva, dovrebbe essere creata automaticamente una nuova istanza. I probe di attività possono essere utilizzati per controllare lo stato dell'applicazione o del processo in esecuzione nel pod. Se il servizio non risponde, il probe di attività rimuove il pod, costringendo ReplicaSet a creare una nuova istanza.

Per altre informazioni, vedere Kubernetes ReplicaSet.

Errori hardware del data center

Occasionalmente, può verificarsi un errore localizzato. Ad esempio, l'alimentazione potrebbe non essere disponibile per un singolo rack di server di Azure. Per proteggere i nodi AKS dal diventare un singolo punto di errore, usare le zone di disponibilità di Azure. Usando le zone di disponibilità, si garantisce che i nodi AKS in una zona di disponibilità siano fisicamente separati da quelli definiti in un'altra zona di disponibilità.

Per maggiori informazioni, consultare la sezione Zone di disponibilità di AKS e Azure.

Errori area di Azure

Quando un'intera area non è più disponibile, i pod nel cluster non sono più disponibili per la gestione delle richieste. In questo caso, Frontdoor di Azure instrada tutto il traffico alle aree integre rimanenti. I cluster e i pod Kubernetes nelle aree integre continuano a gestire le richieste.

In questa situazione, fare attenzione a compensare l'aumento delle richieste e del traffico verso il cluster rimanente. Considerare gli aspetti seguenti:

• Assicurarsi che le risorse di rete e di calcolo siano dimensionate correttamente per assorbire qualsiasi aumento improvviso del traffico dovuto al failover dell'area. Ad esempio, quando si usa Azure CNI, assicurarsi di avere una subnet sufficientemente grande da supportare tutti gli indirizzi IP pod mentre il traffico è in stato di spiking.
• Usare la scalabilità automatica orizzontale dei pod per aumentare il numero di repliche pod per compensare l'aumento della domanda a livello di area.
• Usare il componente di scalabilità automatica del cluster del servizio Azure Kubernetes per aumentare i conteggi dei nodi dell'istanza di Kubernetes per compensare l'aumento della domanda a livello di area.

Per maggiori informazioni, consultare la sezione Scalabilità automatica orizzontale dei pod e Scalabilità automatica del cluster AKS.

Topologia di rete

Analogamente all'architettura di riferimento della baseline di AKS, questa architettura usa una topologia di rete hub-spoke. Oltre alle considerazioni specificate nell'architettura di riferimento della baseline di AKS, prendere in considerazione le procedure consigliate seguenti:

• Implementare un set hub-spoke di reti virtuali per ogni istanza AKS a livello di area. All'interno di ogni area, eseguire il peering di ogni spoke alla rete virtuale hub.
• Instradare tutto il traffico in uscita attraverso un'istanza di Firewall di Azure trovata in ogni rete hub a livello di area. Utilizzare i criteri di Gestione firewall di Azure per gestire i criteri del firewall in tutte le aree.
• Seguire il dimensionamento IP nell'architettura di riferimento della baseline di AKS e consentire un numero maggiore di indirizzi IP per le operazioni di scalabilità di nodi e pod nel caso in cui si verifichi un errore a livello di area in un'altra area e il traffico verso le aree rimanenti aumenti notevolmente.

Gestione del traffico

Con l'architettura di riferimento della baseline di AKS, il traffico del carico di lavoro viene indirizzato direttamente a un'istanza del gateway applicazione di Azure, quindi inoltrato alle risorse del servizio di bilanciamento del carico back-end e al traffico in ingresso di AKS. Quando si usano cluster multipli, le richieste client vengono instradate tramite un'istanza di Frontdoor di Azure, che instrada all'istanza del gateway applicazione di Azure.

Scaricare un file Visio di questo diagramma.

1. L'utente invia una richiesta a un nome di dominio, ad esempio https://contoso-web-a1bc2de3fh4ij5kl.z01.azurefd.net, che viene risolto nel profilo Frontdoor di Azure. Questa richiesta viene crittografata con un certificato con caratteri jolly (*.azurefd.net) rilasciato per tutti i sottodomini di Frontdoor di Azure. Frontdoor di Azure convalida la richiesta rispetto ai criteri Web application firewall, seleziona l'origine più veloce (in base all'integrità e alla latenza) e usa il DNS pubblico per risolvere l'indirizzo IP di origine (istanza del gateway applicazione di Azure).

2. Frontdoor di Azure inoltra la richiesta all'istanza di gateway applicazione appropriata selezionata, che funge da punto di ingresso per il timbro a livello di area. Flussi di traffico su Internet. Frontdoor di Azure garantisce che il traffico verso l'origine venga crittografato.

   Si consideri un metodo per assicurarsi che l'istanza di gateway applicazione accetti solo il traffico dall'istanza di Frontdoor. Un approccio consiste nell'usare un gruppo di sicurezza di rete nella subnet che contiene il gateway applicazione. Le regole possono filtrare il traffico in ingresso (o in uscita) in base a proprietà quali Origine, Porta, Destinazione. La proprietà Origine consente di impostare un tag del servizio predefinito che indica gli indirizzi IP per una risorsa di Azure. Questa astrazione rende più semplice configurare e gestire la regola e tenere traccia degli indirizzi IP. È inoltre consigliabile usare l'intestazione X-Azure-FDID, che Frontdoor di Azure aggiunge alla richiesta prima di inviarla all'origine, per assicurarsi che l'istanza di gateway applicazione accetti solo il traffico dall'istanza di Frontdoor. Per maggiori informazioni sulle intestazioni di Frontdoor, consultare l'articolo Supporto del protocollo per le intestazioni HTTP in Frontdoor di Azure.

Considerazioni sulle risorse condivise

Sebbene l'obiettivo di questo scenario sia quello di avere istanze Kubernetes multiple distribuite in aree di Azure multiple, è opportuno condividere alcune risorse in tutte le aree. Un approccio consiste nell'usare un singolo file Bicep per distribuire tutte le risorse condivise e un altro per distribuire ogni stamp a livello di area. Questa sezione descrive in dettaglio ognuna di queste risorse condivise e considerazioni per l'uso di ognuna tra più istanze AKS.

Registro Container

Registro contenitori di Azure viene usato in questa architettura per fornire servizi di immagine del contenitore. Il cluster esegue il pull delle immagini del contenitore dal registro. Quando si lavora con Registro contenitori di Azure in una distribuzione di cluster multiarea, prendere in considerazione gli elementi seguenti.

Disponibilità a livello geografico

Posizionare un registro contenitori in ogni area in cui viene distribuito un cluster AKS. Questo approccio consente di eseguire operazioni di rete vicina, offrendo trasferimenti a livello di immagine veloci e affidabili. Significa anche che sono disponibili più endpoint di servizio immagine per garantire la disponibilità quando i servizi a livello di area non sono disponibili. L'uso della funzionalità di replica geografica di Registro contenitori di Azure consente di gestire un registro contenitori replicato automaticamente aree multiple.

Prendere in considerazione la creazione di un singolo registro, con repliche in ogni area di Azure contenente cluster. Per maggiori informazioni sulla replica di Registro contenitori di Azure, consultare la sezione Replica geografica in Registro contenitori di Azure.

Immagine che mostra più repliche di Registro contenitori di Azure dall'interno del portale di Azure.

Accesso al cluster

Ogni cluster AKS richiede l'accesso al registro contenitori in modo che possa eseguire il pull dei livelli di immagine del contenitore. Esistono diversi modi per stabilire l'accesso alle Registro contenitori di Azure. In questa architettura, viene creata un'identità gestita per ogni cluster, a cui viene quindi concesso il ruolo AcrPull nel registro contenitori. Per maggiori informazioni e raccomandazioni sull'uso di identità gestite per l'accesso a Registro contenitori di Azure, vedere l'architettura di riferimento della baseline di AKS.

Questa configurazione viene definita nel file Bicep stamp del cluster, in modo che ogni volta che viene distribuito un nuovo stamp, alla nuova istanza AKS venga concesso l'accesso. Poiché il registro contenitori è una risorsa condivisa, assicurarsi che le distribuzioni includano l'ID risorsa del registro contenitori come parametro.

Monitoraggio di Azure

La funzionalità Informazioni dettagliate sul contenitore Monitoraggio di Azure è lo strumento consigliato per monitorare e comprendere le prestazioni e l'integrità dei carichi di lavoro del cluster e dei contenitori. Informazioni dettagliate sui contenitori usa sia un'area di lavoro Analisi dei log per archiviare i dati di log e Metriche di Monitoraggio di Azure per archiviare i dati numerici delle serie temporali. Le metriche di Prometheus possono essere acquisite anche da Informazioni dettagliate sui contenitori, e i dati possono essere inviati al servizio gestito di Monitoraggio di Azure per Prometheus o ai log di Monitoraggio di Azure. Per maggiori informazioni, vedere l'architettura di riferimento della baseline di AKS.

È inoltre possibile configurare le impostazioni di diagnostica del cluster AKS per raccogliere e analizzare i log delle risorse dai componenti del piano di controllo AKS e inoltrarli a un'area di lavoro Analisi dei log.

Quando si progetta una soluzione di monitoraggio per un'architettura in più aree, è importante considerare l'accoppiamento tra ogni stamp. È possibile distribuire una singola area di lavoro Analisi dei log, condivisa da ogni cluster Kubernetes. Analogamente alle altre risorse condivise, definire lo stamp a livello di area per usare le informazioni relative all'area di lavoro Analisi dei log condivisa a livello globale e connettere ogni cluster a livello di area a tale area di lavoro condivisa. Quando ogni cluster a livello di area genera log di diagnostica in tale singola area di lavoro Analisi dei log, è possibile usare i dati, insieme alle metriche delle risorse, per creare più facilmente report e dashboard che consentono di comprendere come viene eseguita l'intera soluzione multiarea.

Frontdoor di Azure

Frontdoor di Azure viene usato per bilanciare il carico e instradare il traffico a ogni cluster AKS. Frontdoor di Azure abilita anche il routing globale di livello 7. Queste funzionalità sono necessarie per questo scenario.

Configurazione del cluster

Man mano che viene aggiunta ogni istanza AKS a livello di area, il gateway applicazione distribuito insieme al cluster Kubernetes deve essere registrato come origine in Frontdoor di Azure, che lo rende disponibile per il routing. Questa operazione richiede un aggiornamento dell'infrastruttura come asset di codice. In alternativa, questa operazione può essere disaccoppiata dalla configurazione della distribuzione e gestita usando strumenti come CLI di Azure.

Certificati

Frontdoor di Azure non supporta le origini usando certificati autofirmati, anche in ambienti di sviluppo o test. Per abilitare il traffico HTTPS, è necessario creare il certificato TLS/SSL firmato da un'autorità di certificazione (CA). Per informazioni su altre CA supportate da Frontdoor, consultare la sezione Autorità di certificazione consentite per abilitare HTTPS personalizzato in Frontdoor di Azure.

Per i test o per i cluster non di produzione, è consigliabile usare Certbot per creare un certificato Let's Encrypt Authority X3 per ognuno dei gateway applicazione.

Quando si pianifica un cluster di produzione, usare il metodo preferito dell'organizzazione per ottenere i certificati TLS.

Accesso al cluster e identità

Come illustrato nell'architettura di riferimento della baseline di AKS, è consigliabile usare Microsoft Entra ID come provider di identità per i cluster. I gruppi di Microsoft Entra possono quindi essere usati per controllare l'accesso alle risorse del cluster.

Quando si gestiscono cluster multipli, è necessario decidere uno schema di accesso. Le opzioni includono:

• Creare un gruppo di accesso globale a livello di cluster in cui i membri possono accedere a tutti gli oggetti in ogni istanza di Kubernetes nel cluster. Questa opzione fornisce esigenze di amministrazione minime; concede tuttavia privilegi significativi a qualsiasi membro del gruppo.
• Creare un singolo gruppo di accesso per ogni istanza di Kubernetes usata per concedere l'accesso agli oggetti in una singola istanza del cluster. Con questa opzione, il sovraccarico amministrativo aumenta; tuttavia, offre anche un accesso più granulare al cluster.
• Definire controlli di accesso granulari per i tipi di oggetti e gli spazi dei nomi Kubernetes e correlare i risultati a una struttura del gruppo Microsoft Entra. Con questa opzione, il sovraccarico amministrativo aumenta significativamente; fornisce tuttavia un accesso granulare non solo a ogni cluster, ma anche agli spazi dei nomi e alle API Kubernetes presenti in ogni cluster.

Per l'accesso amministrativo, è consigliabile creare un gruppo Microsoft Entra per ogni area. Concedere a ogni gruppo l'accesso completo allo stamp del cluster corrispondente in tale area. I membri di ogni gruppo hanno quindi accesso amministrativo ai cluster corrispondenti.

Per maggiori informazioni sulla gestione dell'accesso al cluster AKS con Microsoft Entra ID, consultare la sezione Integrazione di Microsoft Entra di AKS.

Dati, stato e cache

Quando si usa un set distribuito a livello globale di cluster AKS, prendere in considerazione l'architettura dell'applicazione, del processo o di altri carichi di lavoro che potrebbero essere eseguiti nel cluster. Se i carichi di lavoro basati sullo stato vengono distribuiti tra i cluster, è necessario accedere a un archivio stati? Se un processo viene ricreato altrove nel cluster a causa di un errore, il carico di lavoro o il processo continua ad avere accesso a un archivio stati dipendente o a una soluzione di memorizzazione nella cache? Lo stato può essere archiviato in molti modi, ma è complesso da gestire anche in un singolo cluster Kubernetes. La complessità aumenta quando si eseguono aggiunte in cluster Kubernetes multipli. A causa di problemi di accesso a livello di area e complessità, è consigliabile progettare le applicazioni per l'uso di un servizio di archiviazione stati distribuito a livello globale.

La progettazione di questa architettura non include la configurazione per i problemi di stato. Se si esegue una singola applicazione logica in cluster AKS multipli, è consigliabile progettare il carico di lavoro per usare un servizio dati distribuito a livello globale, ad esempio Azure Cosmos DB. Azure Cosmos DB è un sistema di database distribuito a livello globale che consente di leggere e scrivere dati dalle repliche locali del database e il servizio Cosmos DB gestisce automaticamente la replica geografica. Per maggiori informazioni, consultare Azure Cosmos DB.

Se il carico di lavoro usa una soluzione di memorizzazione nella cache, assicurarsi di progettare i servizi di caching in modo che rimangano funzionali anche durante gli eventi di failover. Assicurarsi che il carico di lavoro stesso sia resiliente al failover correlato alla cache e che le soluzioni di caching siano presenti in tutte le istanze AKS a livello di area.

Ottimizzazione dei costi

Usare il calcolatore dei prezzi di Azure per stimare il costo dei servizi usati nell'architettura. Altre procedure consigliate sono descritte nella sezione Ottimizzazione dei costi in Microsoft Azure Well-Architected Framework e opzioni di configurazione specifiche per l'ottimizzazione dei costi nell'articolo Ottimizzazione dei costi.

Valutare la possibilità di abilitare l'analisi dei costi di AKS per l'allocazione granulare dei costi dell'infrastruttura del cluster da costrutti specifici di Kubernetes.

Passaggi successivi

• Zone di disponibilità di AKS
• Gestione flotta Kubernetes di Azure
• Replica geografica nel servizio Registro Azure Container
• Aree abbinate di Azure

Risorse correlate

• Revisione di Azure Well-Architected Framework per Servizio Azure Kubernetes (AKS)
• Architettura di base per un cluster del servizio Azure Kubernetes (AKS)
• Pipeline di integrazione continua/distribuzione continua per carichi di lavoro basati su contenitori
• Integrazione di Microsoft Entra di AKS
• Documentazione di Frontdoor di Azure
• Documentazione di Azure Cosmos DB