Panoramica della soluzione a freddo 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 illustra una soluzione di raffreddamento passivo per AKS. In questa soluzione vengono distribuiti due cluster del servizio Azure Kubernetes indipendenti e identici in due aree di Azure abbinate con un solo cluster che gestisce attivamente il traffico quando l'applicazione è necessaria.

Nota

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

Panoramica della soluzione a freddo passivo

In questo approccio, vengono distribuiti due cluster AKS indipendenti in due regioni di Azure. Quando l'applicazione è necessaria, il cluster passivo viene attivato per ricevere traffico. Se il cluster passivo diventa inattivo, è necessario attivare manualmente il cluster a freddo per assumere il flusso del traffico. È possibile impostare questa condizione tramite un input manuale ogni volta o per specificare un determinato evento.

Scenari e configurazioni

Questa soluzione viene implementata al meglio come carico di lavoro "da usare in base alle esigenze", utile per gli scenari che richiedono l'esecuzione dei carichi di lavoro in orari specifici del giorno o eseguiti su richiesta. I casi d'uso di esempio per un approccio a freddo passivo includono:

  • Un’azienda di produzione che deve eseguire una simulazione complessa e a elevato utilizzo di risorse in un set di dati di grandi dimensioni. In questo caso, il cluster passivo si trova in un'area cloud che offre servizi di elaborazione e archiviazione ad alte prestazioni. Il cluster passivo viene usato solo quando la simulazione viene attivata dall'utente o da una pianificazione. Se il cluster non funziona al momento dell'attivazione, il cluster a freddo può essere usato come backup e il carico di lavoro può essere eseguito su di esso.
  • Un'agenzia governativa che deve mantenere un backup dei sistemi e dei dati critici in caso di attacchi informatici o calamità naturali. In questo caso, il cluster passivo si trova in una posizione sicura e isolata che non è accessibile al pubblico.

Componenti

La soluzione di ripristino di emergenza a freddo 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. Quando l'app è necessaria, il cluster passivo viene attivato per ricevere il traffico di rete.

Key Vault: si esegue il provisioning di un Azure Key Vault in ogni area geografica 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.

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

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 il cluster passivo non funziona correttamente a causa di un problema nella specifica area di Azure, è possibile attivare il cluster a freddo e reindirizzare tutto il traffico all'area del cluster. È possibile usare questo processo mentre il cluster passivo viene disattivato fino a quando non inizia a funzionare di nuovo. Il cluster a freddo può richiedere alcuni minuti per essere online, perché è stato disattivato e deve completare il processo di installazione. Questo approccio non è ideale per le applicazioni sensibili al tempo. In tal caso, consigliamo di valutare un failover attivo-attivo.

Pod applicativi (regionali)

Un oggetto di distribuzione Kubernetes crea più repliche di un pod (ReplicaSet). Se una replica 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, la probe di vitalità 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 che possa supportare tutti gli indirizzi IP dei pod anche in presenza di picchi di traffico.
  • Utilizza il Horizontal Pod Autoscaler per aumentare il numero di repliche dei pod e compensare l'aumento della domanda a livello regionale.
  • Usare Cluster Autoscaler di AKS per aumentare il numero di nodi dell'istanza Kubernetes e compensare l'aumento della domanda regionale.

Pool di nodi Kubernetes (regionali)

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 di AKS dal rischio di un singolo punto di errore a livello di area geografica, usa Azure zone di disponibilità. Le zone di disponibilità assicurano che i nodi AKS in ogni zona di disponibilità siano fisicamente separati da quelli presenti nelle altre zone di disponibilità.

Pool di nodi Kubernetes (globale)

In caso di un'interruzione completa a livello di area geografica, Frontdoor di Azure instrada il traffico verso le aree geografiche 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 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: