Panoramica della soluzione di ripristino di emergenza attivo/passivo 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. Quando l'area non è più disponibile durante un'emergenza, l'applicazione diventa anche 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.

Questa guida descrive una soluzione di ripristino di emergenza attiva-passiva per AKS. In questa soluzione, distribuiamo due cluster AKS indipendenti e identici in due regioni Azure abbinate, di cui solo uno gestisce attivamente il traffico.

Nota

La procedura seguente è stata esaminata internamente e verificata insieme ai partner Microsoft.

Panoramica della soluzione attiva/passiva

In questo approccio di ripristino di emergenza sono disponibili due cluster del servizio Azure Kubernetes indipendenti distribuiti in due aree di Azure. Tuttavia, solo uno dei cluster gestisce attivamente il traffico in qualsiasi momento. Il cluster secondario (non gestisce attivamente il traffico) contiene gli stessi dati di configurazione e dell'applicazione del cluster primario, ma non accetta traffico a meno che non venga indirizzato da Frontdoor di Azure gestione traffico.

Scenari e configurazioni

Questa soluzione viene implementata al meglio quando si ospitano applicazioni basate su risorse, ad esempio i database, che gestiscono attivamente il traffico in un'area. Negli scenari in cui è necessario ospitare applicazioni senza stato distribuite in entrambe le aree, ad esempio il ridimensionamento orizzontale, è consigliabile prendere in considerazione una soluzione attiva/attiva, perché quella attiva/passiva comporta una latenza aggiuntiva.

Componenti

La soluzione di ripristino di emergenza attivo/passivo usa molti servizi di Azure. Questa architettura di esempio include i componenti seguenti:

Più cluster e regioni: si distribuiscono più cluster AKS, ognuno in una regione di Azure distinta. Durante le normali operazioni, il traffico di rete viene instradato al cluster AKS primario definito nella configurazione di Frontdoor di Azure.

Assegnazione di priorità del cluster configurata: si imposta un livello di priorità compreso tra 1 e 5 per ogni cluster (dove 1 è la priorità più alta e 5 la priorità più bassa). È possibile impostare più cluster sullo stesso livello di priorità e specificare il peso per ogni cluster. Se il cluster primario non è più disponibile, il traffico viene instradato automaticamente all'area successiva selezionata in Frontdoor di Azure. Tutto il traffico deve passare attraverso Frontdoor di Azure per consentire il funzionamento del sistema.

Frontdoor di Azure: Frontdoor di Azure distribuisce il carico e instrada il traffico all'istanza di gateway applicazione di Azure nell'area primaria (il cluster deve essere contrassegnato con priorità 1). In caso di errore dell'area, il servizio reindirizza il traffico al cluster successivo nell'elenco di priorità.

Per altre informazioni, vedere Routing del traffico in base alla priorità.

Coppia hub-spoke: Una coppia hub-spoke viene distribuita per ogni istanza regionale di AKS. I criteri di Gestione firewall di Azure gestiscono le regole del firewall in ogni area.

Key Vault: si esegue il provisioning di un Azure Key Vault in ogni area per archiviare segreti e chiavi.

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 dell'applicazione (regionali)

Un oggetto di distribuzione Kubernetes crea più repliche di un pod (ReplicaSet). Se un pod 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. Le sonde di vitalità possono verificare lo stato dell'applicazione o del processo in esecuzione nel pod. Se il pod non risponde, la probe di liveness rimuove il pod, costringendo il ReplicaSet a creare una nuova istanza.

Per altre informazioni, vedere Kubernetes ReplicaSet.

Pod applicativi (globali)

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 utilizza Azure Container Network Interface (CNI), assicurarsi di disporre di una subnet in grado di supportare tutti gli indirizzi IP dei pod anche in caso di picchi di traffico.
  • Utilizzare il Horizontal Pod Autoscaler per aumentare il numero di repliche dei pod e compensare l'aumento della domanda regionale.
  • Usa il Cluster Autoscaler di AKS per aumentare il numero di nodi Kubernetes e compensare l'aumento della domanda a livello regionale.

Pool di nodi Kubernetes (regionale)

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 AKS in questa soluzione attiva-passiva ed evitare che diventino un singolo punto di guasto a livello di area geografica, usare Azure zone di disponibilità. Le zone di disponibilità assicurano che i nodi del servizio Azure Kubernetes in ogni zona di disponibilità siano fisicamente separati da quelli definiti in un'altra zona di disponibilità.

Pool di nodi Kubernetes (globale)

In caso di guasto regionale completo, Frontdoor di Azure instrada il traffico alle restanti aree operative. Anche in questo caso, assicurarsi di far fronte all'aumento del traffico e delle richieste verso il cluster restante.

Strategia di test di failover

Sebbene attualmente non esistano meccanismi in AKS per rendere indisponibile un'intera area di distribuzione a scopo di test, è possibile usare Azure Chaos Studio Workspaces per simulare un'interruzione di una zona di disponibilità per i pool di nodi del cluster.

Passaggi successivi

Se si sta valutando una soluzione diversa, vedere gli articoli seguenti:

  • Ultimo aggiornamento: