Kafka su Kubernetes — è una buona idea?

Benvenuti, Habr!

In passato, siamo stati i primi a lanciare sul mercato russo il tema Kafka e continuiamo di seguire a seguirne lo sviluppo. In particolare, ci è sembrato interessante il tema dell'interazione tra Kafka e Kubernetes. Un'analisi (e piuttosto cauta) su questo argomento è stata pubblicata nel blog dell'azienda Confluent già nell'ottobre dello scorso anno a cura di Gwen Shapiro. Oggi vogliamo attirare la vostra attenzione su un articolo più recente, di aprile, di Johann Gyger, il quale, sebbene non abbia evitato un punto interrogativo nel titolo, affronta la questione in modo più concreto, accompagnando il testo con link interessanti. Scusateci, per favore, per la traduzione libera di "chaos monkey", se potete! articolo di questo argomento si era già parlato nel blog dell'azienda Confluent nell'ottobre dello scorso anno a cura di Gwen Shapiro. Oggi vogliamo richiamare la vostra attenzione su un articolo più recente di aprile di Johann Gyger, che, sebbene non abbia evitato un punto interrogativo nel titolo, affronta il tema in modo più concreto, accompagnando il testo con link interessanti. Vi preghiamo di scusare la nostra traduzione libera di "chaos monkey", se possibile!

Introduzione

Kubernetes è progettato per gestire carichi di lavoro senza stato. In genere, questi carichi di lavoro sono rappresentati in forma di architetture a microservizi, sono leggeri, ben scalabili orizzontalmente, seguono i principi delle applicazioni 12-factor, consentono di lavorare con interruttori automatici (circuit breaker) e scimmie del caos (chaos monkeys).

Kafka, posizionato dall'altra parte, funge sostanzialmente da database distribuito. Di conseguenza, quando si lavora, ci si deve confrontare con lo stato, che è molto più pesante di un microservizio. Kubernetes supporta i carichi di lavoro con stato, ma, come sottolinea Kelsey Hightower nei suoi due tweet, bisogna maneggiarli con cautela:

Alcuni credono che se si implementa Kubernetes su un carico di lavoro con stato, esso diventi un database completamente gestito, in grado di competere con RDS. Non è così. Forse, con sufficiente impegno, aggiungendo componenti e coinvolgendo un team di ingegneri SRE, si riesce a configurare RDS sopra Kubernetes.

Raccomando sempre di essere estremamente cauti nel lanciare 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 specifico a cui si riferiscono.

Dunque, è opportuno eseguire Kafka su Kubernetes? La domanda opposta è: funzionerebbe meglio Kafka senza Kubernetes? Ecco perché voglio sottolineare in questo articolo come Kafka e Kubernetes si completano a vicenda e quali insidie possono sorgere dalla loro combinazione.

Tempo di esecuzione

Parliamo di una cosa basilare: 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 questo non influisce sui broker.

Memoria

I broker Kafka consumano molta memoria. La dimensione della heap JVM di solito è consigliata per essere limitata a 4-5 GB, ma avrai anche bisogno di molta memoria di sistema, poiché Kafka utilizza intensamente la cache delle pagine. In Kubernetes, imposta di conseguenza i limiti delle risorse del contenitore e le richieste.

Archiviazione dei dati

L'archiviazione dei dati nei contenitori è effimera: i dati vengono persi al riavvio. Per i dati di Kafka è possibile utilizzare un volume emptyDir, e l'effetto sarà simile: i dati del tuo broker andranno persi al termine. I tuoi messaggi potrebbero comunque rimanere su altri broker come repliche. Quindi, dopo il riavvio, il broker guasto deve prima replicare tutti i dati, e questo processo potrebbe richiedere del tempo.

Ecco perché è importante utilizzare uno storage dati a lungo termine. Che sia uno storage non locale con un filesystem XFS o, più precisamente, ext4. Non usare NFS. Ti avverto. NFS versioni v3 o v4 non funzioneranno. In breve, il broker Kafka si fermerà se non può eliminare la directory dei dati a causa di problemi di «rinominazione stupida», attuali in NFS. Se finora non ti ho convinto, fai 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 rilocazione.

Rete

Come nella maggior parte dei sistemi distribuiti, le prestazioni di Kafka dipendono fortemente dal mantenimento di latenze di rete minime e da una larghezza di banda massima. Non cercate di posizionare tutti i broker nello stesso nodo, poiché ciò ridurrebbe la disponibilità. Se un nodo Kubernetes fallisce, anche l'intero cluster Kafka andrà in crash. Inoltre, non disperdete il cluster Kafka su diversi 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 manifesti. Poiché ZooKeeper fa parte di Kafka, è un buon punto di partenza per familiarizzare con quali concetti di Kubernetes sono applicabili qui. Una volta compreso questo, sarete in grado di applicare gli stessi concetti anche al cluster Kafka.

• Sotto: pod – è l'unità minima distribuita in Kubernetes. In un pod risiede il tuo carico di lavoro, e il pod stesso corrisponde a un processo nel tuo cluster. Un pod può contenere uno o più container. Ogni server ZooKeeper nell'insieme e ogni broker nel cluster Kafka opereranno in un pod separato.
• StatefulSet: StatefulSet – è un oggetto di Kubernetes che gestisce carichi di lavoro multipli con stato, il quale richiede coordinazione. StatefulSet fornisce garanzie riguardo all'ordinamento dei pod e alla loro unicità.
• Servizi Headless: I servizi consentono di scollegare i pod dai client tramite un nome logico. In questo caso, Kubernetes si occupa del bilanciamento del carico. Tuttavia, nelle operazioni con carichi di lavoro che mantengono lo stato, come nel caso di ZooKeeper e Kafka, i client devono interagire con un'istanza specifica. È qui che entrano in gioco i servizi headless: in tal caso, il client avrà comunque un nome logico, ma non sarà necessario contattare direttamente il pod.
• Volume per storage a lungo termine: questi volumi sono necessari per la configurazione dello storage a blocchi a lungo termine non locale menzionato in precedenza.

Su Yolean fornisce un insieme completo di manifesti, con cui è facile iniziare a lavorare con Kafka su Kubernetes.

Grafici Helm

Helm è un gestore di pacchetti per Kubernetes, paragonabile a gestori di pacchetti per sistemi operativi come yum, apt, Homebrew o Chocolatey. Facilita l'installazione di pacchetti software predefiniti, descritti nei grafici Helm. Un grafico Helm ben progettato semplifica il compito complesso di configurare correttamente tutti i parametri per utilizzare Kafka su Kubernetes. Ci sono diversi grafici Kafka: quello ufficiale è in stato di incubazione, ce n'è uno da Confluent, un altro da Bitnami.

Operatori

Poiché Helm presenta alcuni svantaggi, sta guadagnando notevole popolarità un altro strumento: gli operatori Kubernetes. L'operatore non solo impacchetta il software per Kubernetes, ma consente anche di distribuire e gestire tale software.

Nell'elenco straordinari operatori si menzionano due operatori per Kafka. Uno di essi è Strimzi. Con Strimzi, creare un cluster Kafka è un gioco da ragazzi in pochi minuti. Quasi nessuna configurazione è necessaria, e l'operatore stesso offre anche alcune funzionalità utili, come la crittografia TLS «point-to-point» all'interno del cluster. Confluent offre anche il proprio operatore.

Prestazioni

È molto importante testare le prestazioni, fornendo al tuo istanza Kafka dei punti di controllo. Questi test ti aiuteranno a individuare potenziali colli di bottiglia prima che si presentino problemi. Fortunatamente, Kafka fornisce già due strumenti per il test delle prestazioni: kafka-producer-perf-test.sh e kafka-consumer-perf-test.sh. Usali 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 comprenderete cosa sta succedendo. Oggi esiste un ampio arsenale di strumenti che garantiscono il 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, in modo molto semplice. Se si aggiungono le metriche di cAdvisor, si potrà avere una visione più completa di come vengono utilizzate le risorse in Kubernetes.

Strimzi ha un esempio molto utile di dashboard Grafana per Kafka. Visualizza metriche chiave, come quelle sui settori non replicati o quelli offline. Tutto è molto chiaro. Queste metriche sono integrate con informazioni sull'uso delle risorse e sulle performance, insieme a indicatori di stabilità. In questo modo, si ottiene un monitoraggio di base del cluster Kafka gratuitamente!

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

Tutto ciò sarebbe opportuno integrare con il monitoraggio dei client (metriche sui consumatori e produttori), nonché con il monitoraggio del ritardo (per questo c'è Burrow) e monitoraggio end-to-end – per questo utilizzate Kafka Monitor.

Registrazione

Il logging è un'altra operazione fondamentale. Assicurati che tutti i container nella tua installazione Kafka siano registrati in stdout e stderr, e fai in modo che il tuo cluster Kubernetes aggregi tutti i log in un'infrastruttura di logging centrale, come ad esempio in Elasticsearch.

Verifica del funzionamento

Kubernetes utilizza i controlli di "vitalità" (liveness) e di disponibilità (readiness) per verificare se i tuoi pod funzionano correttamente. Se il controllo di vitalità fallisce, Kubernetes fermerà quel container e lo riavvierà automaticamente, se la politica di riavvio è impostata correttamente. Se il controllo di disponibilità fallisce, Kubernetes isolerà quel pod dal servizio delle richieste. In tal modo, non è più necessario alcun intervento manuale in tali situazioni, il che rappresenta un grande vantaggio.

Distribuzione degli aggiornamenti

Gli StatefulSet supportano aggiornamenti automatici: scegliendo la strategia RollingUpdate, ogni pod Kafka verrà aggiornato uno alla volta. In questo modo, la durata dei tempi di inattività può essere ridotta a zero.

Scalabilità

Scalare un cluster Kafka non è un compito semplice. Tuttavia, in Kubernetes è molto facile scalare i pod a un numero specifico di repliche, il che significa che puoi definire dichiarativamente quanti broker Kafka desideri. La parte più complessa in questo caso è la riassegnazione delle partizioni dopo uno scaling verso l'alto o prima di uno scaling verso il basso. Anche in questo caso, Kubernetes può supportarti in questo compito.

Amministrazione

Le attività legate all'amministrazione del tuo cluster Kafka, in particolare la creazione di argomenti e la riassegnazione delle partizioni, possono essere svolte utilizzando gli script shell disponibili, aprendo l'interfaccia della riga di comando nei tuoi pod. Tuttavia, questa soluzione non è molto elegante. Strimzi supporta la gestione degli argomenti tramite un altro operatore. C'è spazio per miglioramenti.

Backup e ripristino

Ora la disponibilità di Kafka dipenderà anche dalla disponibilità di Kubernetes. Se il tuo cluster Kubernetes va giù, nel peggiore dei casi anche il cluster Kafka smetterà di funzionare. Secondo la legge di Murphy, ciò accadrà sicuramente e potresti perdere dati. Per ridurre il rischio di questo tipo, è importante pianificare attentamente la strategia di backup. Puoi utilizzare MirrorMaker, oppure impiegare S3, come descritto in questo post di Zalando.

Conclusione

Quando si lavora con cluster Kafka piccoli o medi, è decisamente vantaggioso utilizzare Kubernetes, poiché offre maggiore flessibilità e semplifica il lavoro con gli operatori. Se hai 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