Panoramica della soluzione di disponibilità elevata attiva consigliata per il servizio Azure Kubernetes
Quando si crea un'applicazione nel servizio Azure Kubernetes e si sceglie un'area di Azure durante la creazione di risorse, si tratta di un'app a singola area. In caso di un’emergenza che causa l'indisponibilità dell'area, anche l'applicazione diventa non disponibile. Se si crea una distribuzione identica in un'area di Azure secondaria, l'applicazione diventa meno soggetta a un'emergenza a singola area, che garantisce la continuità aziendale e qualsiasi replica dei dati tra le aree consente di ripristinare l'ultimo stato dell'applicazione.
Anche se esistono più modelli che possono fornire recuperabilità per una soluzione del servizio Azure Kubernetes, questa guida descrive la soluzione di disponibilità elevata attiva consigliata per il servizio Azure Kubernetes. In questa soluzione vengono distribuiti due cluster del servizio Azure Kubernetes indipendenti e identici in due aree di Azure abbinate con entrambi i cluster che gestiscono attivamente il traffico.
Nota
Il caso d'uso seguente può essere considerato una pratica standard all'interno del servizio Azure Kubernetes. È stata esaminata internamente e verificata insieme ai partner Microsoft.
Panoramica della soluzione di disponibilità elevata attiva
Questa soluzione si basa su due cluster del servizio Azure Kubernetes identici configurati per gestire attivamente il traffico. Si inserisce un gestore traffico globale, ad esempio Frontdoor di Azure, davanti ai due cluster per distribuire il traffico tra di essi. È necessario configurare in modo coerente i cluster per ospitare un'istanza di tutte le applicazioni necessarie per il funzionamento della soluzione.
Le zone di disponibilità sono un altro modo per garantire disponibilità elevata e tolleranza di errore per il cluster del servizio Azure Kubernetes nella stessa area. Le zone di disponibilità consentono di distribuire i nodi del cluster in più posizioni isolate all'interno di un'area di Azure. In questo modo, se una zona si arresta a causa di un'interruzione dell'alimentazione, di un errore hardware o di rete, il cluster può continuare a essere eseguito e gestire le applicazioni. Le zone di disponibilità migliorano anche le prestazioni e la scalabilità del cluster, riducendo la latenza e la contesa tra i nodi. Per configurare le zone di disponibilità per il cluster del servizio Azure Kubernetes, è necessario specificare i numeri di zona durante la creazione o l'aggiornamento dei pool di nodi. Per altre informazioni, vedere Informazioni sulle zone di disponibilità di Azure.
Nota
Le zone di disponibilità sono supportate in molte aree. Prendere in considerazione l'uso di aree con zone di disponibilità per offrire maggiore resilienza e disponibilità per i carichi di lavoro. Per altre informazioni, vedere Eseguire il ripristino dopo un'interruzione di servizio a livello di area.
Scenari e configurazioni
Questa soluzione viene implementata al meglio quando si ospitano applicazioni senza stato e/o con altre tecnologie distribuite anche in entrambe le aree, ad esempio il ridimensionamento orizzontale. Negli scenari in cui l'applicazione host dipende da risorse, ad esempio i database, che si trovano attivamente in una sola area, è consigliabile implementare invece una soluzione attiva-passiva per un potenziale risparmio sui costi, in quanto il tempo di inattività attivo-passivo ha più tempo di inattività rispetto all'attivo.
Componenti
La soluzione di disponibilità elevata attiva usa molti servizi di Azure. Questa sezione illustra solo i componenti univoci di questa architettura multi-cluster. Per altre informazioni sui restanti componenti, vedere l'architettura di base del servizio Azure Kubernetes.
Più cluster e aree: si distribuiscono più cluster del servizio Azure Kubernetes, ognuno in un'area di Azure separata. Durante le normali operazioni, la configurazione di Frontdoor di Azure instrada il traffico di rete tra tutte le aree. Se un'area non è più disponibile, il traffico viene instradato all'area con il tempo di caricamento più rapido per l'utente.
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. I criteri di Gestione firewall di Azure gestiscono i criteri firewall in tutte le aree.
Archivio chiavi a livello di area: si effettua il provisioning di Azure Key Vault in ogni area per archiviare i valori sensibili e le chiavi specifiche dell'istanza del servizio Azure Kubernetes e per supportare i servizi presenti in tale area.
Frontdoor di Azure: Frontdoor di Azure bilancia il carico e instrada il traffico a un'istanza del gateway applicazione di Azure 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.
Log Analytics: le istanze di Log Analytics a livello di area archiviano le metriche di rete a livello di area e i log di diagnostica. Un'istanza condivisa archivia le metriche e i 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. Con questa soluzione viene usata una singola istanza di Registro Azure Container per tutte le istanze di Kubernetes nel cluster. La replica geografica per Registro Azure Container consente di replicare le immagini nelle aree di Azure selezionate e di accedere in modo continuativo alle immagini anche in caso di interruzione di un'area.
Processo di failover
Se un servizio o un componente del servizio non è più disponibile in un'area, il traffico deve essere indirizzato a un'area in cui il servizio è disponibile. Un'architettura in più aree include molti punti di errore diversi. In questa sezione vengono illustrati i potenziali punti di errore.
Pod applicazione (area)
Un oggetto di distribuzione Kubernetes crea più repliche di un pod (ReplicaSet). Se non è disponibile, il traffico viene instradato tra le repliche rimanenti. Il ReplicaSet Kubernetes tenta di mantenere operativo il numero specificato di repliche. Se un'istanza diventa inattiva, è necessario ricreare una nuova istanza. I probe di attività possono controllare lo stato dell'applicazione o del processo in esecuzione nel pod. Se il pod non risponde, il probe di attività rimuove il pod, che forza il ReplicaSet per 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 di integrità rimanenti. I cluster e i pod Kubernetes in queste aree continuano a gestire le richieste. Per compensare l'aumento del traffico e delle richieste verso il cluster rimanente, tenere presente le indicazioni seguenti:
- Assicurarsi che le risorse di rete e di calcolo siano ridimensionate correttamente per assorbire qualsiasi aumento improvviso del traffico a causa del failover dell'area. Ad esempio, quando si usa l'interfaccia di rete di Azure Container, assicurarsi di avere una subnet in grado di supportare tutti gli indirizzi IP dei pod con un carico di traffico con picchi di traffico.
- 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.
Pool di nodi Kubernetes (a livello di area)
In alcuni casi, l'errore localizzato può verificarsi per le risorse di calcolo, ad esempio l'alimentazione non disponibile in un singolo rack di server di Azure. Per proteggere i nodi del servizio Azure Kubernetes da un singolo errore a livello di area, usare zone di disponibilità di Azure. Le zone di disponibilità assicurano che i nodi del servizio Azure Kubernetes in ogni zona di disponibilità siano fisicamente separati da quelli definiti in altre zone di disponibilità.
Pool di nodi Kubernetes (globale)
In un errore completo a livello di area, Frontdoor di Azure instrada il traffico alle aree integre rimanenti. Anche in questo caso, assicurarsi di compensare l'aumento del traffico e delle richieste verso il cluster rimanente.
Strategia di test di failover
Sebbene non siano attualmente disponibili meccanismi all'interno del servizio Azure Kubernetes per arrestare un'intera area di distribuzione a scopo di test, Azure Chaos Studio offre la possibilità di creare un esperimento chaos nel cluster.
Passaggi successivi
Se si sta valutando una soluzione diversa, vedere gli articoli seguenti: