Affidabilità nel Gateway applicativo per contenitori di Azure

gateway applicazione di Azure for Containers è un servizio gestito di bilanciamento del carico a livello di applicazione (livello 7) e di gestione dinamica del traffico per i carichi di lavoro in esecuzione in Kubernetes. Instrada le richieste in ingresso alle destinazioni back-end nel cluster.

Quando si usa Azure, l'affidabilità è una responsabilità condivisa. Microsoft offre una gamma di funzionalità per supportare la resilienza e il ripristino. L'utente è responsabile della comprensione del funzionamento di tali funzionalità all'interno di tutti i servizi usati e della selezione delle funzionalità necessarie per soddisfare gli obiettivi aziendali e gli obiettivi di tempo di attività.

Questo articolo descrive come gateway applicazione di Azure per contenitori gestisce gli errori temporanei, gli errori della zona di disponibilità, gli errori estesi all'intera area e la manutenzione del servizio. Vengono inoltre descritte le opzioni di backup e ripristino e le informazioni chiave sul contratto di servizio.

Raccomandazioni per la distribuzione di produzione per l'affidabilità

Gateway applicazione per contenitori è a disponibilità elevata per impostazione predefinita. Per i carichi di lavoro di produzione:

Per un'architettura di esempio e indicazioni su topologia, flusso di traffico, affidabilità, sicurezza e operazioni, vedere Distribuire Application Gateway for Containers in servizio Azure Kubernetes.

Panoramica dell'architettura di affidabilità

Questa sezione descrive alcuni degli aspetti importanti del funzionamento del servizio più rilevanti dal punto di vista dell'affidabilità. La sezione presenta l'architettura logica, che include alcune delle risorse e delle funzionalità distribuite e usate. Illustra anche l'architettura fisica, che fornisce informazioni dettagliate sul funzionamento del servizio sotto le quinte.

Architettura logica

Una distribuzione di Application Gateway for Containers include risorse in Azure e nel cluster Kubernetes.

• Azure risorse: il piano di controllo orchestra la configurazione proxy del gateway in base alla configurazione. Il data plane gestito da Azure viene eseguito all'esterno del cluster ed elabora il traffico dell'applicazione.
• Risorse kubernetes: È possibile definire il routing e altre configurazioni usando le risorse Kubernetes. Il controller ALB viene eseguito nel cluster, controlla tali risorse e propaga la configurazione ad Application Gateway for Containers in Azure.

È possibile scegliere tra due strategie di distribuzione. Con la strategia Bring Your Own (BYO) è possibile gestire il ciclo di vita di Application Gateway for Containers, l'associazione e le risorse front-end tramite gli strumenti di Azure. Con la strategia gestita dal controller ALB, il controller ALB gestisce il ciclo di vita di tali risorse Azure in base alle risorse kubernetes definite.

Per una descrizione completa dei componenti, vedere componenti di Application Gateway for Containers.

Dopo aver distribuito e configurato Application Gateway for Containers, instrada le richieste in ingresso alle destinazioni back-end, che rappresentano l'applicazione in esecuzione in Kubernetes.

Se il controller ALB o il piano di controllo non è disponibile, il piano dati continua a elaborare il traffico usando l'ultima configurazione applicata correttamente. Durante l'interruzione, gli aggiornamenti della configurazione non vengono propagati e il servizio non può impostare la configurazione necessaria per gli eventi di scalabilità orizzontale.

Architettura fisica

Azure gestisce e ridimensiona automaticamente l'infrastruttura del data plane in base al traffico dell'applicazione. Application Gateway for Containers viene sempre distribuito in una configurazione a disponibilità elevata: nelle aree che supportano le zone di disponibilità, i gateway sono con ridondanza della zona; nelle aree che non supportano le zone di disponibilità, Azure usa i set di disponibilità.

Resilienza a errori temporanei

Gli errori temporanei sono errori brevi e intermittenti nei componenti. Si verificano spesso in un ambiente distribuito come il cloud e fanno parte delle normali operazioni. Gli errori temporanei si correggono dopo un breve periodo di tempo. È importante che le applicazioni possano gestire gli errori temporanei, in genere ritentando le richieste interessate.

Tutte le applicazioni ospitate nel cloud devono seguire le indicazioni sulla gestione degli errori temporanei di Azure quando comunicano con qualsiasi API, database e altri componenti ospitati nel cloud. Per ulteriori informazioni, vedi Raccomandazioni per la gestione di errori temporanei.

Quando si usa il gateway applicazione per contenitori, tenere in considerazione le seguenti pratiche consigliate:

• Implementare la logica di ripetizione dei tentativi. Configurare i client per ripetere le richieste dopo errori di connessione temporanei.

• Configurare probe di integrità con tolleranza. Se si configurano controlli di integrità personalizzati, impostare la soglia di stato non integro per tollerare errori temporanei. La soglia di stato non integro specifica il numero di probe consecutivi non riusciti che fanno contrassegnare la destinazione di back-end come non integra. Il probe di integrità predefinito usa una soglia di non integrità di tre probe, che consente di evitare che un singolo errore transitorio del probe contrassegni il back-end come non integro.

Resilienza ai guasti delle zone di disponibilità

Le zone di disponibilità sono gruppi di data center separati fisicamente all'interno di un'area di Azure. In caso di guasto in una zona, i servizi possono passare a una delle zone restanti.

Quando si distribuisce gateway applicazione per contenitori in un'area di Azure che supporta le zone di disponibilità, Microsoft configura automaticamente il piano di controllo e il piano dati come con ridondanza della zona in più zone. Non è possibile selezionare le zone usate dal servizio.

Requisiti

Supporto per l'area geografica: Per usare la ridondanza della zona, scegliere un'area geografica che supporti sia Application Gateway for Containers che le zone di disponibilità. Controllare la disponibilità a livello di area geografica di Application Gateway for Containers e confrontarla con l'elenco delle aree geografiche che supportano le zone di disponibilità.

Considerations

Responsabilità condivisa con la piattaforma Kubernetes: Microsoft gestisce il reindirizzamento del traffico per Application Gateway for Containers durante un guasto della zona. Per Servizio Azure Kubernetes (AKS), Microsoft gestisce il piano di controllo Kubernetes. Si è responsabili della configurazione della resilienza della zona per i pool di nodi del cluster e di altre risorse gestite e del comportamento delle applicazioni durante un'interruzione della zona.

• Cluster: configurare i pool di nodi del servizio Azure Kubernetes e altre risorse del cluster associate alle zone che gestisci da distribuire tra zone di disponibilità. Il servizio Azure Kubernetes gestisce il piano di controllo; vedere Configurare le zone di disponibilità per i pool di nodi del servizio Azure Kubernetes.

• Carichi di lavoro: si è responsabili della distribuzione di più repliche pod, della distribuzione tra zone e del garantire che i carichi di lavoro back-end siano disponibili e integri per gestire il traffico durante un'interruzione della zona. È possibile usare pool di nodi che si estendono su zone di disponibilità, vincoli di distribuzione della topologia e anti-affinità dei pod.

• Oggetti di configurazione Kubernetes: Application Gateway for Containers usa oggetti di configurazione Kubernetes archiviati dall'API del cluster. La disponibilità dipende dal piano di controllo Kubernetes e dalla configurazione che gestisci nel tuo cluster.

• Controller ALB: per riconciliare la configurazione, si distribuisce il controller ALB nel cluster Kubernetes. Non fa parte del percorso dati di Application Gateway for Containers.

  Il controller ALB esegue due repliche, con una che funge da leader e l'altra come secondaria. Se il leader non è più disponibile, il secondario può diventare leader e continuare a propagare la configurazione. Entrambe le repliche possono essere eseguite nella stessa zona di disponibilità, a seconda della pianificazione del cluster. Si è responsabili della configurazione dei pod del cluster e del controller per la resilienza tra zone. Usare i vincoli di diffusione della topologia pod o l'anti-affinità dei pod per distribuire le repliche tra le zone. Per altre informazioni, vedere Configurare le zone di disponibilità per i pool di nodi di AKS.

Cost

Il supporto della zona di disponibilità per Application Gateway for Containers non comporta costi aggiuntivi oltre i prezzi del servizio standard. Per informazioni dettagliate sui prezzi, vedere prezzi gateway applicazione di Azure.

Configurare il supporto delle zone di disponibilità

Quando si distribuisce un nuovo gateway in un'area supportata, per impostazione predefinita è con ridondanza della zona. Non è necessario abilitare la ridondanza della zona nelle risorse Azure.

Si è responsabili della configurazione del cluster Kubernetes, del controller ALB e dei carichi di lavoro back-end per la resilienza tra zone.

Comportamento quando tutte le zone sono integre

Questa sezione descrive cosa aspettarsi quando si distribuisce Application Gateway for Containers in un'area che supporta le zone di disponibilità e tutte le zone usate dal servizio sono operative.

• Operazione tra zone: il piano dati di gateway applicazione per contenitori gestito da Azure distribuisce le richieste in ingresso nell'infrastruttura in più zone.

  Si è responsabili della configurazione dei carichi di lavoro di back-end distribuiti tra più zone e di fornire destinazioni integre per ricevere tale traffico.

• Replica dei dati tra zone: Application Gateway for Containers non archivia i dati dell'applicazione. La piattaforma gestisce lo stato di configurazione tramite il piano di controllo con ridondanza della zona per garantire durabilità e resilienza.

Comportamento durante un errore di zona

Questa sezione descrive cosa aspettarsi quando si distribuisce gateway applicazione per contenitori in un'area che supporta le zone di disponibilità e una delle zone usate dal servizio presenta un'interruzione.

• Rilevamento e risposta: gateway applicazione per contenitori reindirizza il traffico all'infrastruttura nelle rimanenti zone integre durante un'interruzione della zona. Non è necessario intervenire per la ridistribuzione del traffico del gateway.

  Tuttavia, si è responsabili delle conseguenze dell'interruzione sul cluster Kubernetes e sulle applicazioni back-end.

• Notifica: Microsoft non invia automaticamente una notifica quando una zona è inattiva. È tuttavia possibile usare Integrità dei servizi di Azure per comprendere l'integrità complessiva del servizio, inclusi eventuali errori di zona, ed è possibile configurare gli avvisi di integrità dei servizi per notificare eventuali problemi.

• Richieste attive: Le connessioni esistenti alla zona guasta vengono eliminate. I client devono ritentare le richieste seguendo le indicazioni riportate in Resilienza agli errori temporanei. Vengono stabilite nuove connessioni all'infrastruttura nelle rimanenti zone sane.

• Perdita di dati prevista: Application Gateway for Containers non archivia i dati dell'applicazione. La piattaforma gestisce lo stato di configurazione tramite il piano di controllo a ridondanza di zona per garantire durabilità e resilienza.

• Tempo di inattività previsto: I client potrebbero riscontrare una breve interruzione quando vengono eliminate le connessioni alla zona guasta. I client devono ripetere le richieste per stabilire nuove connessioni all'infrastruttura nelle zone integre rimanenti.

  Il piano di controllo gestito da Azure rimane disponibile durante un'interruzione a singola zona. Tuttavia, la possibilità di applicare gli aggiornamenti della configurazione dipende anche dalla disponibilità del piano di controllo Kubernetes e del controller ALB.

• Ridistribuzione: Application Gateway for Containers reindirizza il traffico all'infrastruttura nelle restanti zone integre.

Ripristino della zona

Gateway applicazione per contenitori si ripristina automaticamente da problemi sottostanti. Azure gestisce il ripristino dell'infrastruttura del gateway.

Verifica dei guasti di zona

La piattaforma Application Gateway for Containers gestisce il routing del traffico e la risposta ai guasti delle zone per il gateway stesso. Non è necessario avviare o gestire la risposta del gateway. Se si dispone di un cluster Kubernetes che gestisci, è possibile usare Azure Chaos Studio per testare la risposta del cluster agli errori della zona. Per altre informazioni, vedere Test per la resilienza della zona di disponibilità.

Resilienza agli errori a livello di area

Gateway applicazione per contenitori è un servizio ad area singola. Se l'area Azure in cui è stato distribuito un gateway diventa non disponibile, tale gateway non è disponibile.

Soluzioni di multiregione personalizzate per la resilienza

Gateway applicazione per contenitori non fornisce una soluzione predefinita di distribuzione multi area o failover. Per progettare un'interruzione di una regione, distribuire e configurare un gateway separato e un cluster Kubernetes in ogni regione. Si è responsabili dell'indirizzamento del traffico tra i gateway a livello di area e della configurazione del failover.

• Configurare Application Gateway for Containers in modo coerente tra aree. Per semplificare le distribuzioni e mantenere allineate le configurazioni, definisci l'infrastruttura come codice (IaC) usando strumenti come Bicep o Terraform.

• Scegliere e configurare un servizio di gestione del traffico globale, ad esempio Frontdoor di Azure o Gestione traffico di Azure, per indirizzare i client ai gateway regionali. Questi servizi usano modelli di routing diversi e configurazioni di probe di integrità. Configurare il servizio selezionato per deviare il traffico lontano da un gateway non disponibile ed esaminare la relativa documentazione per comprendere il comportamento di routing e le considerazioni sul failover. Frontdoor di Azure fornisce anche funzionalità come la protezione DDoS (Distributed Denial of Service), le funzionalità web application firewall (WAF) e il routing basato su regole.

• Distribuire le applicazioni back-end in ogni area e configurarle per fornire carichi di lavoro integri durante un'interruzione. Se le applicazioni dipendono dai dati o da altri servizi di Azure, progettare e configurare tali servizi anche per la disponibilità in più aree. Esaminare le indicazioni sull'affidabilità per ogni servizio per comprendere le opzioni multiregione e le limitazioni.

Backup e ripristino

Application Gateway for Containers non archivia i dati dell'applicazione. Azure Resource Manager archivia la configurazione della risorsa Azure del gateway. È possibile ricreare queste risorse rieseguendo il deployment della loro configurazione.

Si è responsabili della conservazione della configurazione e delle risorse Kubernetes che definiscono come il gateway viene distribuito e come instrada il traffico:

• Definire le risorse Azure e le relative impostazioni nell'infrastruttura come codice (IaC), ad esempio Bicep o Terraform, e mantenere le definizioni nel controllo della versione. È possibile usarlo per distribuire nuovamente le risorse del gateway.

• Eseguire il backup delle risorse Kubernetes che configurano il gateway, come le risorse ApplicationLoadBalancer, Gateway e HTTPRoute. Ripristinarli nel tuo cluster quando è necessario ricreare la configurazione del routing.

• Mantenere la configurazione correlata, incluse le regole personalizzate e i criteri del Web Application Firewall, nel controllo della versione o tramite il processo di backup della configurazione standard. È possibile usare le pipeline di distribuzione per ricreare in modo coerente le risorse Azure e Kubernetes.

Resilienza alla manutenzione del servizio

Microsoft gestisce la manutenzione per Application Gateway for Containers mantenendo al tempo stesso la disponibilità elevata del servizio.

Le dimensioni minime della subnet /24 richieste per ogni associazione tengono conto delle finestre di manutenzione, pertanto non è necessario allocare spazio di indirizzi IP della subnet aggiuntivo per la manutenzione.

Per altre informazioni, vedere Scalabilità e disponibilità per Application Gateway for Containers.

Contratto di servizio

Il contratto di servizio per i servizi di Azure descrive la disponibilità prevista di ogni servizio e le condizioni che la soluzione deve soddisfare per raggiungere tale aspettativa di disponibilità. Per ulteriori informazioni, vedere Accordi sul livello di servizio (SLA) per i servizi online.

Lo SLA di Application Gateway for Containers misura separatamente il piano di controllo e il piano dati. Entrambi i piani vengono inseriti nel calcolo complessivo del contratto di servizio.

Contenuti correlati

• Distribuzione di Application Gateway for Containers in servizio Azure Kubernetes
• Affidabilità in Azure