Baseline del servizio Azure Kubernetes per cluster con più aree

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

Questa architettura si basa sull'architettura di base del servizio Azure Kubernetes, punto di partenza consigliato da Microsoft per l'infrastruttura del servizio Azure Kubernetes. La baseline del servizio Azure Kubernetes illustra in dettaglio le funzionalità structurali, ad esempio le ID dei carichi di lavoro di Microsoft Entra, le restrizioni in ingresso e in 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 più aree.

Architettura

Scaricare un file di Visio di questa architettura.

Un'implementazione di riferimento di questa architettura è disponibile in GitHub.

Componenti

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

• Vengono distribuiti più cluster/più aree del servizio Azure Kubernetes, ognuno in un'area di Azure separata. Durante le normali operazioni, il traffico di rete viene instradato 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.
• Rete hub-spoke per area Viene distribuita una coppia di rete hub-spoke a livello di area per ogni istanza del servizio Azure Kubernetes a livello di area. Firewall di Azure Manager vengono usati per gestire i criteri firewall in tutte le aree.
• Viene effettuato il provisioning dell'archivio chiavi di Azure Key Vault a livello di area in ogni area per l'archiviazione di valori sensibili e chiavi specifiche per l'istanza del servizio Azure Kubernetes e i servizi di supporto disponibili in tale area.
• Frontdoor di Azure frontdoor di Azure viene usato per bilanciare il carico e instradare il traffico a un'istanza del gateway di app Azure lication a livello di area, che si trova davanti a ogni cluster del servizio Azure Kubernetes. Frontdoor di Azure consente il routing globale di livello sette, entrambi necessari per questa architettura di riferimento.
• Le istanze di Log Analytics a livello di area di Log Analytics vengono usate per archiviare le metriche di rete a livello di area e i log di diagnostica. Inoltre, un'istanza di Log Analytics condivisa viene usata per archiviare metriche e log di diagnostica per tutte le istanze del servizio Azure Kubernetes.
• Registro Contenitori Le immagini del contenitore per il carico di lavoro vengono archiviate in un registro contenitori gestito. In questa architettura viene usata una singola Registro Azure Container per tutte le istanze di Kubernetes nel cluster. La replica geografica per Registro Azure Container consente la replica delle immagini nelle aree di Azure selezionate e l'accesso continuo alle immagini anche in caso di interruzione di un'area.

Schemi progettuali

Questa architettura di riferimento usa due modelli di progettazione cloud. Nodo geografico (geodes) in cui qualsiasi area può gestire qualsiasi richiesta e stamp di distribuzione in cui vengono distribuite più copie indipendenti di un'applicazione o di un componente dell'applicazione da un'unica origine (modello di distribuzione).

Considerazioni sul modello di nodo geografico

Quando si selezionano aree per distribuire ogni cluster del servizio Azure Kubernetes, 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 replica 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 del servizio Azure Kubernetes.

All'interno di ogni area, i nodi nei pool di nodi del servizio Azure Kubernetes 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 altre informazioni sulle zone di disponibilità e del servizio Azure Kubernetes, incluso un elenco di aree supportate, vedere Zone di disponibilità del servizio Azure Kubernetes.

Considerazioni sul timbro di distribuzione

Quando si gestisce un cluster del servizio Azure Kubernetes in più aree, più istanze del servizio Azure Kubernetes vengono distribuite in più aree. Ognuna di queste istanze è considerata un timbro. In caso di errore a livello di area o la necessità di aggiungere maggiore capacità e/o presenza a livello di area per il cluster, potrebbe essere necessario creare una nuova istanza di stamp. Quando si seleziona un processo per la creazione e la gestione dei francobolli di distribuzione, è importante considerare quanto segue:

• Selezionare la tecnologia appropriata per le definizioni di stamp che consente la configurazione generalizzata, ad esempio 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 attivo/attivo, considerare il modo in cui il traffico viene bilanciato tra ogni timbro
• Man mano che i francobolli vengono aggiunti e rimossi dalla raccolta, prendere in considerazione problemi di capacità e costi
• Si consideri come ottenere visibilità e/o monitorare la raccolta di timbri come singola unità.

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

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 Azure Kubernetes Fleet Manager 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 quotidiane 2 e le 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 set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Framework ben progettato di Microsoft Azure.

Distribuzione del cluster e bootstrap

Quando si distribuiscono più cluster Kubernetes 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 di Kubernetes sia il più possibile identica. È consigliabile prendere in considerazione le strategie per l'aumento e l'aumento del numero di istanze di Kubernetes aggiungendo o rimuovendo altre istanze di Kubernetes. Si vuole che la progettazione e il piano di distribuzione e configurazione tengano conto degli errori a livello di area o di altri scenari comuni.

Definizione del cluster

Sono disponibili molte opzioni per la distribuzione di un cluster servizio Azure Kubernetes. Le portale di Azure, l'interfaccia della riga di comando di Azure e il modulo Azure PowerShell sono tutte opzioni decenti per la distribuzione di cluster del servizio Azure Kubernetes singoli o non associati. Questi metodi, tuttavia, possono presentare problemi quando si lavora con molti cluster del servizio Azure Kubernetes strettamente associati. Ad esempio, l'uso del portale di Azure apre l'opportunità di mancata configurazione a causa di passaggi mancanti o opzioni di configurazione non disponibili. Inoltre, la distribuzione e la configurazione di molti cluster che usano il portale è un processo tempestivo che richiede l'attenzione di uno o più tecnici. È possibile costruire 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 lavora con molte istanze del servizio Azure Kubernetes, è consigliabile prendere in considerazione l'infrastruttura come soluzioni di codice, ad esempio modelli di Azure Resource Manager, modelli Bicep o configurazioni Terraform. L'infrastruttura come soluzioni di codice offre una soluzione di distribuzione automatizzata, scalabile e idempotente. Questa architettura di riferimento include un modello di Resource Manager per le soluzioni condivise e un altro per i cluster del servizio Azure Kubernetes e i servizi regionali. Se si usa l'infrastruttura come codice, è possibile definire un timbro 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 un timbro quasi identico in qualsiasi area.

Il costo dello sviluppo e della gestione dell'infrastruttura come asset di codice può essere costoso. In alcuni casi, ad esempio quando viene distribuito un numero statico/fisso di istanze del servizio Azure Kubernetes, il sovraccarico dell'infrastruttura come codice potrebbe superare i vantaggi. Per questi casi, l'uso di un approccio più imperativo, ad esempio con gli strumenti da riga di comando o anche un approccio manuale, è ok.

Distribuzione cluster

Dopo aver definito la definizione del timbro 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 codice/controllo del codice sorgente della distribuzione
• Cronologia e registrazione della distribuzione

Man mano che vengono aggiunti o rimossi nuovi timbri dal cluster globale, la pipeline di distribuzione deve essere aggiornata per mantenere la coerenza. Nell'implementazione di riferimento ogni area viene distribuita come singolo passaggio all'interno di un flusso di lavoro di GitHub Action (esempio). Questa configurazione è semplice in quanto 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 nell'usare la logica 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 che ogni stamp del cluster non è descritto in modo esplicito nella pipeline di distribuzione. Il vantaggio positivo è che l'aggiunta o la rimozione di indicatori cluster dalla pipeline diventa un semplice aggiornamento all'elenco delle aree desiderate.

Inoltre, la rimozione di un timbro del cluster dalla pipeline di distribuzione non garantisce necessariamente che venga rimossa anche. A seconda della soluzione di distribuzione e della configurazione, potrebbe essere necessario un passaggio aggiuntivo per assicurarsi che le istanze del servizio Azure Kubernetes siano state rimosse in modo appropriato.

Bootstrap del cluster

Dopo aver distribuito 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. È anche 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

Invece di 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. Questa implementazione usa l'estensione Flux per il servizio Azure Kubernetes per abilitare il bootstrap automatico dei cluster e immediatamente dopo la distribuzione dei cluster.

GitOps è più dettagliato nell'architettura di riferimento della baseline del servizio Azure Kubernetes. Il punto importante è che l'uso di un approccio basato su GitOps per la configurazione garantisce che ogni istanza di Kubernetes sia configurata in modo analogo senza sforzo personalizzato. Questo diventa ancora più importante man mano che le dimensioni della tua flotta aumentano.

Criteri di Azure

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

Criteri di Azure è abilitato in questa implementazione di riferimento quando vengono creati i cluster del servizio Azure Kubernetes e assegna l'iniziativa restrittiva in modalità di controllo per ottenere visibilità sulla mancata conformità. L'implementazione imposta anche più criteri che non fanno parte di alcuna iniziativa predefinita. Questi criteri vengono impostati in modalità Nega. È 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. L'implementazione di riferimento associata a questa architettura usa un modello di Resource Manager per assegnare criteri al gruppo di risorse in cui viene distribuito ogni cluster del servizio Azure Kubernetes. Man mano che aumenta il footprint del cluster globale, si ottengono molti criteri duplicati. È anche 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 del servizio Azure Kubernetes nell'ambito di una sottoscrizione e/o a tutte le sottoscrizioni presenti in un gruppo di gestione.

Quando si progettano criteri per più cluster del servizio Azure Kubernetes, prendere in considerazione gli elementi seguenti:

• I criteri che devono essere applicati a livello globale a tutte le istanze del servizio Azure Kubernetes possono essere applicati a un gruppo di gestione o a una sottoscrizione
• L'inserimento di ogni cluster a livello di area nel proprio gruppo di risorse consente criteri specifici dell'area applicati al gruppo di risorse

Vedere Cloud Adoption Framework resource organization (Organizzazione delle risorse di Cloud Adoption Framework) per i materiali che consentiranno di definire una strategia di gestione dei criteri.

Distribuzione del carico di lavoro

Oltre alla configurazione dell'istanza del servizio Azure Kubernetes, prendere in considerazione il carico di lavoro distribuito in ogni istanza o stamp a livello di area. Le soluzioni di distribuzione o le pipeline richiederanno la configurazione per ogni stamp a livello di area. Man mano che vengono aggiunti altri stamp al cluster globale, il processo di distribuzione deve essere esteso o 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 più indicatori cluster.
• Usare una singola pipeline di distribuzione continua configurata per distribuire il carico di lavoro in tutti i timbri del cluster.
• Specificare i dettagli dell'istanza specifica dello stamp come parametri di distribuzione.
• Valutare il modo in cui la registrazione diagnostica dell'applicazione e la traccia distribuita sono configurate per l'osservabilità a livello di applicazione.

Disponibilità e failover

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

Pod applicazione (area)

Un oggetto di distribuzione Kubernetes viene usato per creare più repliche di un pod (ReplicaSet). Se non è disponibile, il traffico viene instradato tra i rimanenti. Il set di repliche Kubernetes tenta di mantenere operativo il numero specificato di repliche. Se un'istanza diventa inattiva, verrà ricreata una nuova istanza. Infine, i probe di attività possono essere usati per controllare lo stato dell'applicazione o del processo in esecuzione nel pod. Se il servizio non risponde, il probe di attività rimuoverà il pod, che forza replicaSet a creare una nuova istanza.

Per altre informazioni, vedere Kubernetes ReplicaSet.

Pod applicazione (globale)

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

Prestare attenzione a questa situazione per compensare l'aumento del traffico o delle richieste verso il cluster rimanente. Alcuni aspetti da considerare:

• Assicurarsi che le risorse di rete e di calcolo siano di dimensioni appropriate per assorbire qualsiasi aumento improvviso del traffico a causa del failover dell'area. Ad esempio, quando si usa Azure CNI, assicurarsi di avere una subnet in grado di supportare tutti gli INDIRIZZI IP pod con un carico di traffico con picchi di traffico.
• Utilizzare Horizontal Pod Autoscaler per aumentare il numero di repliche pod per compensare l'aumento della domanda a livello di area.
• Usare il ridimensionamento automatico 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 altre informazioni, vedere Scalabilità automatica orizzontale dei pod e scalabilità automatica del cluster del servizio Azure Kubernetes.

Pool di nodi Kubernetes (area)

In alcuni casi, l'errore localizzato può verificarsi per le risorse di calcolo, ad esempio se l'alimentazione non è disponibile in un singolo rack di server di Azure. Per proteggere i nodi del servizio Azure Kubernetes da diventare un singolo errore a livello di area, usare le zone di disponibilità di Azure. L'uso delle zone di disponibilità garantisce che i nodi del servizio Azure Kubernetes in una determinata zona di disponibilità siano fisicamente separati da quelli definiti in un'altra zona di disponibilità.

Per altre informazioni, vedere Servizio Azure Kubernetes e zone di disponibilità di Azure.

Pool di nodi Kubernetes (globale)

In un errore completo a livello di area, Frontdoor di Azure instrada il traffico alle aree rimanenti e integre. Anche in questo caso, prestare attenzione a compensare l'aumento del traffico o delle richieste verso il cluster rimanente.

Per altre informazioni, vedere Frontdoor di Azure.

Topologia di rete

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

• Implementare un hub-spoke per ogni istanza del servizio Azure Kubernetes a livello di area, in cui viene eseguito il peering delle reti virtuali hub-spoke.
• Instradare tutto il traffico in uscita attraverso un'istanza di Firewall di Azure trovata in ogni rete hub a livello di area. Usare i criteri di Firewall di Azure Manager per gestire i criteri firewall in tutte le aree.
• Se si verifica un errore a livello di area, seguire il ridimensionamento IP trovato nell'architettura di riferimento della baseline del servizio Azure Kubernetes e consentire più indirizzi IP per le operazioni di scalabilità di nodi e pod.

Gestione del traffico

Con l'architettura di riferimento della baseline del servizio Azure Kubernetes, il traffico del carico di lavoro viene indirizzato direttamente a un'istanza del gateway di app Azure lication, quindi inoltrata alle risorse di ingresso del servizio di bilanciamento del carico back-end/servizio Azure Kubernetes. Quando si usano più cluster, le richieste client vengono instradate tramite un'istanza di Frontdoor di Azure, che instrada all'istanza del gateway di app Azure lication.

Scaricare un file di Visio di questo diagramma.

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

2. Frontdoor inoltra la richiesta all'istanza di gateway applicazione appropriata selezionata, che funge da punto di ingresso per il timbro regionale. Il traffico scorre su Internet e viene crittografato da Frontdoor di Azure. 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à Source consente di impostare un tag di 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 Frontdoor per back-end X-Azure-FDID per assicurarsi che l'istanza di gateway applicazione accetti solo il traffico dall'istanza di Frontdoor. Per altre informazioni sulle intestazioni di Frontdoor, vedere Supporto del protocollo per le intestazioni HTTP in Frontdoor di Azure.

Considerazioni sulle risorse condivise

Anche se l'attenzione di questa architettura di riferimento riguarda la distribuzione di più istanze di Kubernetes in più aree di Azure, ha senso avere alcune risorse condivise in tutte le istanze. Implementazione di riferimento a più aree del servizio Azure Kubernetes usando un singolo modello di Resource Manager per distribuire tutte le risorse condivise e quindi un'altra 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 del servizio Azure Kubernetes.

Registro Container

Registro Azure Container viene usato in questa architettura di riferimento per fornire servizi di immagine del contenitore (pull). Quando si lavora con Registro Azure Container in una distribuzione di cluster in più aree, prendere in considerazione gli elementi seguenti.

Disponibilità a livello geografico

Il posizionamento di un registro contenitori in ogni area in cui viene distribuito un cluster del servizio Azure Kubernetes consente operazioni di chiusura della rete, consentendo trasferimenti di livello immagine veloci e affidabili. Disporre di più endpoint servizio immagine per garantire la disponibilità quando i servizi a livello di area non sono disponibili. L'uso della funzionalità di replica geografica dei registri contenitori di Azure consente di gestire un'istanza del Registro Container replicata in più aree.

L'implementazione di riferimento a più aree del servizio Azure Kubernetes ha creato una singola istanza del Registro Container e le repliche di questa istanza in ogni area del cluster. Per altre informazioni sulla replica Registro Azure Container, vedere Replica geografica in Registro Azure Container.

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

Accesso al cluster

Ogni istanza del servizio Azure Kubernetes richiede l'accesso per il pull dei livelli di immagine dal Registro Azure Container. Esistono diversi modi per stabilire l'accesso a Registro Azure Container. Questa architettura di riferimento usa un'identità gestita di Azure per ogni cluster, a cui viene quindi concesso il ruolo AcrPull nell'istanza del Registro Container. Per altre informazioni e consigli sull'uso di identità gestite per l'accesso al Registro Container, vedere l'architettura di riferimento della baseline del servizio Azure Kubernetes.

Questa configurazione viene definita nel modello arm del cluster stamp in modo che ogni volta che viene distribuito un nuovo stamp, alla nuova istanza del servizio Azure Kubernetes viene concesso l'accesso. Poiché registro contenitori è una risorsa condivisa, assicurarsi che il modello di stamp di distribuzione possa usare e usare i dettagli necessari, in questo caso l'ID risorsa del Registro Contenitori.

Monitoraggio di Azure

La funzionalità Informazioni dettagliate sui contenitori di 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 Log Analytics per archiviare i dati di log che le metriche di Monitoraggio di Azure per archiviare i dati numerici delle serie temporali. Le metriche di Prometheus possono anche essere raccolte da Informazioni dettagliate contenitore e inviare i dati al servizio gestito di Monitoraggio di Azure per Prometheus o ai log di Monitoraggio di Azure.

È anche possibile configurare le impostazioni di diagnostica del cluster del servizio Azure Kubernetes per raccogliere e analizzare i log delle risorse dai componenti del piano di controllo del servizio Azure Kubernetes e inoltrare a un'area di lavoro Log Analytics.

Servizio Azure Kubernetes Per altre informazioni, vedere l'architettura di riferimento della baseline del servizio Azure Kubernetes.

Quando si considera il monitoraggio per un'implementazione tra aree, ad esempio questa architettura di riferimento, è importante considerare l'accoppiamento tra ogni stamp. In questo caso, considerare ogni timbro un componente di una singola unità (cluster a livello di area). L'implementazione di riferimento del servizio Azure Kubernetes in più aree usa una singola area di lavoro Log Analytics, condivisa da ogni cluster Kubernetes. Analogamente alle altre risorse condivise, definire il timbro a livello di area per usare le informazioni relative all'area di lavoro Log Analytics singola e connettere ogni cluster.

Ora che ogni cluster a livello di area genera log di diagnostica in una singola area di lavoro Log Analytics, questi dati, insieme alle metriche delle risorse, possono essere usati per creare report e dashboard più facilmente che rappresentano l'intero cluster globale.

Frontdoor di Azure

Frontdoor di Azure viene usato per bilanciare il carico e instradare il traffico a ogni cluster del servizio Azure Kubernetes. Frontdoor di Azure consente il routing globale di livello sette, entrambi necessari per questa architettura di riferimento.

Configurazione del cluster

Man mano che vengono aggiunte istanze del servizio Azure Kubernetes a livello di area, il gateway applicazione distribuito insieme al cluster Kubernetes deve essere registrato come back-end frontdoor per il routing appropriato. Questa operazione richiede un aggiornamento dell'infrastruttura come asset di codice. In alternativa, questa operazione può essere disaccoppiata dalla configurazione della distribuzione e gestita con strumenti come l'interfaccia della riga di comando di Azure. La pipeline di distribuzione delle implementazioni di riferimento incluse usa un passaggio distinto dell'interfaccia della riga di comando di Azure per questa operazione.

Certificati

Frontdoor non supporta i certificati autofirmato anche negli ambienti di sviluppo/test. Per abilitare il traffico HTTPS, è necessario creare il certificato TLS/SSL firmato da un'autorità di certificazione (CA). L'implementazione di riferimento usa Certbot per creare un certificato Let's Encrypt Authority X3. Quando si pianifica un cluster di produzione, usare il metodo preferito dell'organizzazione per ottenere i certificati TLS.

Per informazioni su altre ca supportate da Frontdoor, vedere Autorità di certificazione consentite per abilitare HTTPS personalizzato in Frontdoor di Azure.

Accesso al cluster e identità

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

Quando si gestiscono più cluster, è 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 di Azure Directory. 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 all'interno di ogni cluster.

Con l'implementazione di riferimento inclusa, vengono creati due gruppi di Microsoft Entra per l'accesso amministratore. Questi gruppi vengono specificati in fase di distribuzione del cluster usando il file dei parametri di distribuzione. I membri di ogni gruppo hanno accesso completo al timbro del cluster corrispondente.

Per altre informazioni sulla gestione dell'accesso al cluster del servizio Azure Kubernetes con Microsoft Entra ID, vedere Integrazione di Microsoft Entra nel servizio Azure Kubernetes.

Dati, stato e cache

Quando si usa un cluster distribuito a livello globale di istanze del servizio Azure Kubernetes, prendere in considerazione l'architettura dell'applicazione, del processo o di altri carichi di lavoro che potrebbero essere eseguiti nel cluster. Poiché il carico di lavoro basato su stato viene distribuito nel cluster, sarà 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 continuerà ad avere accesso a un archivio di stato o a una soluzione di memorizzazione nella cache dipendenti? Lo stato può essere raggiunto in molti modi; Tuttavia, può essere complesso in un singolo cluster Kubernetes. La complessità aumenta quando si aggiunge in più istanze di Kubernetes in cluster. 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.

L'implementazione di riferimento multi-cluster non include una dimostrazione o una configurazione per problemi di stato. Se si eseguono applicazioni tra istanze del servizio Azure Kubernetes in cluster, è 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. Per altre informazioni, vedere Azure Cosmos DB.

Se il carico di lavoro usa una soluzione di memorizzazione nella cache, assicurarsi che sia progettato in modo che i servizi di memorizzazione nella cache rimangano funzionali. A tale scopo, assicurarsi che il carico di lavoro stesso sia resiliente al failover correlato alla cache e che le soluzioni di memorizzazione nella cache siano presenti in tutte le istanze del servizio Azure Kubernetes a livello di area.

Ottimizzazione dei costi

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

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

Passaggi successivi

• Zone di disponibilità del servizio Azure Kubernetes
• Azure Kubernetes Fleet Manager
• 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 (servizio Azure Kubernetes AKS)
• Pipeline di integrazione continua/distribuzione continua per carichi di lavoro basati su contenitori
• Integrazione di Microsoft Entra del servizio Azure Kubernetes
• Documentazione di Frontdoor di Azure
• Documentazione di Azure Cosmos DB