Carichi di lavoro con stato nel servizio Azure Kubernetes

Questo articolo offre una panoramica dell'esecuzione e della migrazione di carichi di lavoro con stato in Servizio Azure Kubernetes (AKS): modelli di progettazione, opzioni di archiviazione e migrazione su rampe per database e servizi con stato.

Che cosa sono i carichi di lavoro con stato?

Un carico di lavoro con stato è un'applicazione che usa l'archiviazione dei dati persistente per mantenere lo stato tra più istanze, garantendo un'esperienza utente facile e personalizzata. Questa progettazione è fondamentale per servizi come online banking, shopping online e posta elettronica, in cui la coerenza dei dati, la cronologia delle sessioni e l'affidabilità sono fondamentali. I carichi di lavoro con stato offrono anche efficienza in scenari di elaborazione con prestazioni elevate e quasi in tempo reale che traggono vantaggio da funzionalità avanzate come failover e ripristino, garantendo la continuità aziendale.

Anche se i carichi di lavoro con stato offrono molti vantaggi, presentano anche determinate problematiche. Ad esempio, i carichi di lavoro con stato spesso introducono modelli di elaborazione complessi che possono comportare un aumento del sovraccarico e dei costi delle prestazioni. È importante comprendere e considerare le esigenze specifiche dell'applicazione per determinare il giusto equilibrio tra con stato e senza stato.

Dato il ruolo critico dei carichi di lavoro con stato, Azure offre diversi approcci per eseguirli in modo efficace. Questa sezione illustra le procedure consigliate per la distribuzione di carichi di lavoro con stato nel servizio Azure Kubernetes, consentendo agli sviluppatori e alle organizzazioni di scegliere l'opzione più adatta per le loro esigenze.

Migrazione di carichi di lavoro con stato in AKS

Se stai migrando applicazioni con stato esistenti in AKS, segui questo breve percorso iniziale di migrazione per ridurre i rischi e accelerare la distribuzione:

  1. Valutare i requisiti di archiviazione e disponibilità: documenti IOPS, velocità effettiva, latenza, durabilità e disponibilità elevata necessarie per i dati. Identifica se il tuo carico di lavoro richiede un'archiviazione a blocchi (Azure Disk), di file (File di Azure) o un'archiviazione specializzata supportata da CSI.
  2. Scegliere un driver CSI e una topologia di archiviazione CSI: selezionare il driver CSI supportato dal servizio Azure Kubernetes che soddisfa tali requisiti, ad esempio Azure CSI del disco per l'archiviazione a blocchi, File di Azure CSI per l'archiviazione file condivisa o un CSI di terze parti per le funzionalità avanzate. Verificare che siano supportati gli snapshot del volume e i requisiti di replica.
  3. Distribuire usando StatefulSets o un operatore: eseguire la migrazione di repliche con StatefulSets o usare un operatore di database per gestire failover, appartenenza e backup. Convalidare il ripristino, il failover e il comportamento di aggiornamento in sequenza in un ambiente di test prima del cutover.

Per altre informazioni, vedere Considerazioni sulla migrazione di carichi di lavoro con stato al servizio Azure Kubernetes.

Scenari comuni di migrazione con stato

  • PostgreSQL: valutare le esigenze di IOPS dello storage e di alta disponibilità, scegliere uno storage replicato su blocchi o supportato da CSI e distribuirlo con uno StatefulSet o un operatore PostgreSQL. Vedere Indicazioni su PostgreSQL.
  • MongoDB: verificare il write concern, il journaling e la topologia del set di replica; selezionare uno storage che soddisfi i requisiti di throughput e durabilità e distribuire usando StatefulSets o l'operatore MongoDB. Vedere Le linee guida per MongoDB.

Stack di base del framework con stato Kubernetes

Il framework con stato Kubernetes inizia con uno stack di base comune. In questo caso, usare lo stack KATE , uno stack diffuso standardizzato usato per molti progetti di infrastruttura. Lo stack KATE usa gli strumenti open source seguenti:

Le guide del servizio Azure Kubernetes non implementano ArgoCD o Terraform perché sono progettate per operazioni di 1 giorno. Tuttavia, man mano che le scalabilità e i requisiti della distribuzione si evolvono, dovrebbe essere più semplice integrare ArgoCD e Terraform, poiché le guide usano parte dello stack KATE.

Framework con stato Kubernetes per Azure

Con lo stack di base stabilito, ora è necessario migliorare il framework per supportare carichi di lavoro con stato in Azure, in particolare integrando le risorse essenziali per l'esecuzione dell'infrastruttura dati nel servizio Azure Kubernetes.

Il supporto di carichi di lavoro con stato complessi, ad esempio database o code di messaggi, richiede funzionalità di archiviazione che superano le opzioni temporanee. In particolare, sono necessari sistemi che offrono maggiore resilienza e disponibilità per risolvere vari eventi, ad esempio errori dell'applicazione o riassegnazioni del carico di lavoro a host diversi. È possibile ottenere questa resilienza usando il sottosistema PersistentVolume, che comprende tre risorse Kubernetes interconnesse: PersistentVolumes, PersistentVolumeClaims e StorageClasses. Questo sottosistema fornisce un'API per gli utenti e gli amministratori per astrarre i dettagli di come viene fornita l'archiviazione da come viene usata l'archiviazione.

La maggior parte dei carichi di lavoro con stato richiede dati provenienti da segreti, ad esempio stringa di connessione, nomi utente, password e certificati. Azure Key Vault fornisce un'archiviazione sicura per i segreti usati per contenere i segreti dei framework con stato necessari.

È necessario anche un controller Kubernetes o un operatore Kubernetes, ad esempio il driver CSI di archiviazione segreti o l'operatore segreti esterni per sincronizzare i segreti dell'archivio di segreti come segreti Kubernetes.

Screenshot di un diagramma che mostra il framework con stato Kubernetes per Azure.

Progettare e distribuire carichi di lavoro con stato in Azure

Se si esegue la migrazione di un carico di lavoro con stato esistente al servizio Azure Kubernetes, iniziare con i carichi di lavoro con stato di migrazione al servizio Azure Kubernetes in modalità on-ramp per esaminare i passaggi di valutazione e convalida specifici della migrazione.

Le sezioni seguenti forniscono collegamenti alle informazioni di progettazione e distribuzione per scenari di carico di lavoro con stato in Azure.

MongoDB

PostgreSQL

Valkey

Apache Airflow

Apache Kafka con Strimzi

GitHub Actions con File di Azure

Annotazioni

Sebbene i StatefulSet forniscano identità persistenti e archiviazione, i pool di nodi Spot di Azure non sono consigliati per carichi di lavoro con stato critici per la produzione. Le macchine virtuali spot possono essere rimosse con poco preavviso quando Azure recupera la capacità, causando interruzioni improvvise dei nodi e potenziali ritardi nel ripristino del volume o nella riprogrammazione dei pod. Per i carichi di lavoro che dipendono da dati persistenti e disponibilità elevata, usare i normali pool di nodi e i meccanismi di resilienza di archiviazione appropriati. I pool di nodi spot di Azure devono essere riservati a carichi di lavoro soggetti a interruzioni che possono tollerare la perdita imprevista dei nodi.

Collaboratori

Microsoft gestisce questo articolo. I collaboratori seguenti l'hanno scritto originariamente:

  • Don High | Ingegnere Responsabile Cliente
  • Colin Mixon | Product Manager
  • Erin Schaffer | Sviluppatore di contenuti 2
  • Last updated on