Kafka su Kubernetes: è una buona cosa?

Benvenuti, Habr!

All'epoca siamo stati i primi a portare sul mercato russo il tema Kafka e continuiamo di monitorare a seguirne l'evoluzione. In particolare, ci è sembrato interessante il tema dell'interazione tra Kafka e Kubernetes. Un'analisi (e piuttosto cauta) su Habr. su questo argomento è stata pubblicata nel blog dell'azienda Confluent già nell'ottobre dello scorso anno a firma di Gwen Shapiro. Oggi vogliamo attirare la vostra attenzione su un articolo più recente, di aprile, di Johann Gyger, che, pur non essendosi astenuto dall'usare un punto interrogativo nel titolo, esplora il tema in una chiave più specifica, accompagnando il testo con link interessanti. Vi chiediamo scusa per la libera traduzione di «chaos monkey», se ce la fate!

Introduzione

Kubernetes è progettato per gestire carichi di lavoro senza stato. Di norma, questi tipi di carichi di lavoro sono rappresentati in forma di architettura a microservizi, sono leggeri, scalabili orizzontalmente, seguono i principi delle applicazioni a 12 fattori, e permettono di lavorare con interruttori automatici (circuit breaker) e scimmie del caos (chaos monkeys).

Kafka, d'altra parte, funge essenzialmente da database distribuito. Pertanto, quando si lavora, bisogna gestire uno stato, che è molto più pesante di un microservizio. Kubernetes supporta carichi di lavoro con stato, ma, come sottolinea Kelsey Hightower in due dei suoi tweet, bisogna fare attenzione:

Alcuni pensano che se si applica Kubernetes a un carico di lavoro con stato, esso diventi un database completamente gestito in grado di competere con RDS. Non è così. Forse, se si lavora abbastanza, si possono aggiungere componenti e coinvolgere un team di ingegneri SRE, si potrebbe configurare un RDS su Kubernetes.

Raccomando sempre di prestare estrema attenzione quando si avviano carichi di lavoro con stato su Kubernetes. La maggior parte di coloro che si chiedono: «Posso eseguire carichi di lavoro con stato su Kubernetes?» non ha esperienza sufficiente con Kubernetes e spesso nemmeno con il carico di lavoro in questione.

Quindi, vale la pena eseguire Kafka su Kubernetes? Una domanda a contrario: funzionerebbe meglio Kafka senza Kubernetes? Ecco perché voglio sottolineare in questo articolo come Kafka e Kubernetes si completino a vicenda e quali insidie possono sorgere dalla loro combinazione.

Tempo di esecuzione

Parliamo di una cosa fondamentale: l'ambiente di runtime in quanto tale

Processo

I broker Kafka sono efficienti nell'uso della CPU. Il TLS può comportare alcuni costi. Tuttavia, i client Kafka possono caricare maggiormente la CPU se utilizzano la crittografia, ma ciò non influisce sui broker.

Memoria

I broker Kafka consumano memoria. La dimensione della heap JVM di solito deve essere limitata a 4-5 GB, ma avrete anche bisogno di molta memoria di sistema, poiché Kafka utilizza molto attivamente la cache delle pagine. In Kubernetes, impostate adeguatamente i limiti delle risorse e le richieste del container.

Storage dei dati

Lo storage dei dati nei container è efimero: i dati vanno persi al riavvio. Per i dati di Kafka, si può utilizzare un volume emptyDir, e l'effetto sarà analogo: i dati del vostro broker andranno persi dopo la chiusura. I vostri messaggi possono comunque essere conservati su altri broker come repliche. Pertanto, dopo il riavvio, il broker difettoso deve prima replicare tutti i dati, e questo processo può richiedere un bel po' di tempo.

Ecco perché è necessario utilizzare uno storage di dati durevole. Deve essere uno storage durevole non locale con un filesystem XFS o, più precisamente, ext4. Non utilizzare NFS. Te l’ho detto. NFS versione v3 o v4 non funzionerà. In breve, il broker Kafka si fermerà se non riesce a eliminare la directory dei dati a causa di problemi con le "rinomine stupide", rilevanti in NFS. Se non ti ho ancora convinto, presta molta attenzione leggi questo articolo. Lo storage dei dati deve essere non locale, affinché Kubernetes possa scegliere un nuovo nodo in modo più flessibile dopo un riavvio o una relocation.

Rete

Come nella maggior parte dei sistemi distribuiti, le prestazioni di Kafka dipendono fortemente dal mantenere al minimo le latenze di rete e al massimo la larghezza di banda. Non tentate di posizionare tutti i broker sullo stesso nodo, poiché ciò ridurrebbe la disponibilità. Se un nodo Kubernetes fallisce, fallirà anche l'intero cluster Kafka. Inoltre, non disperdete il cluster Kafka su interi data center. Lo stesso vale per il cluster Kubernetes. Un buon compromesso in questo caso è scegliere diverse zone di disponibilità.

Configurazione

Manifesti comuni

Sul sito di Kubernetes c'è una guida molto utile su come configurare ZooKeeper utilizzando i manifesti. Poiché ZooKeeper fa parte di Kafka, è un buon punto di partenza per familiarizzare con le concetti di Kubernetes applicabili qui. Una volta compreso ciò, sarete in grado di applicare le stesse concezioni anche al cluster Kafka.

• Sotto: il pod è l'unità base distribuita minima in Kubernetes. All'interno del pod si trova il vostro carico di lavoro, e il pod stesso corrisponde a un processo nel cluster. Il pod contiene uno o più container. Ogni server ZooKeeper nell'ensemble e ogni broker nel cluster Kafka funzioneranno in un pod separato.
• StatefulSet: StatefulSet è un oggetto Kubernetes che gestisce più carichi di lavoro persistenti, i quali richiedono coordinazione. I StatefulSet forniscono garanzie riguardo l'ordinamento dei pod e la loro unicità.
• Servizi headless: I servizi permettono di separare i pod dai client utilizzando un nome logico. In questo caso, Kubernetes si occupa del bilanciamento del carico. Tuttavia, quando si trattano carichi di lavoro persistenti, come nel caso di ZooKeeper e Kafka, i client devono scambiarsi informazioni con un'istanza specifica. È qui che i servizi headless diventano utili: in tal caso, il client avrà comunque un nome logico, ma non sarà necessario riferirsi direttamente al pod.
• Volume per lo storage a lungo termine: tali volumi sono necessari per configurare uno storage a blocchi non locale di lungo termine, come accennato in precedenza.

A Yolean fornisce un insieme completo di manifesti che semplificano l'avvio del lavoro con Kafka su Kubernetes.

Diagrammi Helm

Helm è un gestore di pacchetti per Kubernetes, paragonabile ai gestori di pacchetti per sistemi operativi come yum, apt, Homebrew o Chocolatey. Con esso, è facile installare pacchetti software predefiniti descritti nei diagrammi Helm. Un diagramma Helm ben strutturato semplifica il compito complesso di configurare correttamente tutti i parametri per l'uso di Kafka su Kubernetes. Ci sono diversi diagrammi di Kafka: quello ufficiale si trova in uno stato incubatore, ce n'è uno di Confluent, un altro è di Bitnami.

Operatori

Poiché Helm presenta alcuni svantaggi, sta guadagnando popolarità un altro strumento: gli operatori Kubernetes. Un operatore non si limita a pacchettizzare software per Kubernetes, ma consente anche di distribuire e gestire tale software.

Nella lista degli operatori straordinari si menzionano due operatori per Kafka. Uno di essi è Strimzi. Con Strimzi, è semplice avviare un cluster Kafka in pochi minuti. Non è necessaria quasi nessuna configurazione e l'operatore stesso offre alcune funzionalità interessanti, come la crittografia TLS punto a punto all'interno del cluster. Confluent fornisce anche il proprio operatore.

Prestazioni

È molto importante testare le prestazioni fornendo punti di controllo al tuo istanza Kafka installata. Tali test possono aiutarti a identificare strozzature potenziali prima che sorgano problemi. Fortunatamente, Kafka già fornisce due strumenti per il testing delle prestazioni: kafka-producer-perf-test.sh e kafka-consumer-perf-test.sh. Utilizzali attivamente. Per riferimento, puoi confrontarti con i risultati descritti in questo post Jay Kreps, oppure fare riferimento a questa panoramica Amazon MSK di Stéphane Maarek.

Operazioni

Monitoraggio

La trasparenza nel sistema è molto importante; altrimenti non capirai cosa sta succedendo. Oggi esistono strumenti solidi che offrono monitoraggio basato su metriche in stile cloud native. Due strumenti popolari per questo scopo sono Prometheus e Grafana. Prometheus può raccogliere metriche da tutti i processi Java (Kafka, Zookeeper, Kafka Connect) tramite l'esportatore JMX - nel modo più semplice possibile. Se si aggiungono le metriche cAdvisor, sarà possibile avere una visione più completa di come le risorse vengono utilizzate in Kubernetes.

Strimzi offre un esempio molto utile di dashboard Grafana per Kafka. Visualizza metriche chiave, come quelle relative a settori non replicati o offline. Tutto è molto chiaro. Queste metriche sono integrate da informazioni sull'uso delle risorse e sulle prestazioni, oltre a indicatori di stabilità. In questo modo, ottieni un monitoraggio di base del cluster Kafka senza alcun costo!

Fonte: strimzi.io/docs/master/#kafka_dashboard

Tutto questo sarebbe bene integrarlo con il monitoraggio dei client (metriche su consumer e producer), così come con il monitoraggio del ritardo (per questo c'è Burrow) e il monitoraggio end-to-end – per farlo utilizza Kafka Monitor.

Registrazione

La registrazione è un'altra fondamentale responsabilità. Assicurati che tutti i container nella tua installazione di Kafka vengano registrati in stdout e stderr, e assicurati anche che il tuo cluster Kubernetes raggruppi tutti i log in un'infrastruttura di logging centralizzata, ad esempio in Elasticsearch.

Verifica del funzionamento

Kubernetes utilizza probe di liveness e readiness per verificare se i tuoi pod funzionano correttamente. Se il controllo di liveness fallisce, Kubernetes fermerà quel container e poi lo riavvierà automaticamente, se la politica di riavvio è impostata correttamente. Se il controllo di readiness fallisce, Kubernetes isolerà quel pod dall'elaborazione delle richieste. In questo modo, in tali situazioni non è più necessario alcun intervento manuale, il che è un grande vantaggio.

Distribuzione degli aggiornamenti

StatefulSet supporta aggiornamenti automatici: scegliendo la strategia RollingUpdate, ogni pod Kafka verrà aggiornato uno alla volta. In questo modo, è possibile ridurre a zero il tempo di fermo.

Scalabilità

Scalare un cluster Kafka è un compito complesso. Tuttavia, in Kubernetes è molto semplice scalare i pod a un numero specifico di repliche, il che significa che puoi definire in modo dichiarativo quanti broker Kafka desideri. La parte più difficile in questo caso è la riassegnazione dei settori dopo una scalata verso l'alto o prima di una scalata verso il basso. Anche qui, Kubernetes può aiutarti con questa operazione.

Amministrazione

Le attività relative all'amministrazione del vostro cluster Kafka, in particolare la creazione di topic e la ridefinizione delle partizioni possono essere svolte utilizzando gli script shell esistenti, aprendo l'interfaccia della riga di comando nei vostri pod. Tuttavia, questa soluzione non è molto elegante. Strimzi supporta la gestione dei topic tramite un altro operatore. Qui c'è bisogno di miglioramenti.

Backup e ripristino

Ora la disponibilità di Kafka dipenderà anche dalla disponibilità di Kubernetes. Se il vostro cluster Kubernetes si guasta, nel peggiore dei casi si guasterà anche il cluster Kafka. Secondo la legge di Murphy, ciò accadrà sicuramente, e perderete dati. Per ridurre il rischio di tali eventi, lavorate bene sul concetto di backup. Potete utilizzare MirrorMaker, un'altra opzione è impiegare S3 a tal fine, come descritto in questo posto di Zalando.

Conclusione

Quando si lavora con cluster Kafka di piccole o medie dimensioni, è decisamente utile utilizzare Kubernetes, poiché fornisce flessibilità aggiuntiva e semplifica il lavoro con gli operatori. Se avete requisiti non funzionali molto severi riguardanti la latenza e/o la larghezza di banda, potrebbe essere meglio considerare un'altra opzione di distribuzione.

Fonte: habr.com