Alta disponibilità per applicazioni AKS multilivello

Questo articolo illustra la disponibilità elevata per la distribuzione di applicazioni a più livelli nei cluster Servizio Azure Kubernetes (AKS). Descrive i meccanismi e le architetture HA di Kubernetes e fornisce una checklist e linee guida per identificare ed eliminare i singoli punti di guasto dell'HA.

Esistono due attività fondamentali per implementare l'alta disponibilità per le applicazioni AKS:

  • Identificare tutti i singoli punti di errore nell'applicazione.
  • Eliminare i singoli punti di errore.

Per eliminare singoli punti di errore, è necessaria una soluzione a disponibilità elevata.

I quattro pilastri dell'HA

Quattro pilastri dell'HA sono presenti in ogni sistema ad alta disponibilità:

  • Redundancy
  • Monitoraggio
  • Recupero
  • Checkpoint

Si consideri la seguente applicazione AKS multilivello, in cui il traffico arriva al livello della logica di business, il livello dati conserva lo stato e l'applicazione restituisce risposte agli utenti.

Diagramma che illustra un'applicazione AKS multilivello.

Identificare singoli punti di errore

Per identificare singoli punti di errore, iniziare determinando il percorso critico tra le richieste client e i componenti che servono tali richieste. Qualsiasi componente in questo percorso che non è gestito secondo i quattro pilastri dell'alta disponibilità, oppure secondo i tre pilastri se si tratta di un componente senza stato e senza checkpoint, è un singolo punto di guasto. Anche un componente replicato viene considerato un singolo punto di errore se non viene monitorato, perché l'errore non viene rilevato automaticamente.

Eliminare singoli punti di errore

Per eliminare singoli punti di errore, distribuire l'applicazione per replicare i componenti del percorso critico e usare servizi di bilanciamento del carico, monitoraggio e meccanismi di ripristino. Kubernetes può gestire tutte queste attività.

Diagramma che mostra i componenti replicati in un'applicazione AKS multilivello.

Scaricare un file di Visio di questo diagramma.

In un'applicazione replicata:

  • I componenti del livello business vengono replicati con diversi numeri di repliche per componente, a seconda delle prestazioni e del carico di lavoro.
  • È inoltre possibile replicare il livello dati dietro un bilanciatore del carico.

Kubernetes offre diversi costrutti e meccanismi, ad esempio il bilanciamento del carico e le probe di integrità, che consentono di implementare i pilastri dell'alta disponibilità. La seguente checklist e la relativa discussione suddividono questi costrutti e meccanismi in categorie che si mappano sui quattro pilastri dell'alta disponibilità.

Elenco di controllo per la disponibilità elevata di Kubernetes

A parte la gestione dello stato, Kubernetes fa un ottimo lavoro nel garantire l'alta disponibilità delle applicazioni. L'elenco di controllo della disponibilità elevata elenca le configurazioni comuni che è possibile usare per ottimizzare la gestione della disponibilità elevata di Kubernetes. Per usare l'elenco di controllo, valutare la distribuzione di Kubernetes con i meccanismi e i costrutti seguenti e implementare eventuali elementi mancanti.

Pilastro HA Soluzione
Redundancy ☐ Tipo di controller Kubernetes
☐ Numero di repliche
☐ Pianificazione dell'anti-affinità
Monitoraggio ☐ Probe di vitalità
☐ Probe di idoneità
☐ Probe di avvio
Recupero ☐ Tipo di servizio
☐ Elezioni leader
☐ Criteri di riavvio
☐ Hook di pre-interruzione
Checkpoint ☐ Richieste di volumi persistenti
☐ Volumi permanenti

Redundancy

La ridondanza riduce la presenza di un singolo punto di errore. Hai bisogno di ridondanza a tutti i livelli di un'applicazione. Per ottenere la ridondanza, si replica un componente di un determinato livello con una o più repliche identiche.

  • Tipo di controller. Configurazione: kind: Deployment. Kubernetes offre diversi controller che possono gestire il ciclo di vita del pod dell'applicazione. Il controller più diffuso è Deployment. Statefulset, un altro controller, è utile quando è necessario mantenere l'identità del pod dopo un ripristino. Altri controller, come Replicasets, non forniscono la stessa utile funzionalità, come il rollback, che Deployment offre.

  • Numero di repliche. Configurazione: spec.replicas. Impostando il numero di repliche a una sola, si configura un modello di standby a freddo. Se si usa un modello cold standby, quando si verifica un errore, una nuova istanza inizia da zero, che influisce sulla disponibilità. Questo modello potrebbe funzionare per componenti con carichi di lavoro a basso volume, ma valuta di replicare i componenti stateless ad alto volume.

    Specificando i limiti delle richieste di risorse, spec.containers[].resourcesè possibile aggiungere la scalabilità automatica orizzontale dei pod (HPA), che fa sì che Kubernetes possa aumentare o ridurre automaticamente il numero di repliche in base alle soglie di utilizzo delle risorse definite dall'utente. HPA consente di evitare scenari in cui un aumento del carico impedisce all'applicazione di gestire le richieste a causa dell'overload.

  • Pianificazione dell'anti-affinità. Configurazione: spec.affinity.podAntiAffinity. Un tipico cluster Kubernetes a livello di produzione include nodi distribuiti in più zone di disponibilità, che è possibile configurare usando un .topologyKey I pod dello stesso deployment dovrebbero avere un'anti-affinità preferenziale o soft tra loro. Questa configurazione garantisce che i pod pianificano i nodi in zone di disponibilità diverse.

    Un cluster AKS può avere più pool di nodi, ognuno con dimensioni e specifiche diverse per i set di scalabilità di macchine virtuali. Ad esempio, è possibile ospitare i pod di database nei nodi con unità SSD (Solid State Drive) veloci e ospitare i pod di Machine Learning nei nodi con unità di elaborazione grafica (GPU).

Monitoraggio

Se non monitori l'applicazione, la ridondanza può diventare inefficace. È necessario un meccanismo di monitoraggio costante per garantire che il carico di lavoro raggiunga una replica integra.

  • Probe di vitalità, configurazione spec.containers.livenessProbe, monitorano lo stato di salute dei pod. Se un contenitore ha esito negativo o si chiude, Kubernetes può rilevarlo. Quando l'attività ha esito negativo, Kubernetes riavvia il contenitore.

  • Probe di idoneità, configurazione spec.containers.readinessProbe, determinare se inviare traffico al pod. Se i pod di una distribuzione non sono pronti, non faranno parte degli endpoint del servizio Kubernetes che astraggono la distribuzione e pertanto non saranno utili. È importante impostare con attenzione le probe di readiness, perché non causano un riavvio, ma vengono usate per escludere i pod dalla ricezione del traffico finché non sono pronti.

  • Probe di avvio, configurazione spec.containers.startupProbe, servono principalmente a evitare falsi positivi per la prontezza e l'integrità nelle applicazioni con avvio lento. Dopo che il probe di avvio ha esito positivo, viene avviato il probe di attività.

Azure fornisce informazioni più approfondite che consentono di impostare avvisi in base all'integrità del cluster.

Recupero

Lo scopo principale del monitoraggio è attivare il ripristino quando rileva un errore. Un processo di ripristino prevede tre fasi:

  1. Isolare e reindirizzare: Assicurarsi che la replica difettosa non riceva traffico e indirizzare il carico di lavoro alle repliche integre.
  2. Riparazione: Riavviare la replica difettosa. In questo modo è possibile correggere gli errori temporanei.
  3. Ricongiungersi: Dopo il ripristino, se il monitoraggio ritiene integro la replica, ricongiunti la replica ad altre repliche per gestire il carico di lavoro.

Kubernetes fornisce i meccanismi seguenti per implementare queste fasi:

  • Tipo di servizio. Configurazione: spec.type. Esporre i pod tramite un servizio può essere classificato come ridondanza o ripristino. In alcuni casi, tuttavia, è possibile usare una distribuzione a replica singola. Ci sono ancora vantaggi nell'esporre i pod tramite un servizio, anche se non è presente alcun bilanciamento del carico.

    Il vantaggio principale dell'uso del servizio è che le voci DNS (Domain Name System) vengono aggiornate automaticamente con gli endpoint del servizio Kubernetes. Un pod con contenitori i cui probe di integrità non hanno esito positivo non riceverà traffico tramite AKS. Sebbene la capacità di bilanciamento del carico dei servizi ClusterIP di Kubernetes sia rudimentale, è possibile abbinare un servizio headless a Ingress o ad altre soluzioni di service mesh per bilanciare meglio la distribuzione del carico.

    Il meccanismo tramite cui il traffico esterno raggiunge il cluster AKS esula dall'ambito di Kubernetes. È possibile gestire il traffico esterno usando servizi come gateway applicazione di Azure.

  • Elezioni leader. È preferibile implementare alcuni componenti come singleton. L'utilità di pianificazione è uno di questi componenti, perché due utilità di pianificazione attive possono entrare in conflitto tra loro. L'utilizzo di un singleton espone l'applicazione a problemi legati al cold standby. Per abilitare il warm standby di un pod, è possibile usare l'elezione del leader, in cui un solo pod, il leader, gestisce le richieste.

  • Criteri di riavvio. Configurazione: spec.restartPolicy. Il criterio di riavvio si applica a tutti i contenitori del pod. Deve essere presente una giustificazione valida per l'impostazione di questo attributo su Never. Alcuni container contattano un server di licenze ogni volta che vengono avviati e potresti voler evitare i costi aggiuntivi dovuti a riavvii eccessivi.

  • Hook di pre-arresto Configurazione: spec.containers.lifecycle.preStop. Gli hook pre-stop vengono eseguiti prima che al container venga inviato un segnale SIGTERM. Uno script di pre-arresto può essere semplice come un comando di sospensione di 30 secondi.

    Ad esempio, quando un'applicazione gestita da un HPA viene ridotta, le richieste in corso potrebbero essere terminate bruscamente, a meno che l'applicazione non disponga di un gestore SIGTERM che completi l'elaborazione delle richieste prima di terminare. Un hook pre-stop rimuove l'endpoint del pod dall'endpoint del servizio e, di conseguenza, la voce DNS. Mentre il pre-stop hook è in esecuzione, non possono essere inviate nuove richieste al pod. L'hook pre-stop consente al pod di completare l'elaborazione delle richieste in corso senza riceverne di nuove. Gli hook pre-stop sono un modo semplice per ridurre al minimo le richieste perse senza modificare il codice dell'applicazione.

Checkpoint

Le applicazioni moderne contengono molti componenti senza stato, ma le applicazioni completamente senza stato sono ancora rare. La maggior parte delle applicazioni verifica il proprio stato nel livello dati. Kubernetes non fornisce intenzionalmente alcun meccanismo per gestire lo stato dell'applicazione. La gestione dello stato è un'attività complessa che non fa parte della gestione dei contenitori.

È possibile rendere persistente lo stato dell'applicazione in tre livelli:

  • Il livello dei record di dati archivia i dati in un database. Ogni record di database può essere replicato in più istanze di database. I record di database sono la forma dominante di persistenza dello stato, soprattutto nei database cloud gestiti come Azure Cosmos DB.

  • Il livello del file system in genere replica i file di dati, ad esempio i file di write-ahead logging (WAL). La maggior parte dei provider di servizi cloud offre plug-in per le proprie soluzioni. Ad esempio, File di Azure fornisce un plug-in.

  • Il livello del disco rende persistenti i dati a livello di blocco, che offre flessibilità per definire il file system da usare, come in archiviazione su disco di Azure.

I volumi Kubernetes , i volumi persistenti e le attestazioni di volume persistente possono rendere persistente lo stato dell'applicazione a livello di file system o disco. Il modello più comune per archiviare lo stato è ancora il livello dei record di dati.

Disponibilità elevata e ripristino di emergenza

Sia per l'alta disponibilità che per il disaster recovery (DR), la scelta della topologia di rete e delle soluzioni di bilanciamento del carico è importante.

Tuttavia, il disaster recovery richiede la distribuzione del servizio in più aree geografiche a livello dell'intero servizio, con soluzioni di bilanciamento del carico tra aree di Azure. L'applicazione viene distribuita in più aree o in ogni area viene distribuita un'intera istanza dell'applicazione. La scelta dipende dal tipo di applicazione, dall'architettura dell'applicazione e dalla tolleranza di latenza tra i componenti.

L'alta disponibilità trae vantaggio dalle distribuzioni multizona all'interno delle aree di Azure anziché dall'uso di più aree. Il diagramma seguente illustra la differenza tra le zone di disponibilità e le regioni per HA e DR.

Diagramma che confronta le zone di disponibilità e le regioni di Azure per l'alta disponibilità e il ripristino di emergenza.

Scaricare un file di Visio di questa architettura.

Questo articolo si concentra su HA a livello di applicazione all’interno di un singolo cluster AKS. Per altre informazioni sul ripristino di emergenza (DR) nelle distribuzioni multi-cluster di AKS, vedere Baseline di AKS per cluster in più aree geografiche.

Altre considerazioni

  • Per mantenere l'alta disponibilità dell'applicazione, assicuratevi che il piano di controllo di Kubernetes, incluso il server API e il controller manager, sia altamente disponibile. Usa il livello tariffario Standard o Premium per garantire l'alta disponibilità.

  • Una strategia di consolidamento delle risorse è in diretto contrasto con il pilastro della ridondanza HA. Pertanto, è necessario analizzare attentamente il costo della ridondanza. Il calcolatore prezzi Azure può essere utile.

Contributors

Microsoft gestisce questo articolo. I seguenti collaboratori hanno scritto questo articolo.

Autore principale:

Altri contributori:

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

  • Last updated on