Distribuire un cluster Kafka nel servizio Azure Kubernetes usando Strimzi

In questa guida vengono esaminati i prerequisiti, le considerazioni sull'architettura e i componenti chiave per la distribuzione e il funzionamento di un cluster Apache Kafka a disponibilità elevata nel servizio Azure Kubernetes usando l'operatore Strimzi.

Che cos'è Apache Kafka e Strimzi?

Apache Kafka è una piattaforma di streaming di eventi distribuiti open source progettata per gestire dati di streaming in tempo reale, ad alta velocità effettiva e volume elevato. Di conseguenza, viene usato da migliaia di aziende per pipeline di dati ad alte prestazioni, analisi di streaming, integrazione dei dati e applicazioni cruciali. Tuttavia, la gestione e il ridimensionamento dei cluster Kafka possono risultare complessi e spesso dispendiosi in termini di tempo.

Strimzi è un progetto open source che semplifica la distribuzione, la gestione e il funzionamento di Apache Kafka in Kubernetes. Fornisce un set di operatori Kubernetes e immagini container che automatizzano attività operative complesse di Kafka tramite configurazione dichiarativa.

Gli operatori Strimzi seguono il modello di operatore Kubernetes per automatizzare le operazioni Kafka. Riconcilia continuamente lo stato dichiarato dei componenti Kafka con lo stato effettivo, gestendo automaticamente attività operative complesse.

Per altre informazioni su Strimzi, vedere la documentazione di Strimzi.

Componenti

Operatore cluster Strimzi

L'operatore cluster Strimzi è il componente centrale che gestisce l'intero ecosistema Kafka. Quando viene distribuito, può anche effettuare il provisioning dell'operatore di entità, costituito da:

• Operatore argomento: automatizza la creazione, la modifica e l'eliminazione di argomenti Kafka in base alle KafkaTopic risorse personalizzate.
• Operatore utente: gestisce gli utenti Kafka e gli elenchi di controllo di accesso (ACL) tramite KafkaUser risorse personalizzate.

Insieme, questi operatori creano un sistema di gestione completamente dichiarativo in cui l'infrastruttura Kafka è definita come risorse Kubernetes che è possibile controllare con sistemi di gestione delle versioni, monitorare e distribuire in maniera uniforme tra gli ambienti.

Cluster Kafka

L'operatore cluster Strimzi gestisce i cluster Kafka tramite risorse personalizzate specializzate:

• KafkaNodePools: definire gruppi di nodi Kafka con ruoli specifici (broker, controller o entrambi).
• Kafka: la risorsa personalizzata principale che collega tutti gli elementi, definendo configurazioni a livello di cluster.

Una distribuzione tipica di KafkaNodePools e Kafka include:

• Nodi broker dedicati che gestiscono il traffico client e l'archiviazione dei dati.
• Nodi controller dedicati che gestiscono i metadati e il coordinamento del cluster.
• Più repliche di ogni componente distribuite tra zone di disponibilità.

Controllo di velocità

Cruise Control è un componente avanzato che fornisce il bilanciamento e il monitoraggio automatizzati dei carichi di lavoro per i cluster Kafka. Quando viene distribuito come parte di un cluster Kafka gestito da Strimzi, Cruise Control offre:

• Ribilanciamento automatico delle partizioni: ridistribuisce le partizioni tra i broker per ottimizzare l'utilizzo delle risorse.
• Rilevamento anomalie: identifica e avvisa il comportamento anomalo del cluster.
• Funzionalità di riparazione automatica: risolve automaticamente i problemi comuni di squilibrio del cluster.
• Analisi del carico di lavoro: fornisce informazioni dettagliate sulle prestazioni del cluster e sull'utilizzo delle risorse.

Cruise Control consente di mantenere prestazioni ottimali man mano che il carico di lavoro cambia nel tempo, riducendo la necessità di intervento manuale durante gli eventi di ridimensionamento o dopo gli errori del broker.

Drain Cleaner

Strimzi Drain Cleaner è un'utilità progettata per gestire i pod broker Kafka distribuiti da Strimzi durante lo svuotamento dei nodi Kubernetes. Strimzi Drain Cleaner intercetta le operazioni di svuotamento dei nodi Kubernetes tramite il webhook di ammissione per coordinare la manutenzione normale dei cluster Kafka. Quando viene effettuata una richiesta di rimozione per i pod broker Kafka, la richiesta viene rilevata e l'oggetto Drain Cleaner annota i pod per segnalare all'operatore cluster Strimzi di gestire il riavvio, assicurandosi che il cluster Kafka rimanga in uno stato integro. Questo processo mantiene l'integrità del cluster e l'affidabilità dei dati durante le operazioni di manutenzione di routine o errori imprevisti dei nodi.

Quando usare Kafka su AKS

Prendere in considerazione l'esecuzione di Kafka nel servizio Azure Kubernetes quando:

• È necessario il controllo completo sulla configurazione e sulle operazioni Kafka.
• Il caso d'uso richiede funzionalità Kafka specifiche non disponibili nelle offerte gestite.
• Si desidera integrare Kafka con altre applicazioni containerizzate in esecuzione su AKS.
• È necessario eseguire la distribuzione in aree in cui i servizi Kafka gestiti non sono disponibili.
• L'organizzazione ha competenze esistenti in Kubernetes e nell'orchestrazione dei contenitori.

Per casi d'uso più semplici o quando il sovraccarico operativo è un problema, prendere in considerazione servizi completamente gestiti come Hub eventi di Azure.

Considerazioni chiave per Kafka nel servizio Azure Kubernetes

Archiviazione su disco di Azure

Per le distribuzioni Kafka su AKS, viene usato il driver CSI del disco di Azure che fornisce volumi persistenti supportati da dischi gestiti di Azure. Strimzi sfrutta la configurazione JBOD (Just a Bunch of Disks) per gestire la persistenza dei dati.

Per garantire l'elevata disponibilità in caso di guasti dell'infrastruttura, le Storage classes devono essere configurate con dischi SSD Premium v2 distribuiti tra le zone di disponibilità utilizzando la modalità di associazione WaitForFirstConsumer volume. In questo modo, i pod vengono pianificati nelle zone in cui possono essere creati i loro volumi persistenti. SSD Premium v2 può offrire la latenza, le operazioni di I/O al secondo e la velocità effettiva coerente richieste dai carichi di lavoro Kafka a elevato utilizzo di I/O a una struttura di costi ottimizzata.

La tabella seguente fornisce i punti di partenza per le configurazioni Premium SSD v2 in diverse dimensioni del cluster Kafka:

Le operazioni di I/O al secondo, la larghezza di banda e le dimensioni del disco necessarie variano in base alle caratteristiche specifiche del carico di lavoro Kafka. Queste proprietà possono evolversi nel tempo man mano che cambiano i requisiti di velocità effettiva e conservazione dell'applicazione.

Pool di nodi

La selezione dei pool di nodi appropriati per la distribuzione Kafka nel servizio Azure Kubernetes è una decisione architetturale fondamentale che influisce direttamente sulle prestazioni, sulla disponibilità e sull'efficienza dei costi. I carichi di lavoro Kafka hanno modelli di utilizzo delle risorse univoci, caratterizzati da richieste di velocità effettiva elevata, intensità di I/O di archiviazione e necessità di prestazioni coerenti in carichi variabili. Kafka è in genere più intensivo della memoria rispetto all'uso intensivo della CPU. Tuttavia, i requisiti della CPU possono aumentare in modo significativo con compressione/decompressione dei messaggi, crittografia SSL/TLS o scenari a velocità effettiva elevata con molti messaggi di piccole dimensioni.

Considerando l'architettura nativa di Kubernetes di Strimzi in cui ogni broker Kafka viene eseguito come singolo pod, la strategia di selezione dei nodi del servizio Azure Kubernetes deve ottimizzare il ridimensionamento orizzontale anziché il ridimensionamento verticale a nodo singolo. La configurazione corretta del pool di nodi nel servizio Azure Kubernetes garantisce un utilizzo efficiente delle risorse mantenendo l'isolamento delle prestazioni richiesto dai componenti Kafka per funzionare in modo affidabile.

Kafka viene eseguito usando una JVM (Java Virtual Machines). L'ottimizzazione della JVM è fondamentale per ottenere prestazioni Kafka ottimali, in particolare negli ambienti di produzione. LinkedIn, creatori di Kafka, ha condiviso gli argomenti tipici per l'esecuzione di Kafka in Java per uno dei cluster più trafficati di LinkedIn: Configurazione Java kafka.

Per questa guida, un heap di memoria di 6 GB verrà usato come baseline per i broker, con un ulteriore 2 GB allocato per supportare l'utilizzo della memoria off-heap. Per i controller, un heap di memoria da 3 GB verrà usato come baseline, con un sovraccarico aggiuntivo di 1 GB.

Quando si ridimensionano le macchine virtuali per la distribuzione Kafka, prendere in considerazione questi fattori specifici del carico di lavoro:

Cluster Kafka da piccole a medie dimensioni

Cluster Kafka di grandi dimensioni

Prima di finalizzare l'ambiente di produzione, è consigliabile seguire questa procedura:

• Eseguire test di carico con volumi e modelli di dati rappresentativi.
• Monitorare l'utilizzo della CPU, della memoria, del disco e della rete durante i carichi di picco.
• Modificare gli SKU del pool di nodi del servizio Azure Kubernetes in base ai colli di bottiglia osservati.
• Esaminare il costo degli SKU del pool di nodi.

Disponibilità elevata e resilienza

Per garantire la disponibilità elevata della distribuzione Kafka, è necessario:

• Distribuire tra più zone di disponibilità.
• Configurare i vincoli di distribuzione della replica appropriati.
• Implementare budget di interruzione dei pod appropriati.
• Configurare Cruise Control per il ribilanciamento delle partizioni degli argomenti.
• Usare Strimzi Drain Cleaner per gestire le operazioni di svuotamento e manutenzione dei nodi.

Monitoraggio e operazioni

Un monitoraggio efficace dei cluster Kafka include:

• Configurazione della raccolta di metriche JMX.
• Monitoraggio del ritardo dei consumatori con l'utilità di esportazione Kafka.
• Integrazione con Azure Managed Prometheus e Azure Managed Grafana.
• Avvisi sugli indicatori chiave delle prestazioni e sulle metriche di salute.

Passaggio successivo

Contributori

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

• Sergio Navar | Senior Customer Engineer
• Erin Schaffer | Sviluppatore di contenuti 2