Kafka nantu à Kubernetes hè bonu?

Saluti, Habr!

À un tempu, eramu i primi à presentà u tema à u mercatu russu Kafka è cuntinuà pista per u so sviluppu. In particulare, avemu trovu u tema di interaczione trà Kafka è Kubernetes. Osservabile (è abbastanza attentu) un articulu stu tema hè statu publicatu nantu à u blog Confluent in uttrovi di l'annu passatu sottu l'autore di Gwen Shapira. Oghje vulemu attirà a vostra attenzione à un articulu più recente d'aprile di Johann Gyger, chì, ancu s'ellu ùn hè micca senza un puntu d'interrogazione in u titulu, esamina u tema in una manera più sustantiva, accumpagnendu u testu cù ligami interessanti. Per piacè perdonaci a traduzzione gratuita di "scimmia di caos" se pudete!

Introduzione

Kubernetes hè pensatu per trattà carichi di travagliu senza statu. Di genere, tali carichi di travagliu sò presentati in a forma di una architettura di microserviziu, sò ligeri, scalanu bè orizzontalmente, seguitanu i principii di l'applicazioni di fattore 12, è ponu travaglià cù circuit breakers è scimmie di caos.

Kafka, invece, agisce essenzialmente cum'è una basa di dati distribuita. Cusì, quandu u travagliu, avete da trattà cù u statu, è hè assai più pesu di un microserviziu. Kubernetes supporta carichi stateful, ma cum'è Kelsey Hightower indica in dui tweets, deve esse trattatu cun cura:

Certi pirsuni pensanu chì, se mette Kubernetes in una carica di travagliu statale, diventa una basa di dati cumpletamente gestita chì rivale RDS. Questu hè sbagliatu. Forse, se travagliate abbastanza, aghjunghje cumpunenti supplementari è attrae una squadra di ingegneri SRE, puderà custruisce RDS sopra Kubernetes.

Aghju sempre ricumandemu chì tutti esercitanu estrema prudenza quandu eseguenu carichi di travagliu stateful in Kubernetes. A maiò parte di e persone chì dumandanu "puderaghju eseguisce carichi di travagliu stateful in Kubernetes" ùn anu micca abbastanza sperienza cù Kubernetes, è spessu cù a carica di travagliu chì dumandanu.

Allora, duvete eseguisce Kafka nantu à Kubernetes? Contro quistione: Kafka travaglià megliu senza Kubernetes? Hè per quessa chì vogliu mette in risaltu in questu articulu cumu Kafka è Kubernetes si cumplementanu l'un à l'altru, è chì trappule ponu vene cun cumminendu.

Tempu di cumpiimentu

Parlemu di a cosa basica - l'ambiente runtime stessu

prucessu

I brokers Kafka sò CPU amichevuli. TLS pò intruduce qualchì overhead. Tuttavia, i clienti Kafka ponu esse più intensivi di CPU si usanu criptografia, ma questu ùn affetta micca i brokers.

memoria

I brokers Kafka manghjanu a memoria. A dimensione di l'heap JVM hè di solitu limitata à 4-5 GB, ma avete ancu bisognu di assai memoria di u sistema postu chì Kafka usa a cache di pagina assai assai. In Kubernetes, stabilisce e risorse di u containeru è dumandate i limiti in cunsequenza.

Magazzinu di dati

L'almacenamiento di dati in cuntenituri hè effimera - i dati sò persi quandu si riavvia. Per i dati Kafka pudete aduprà un voluminu emptyDir, è l'effettu serà simile: i vostri dati di u broker seranu persi dopu à a fine. I vostri missaghji ponu sempre esse guardati in altri brokers cum'è rèpliche. Dunque, dopu à un riavviu, u broker fallutu deve prima riplicà tutte e dati, è stu prucessu pò piglià assai tempu.

Hè per quessa chì duvete aduprà u almacenamentu di dati à longu andà. Chì sia un almacenamentu à longu andà non-lucale cù u sistema di schedari XFS o, più precisamente, ext4. Ùn aduprate micca NFS. Vi aghju avvistatu. E versioni NFS v3 o v4 ùn funziona micca. In cortu, u broker Kafka crash s'ellu ùn pò micca sguassà u cartulare di dati per via di u prublema "stupid rename" in NFS. S'ellu ùn vi aghju micca cunvinta ancu, assai attentamente leghje stu articulu. U magazzinu di dati ùn deve esse micca lucale in modu chì Kubernetes pò sceglie più flexiblemente un novu node dopu un riavviu o trasferimentu.

Network

Cum'è cù a maiò parte di i sistemi distribuiti, u rendiment di Kafka hè assai dipendente da mantene a latenza di a rete à u minimu è a larghezza di banda à u massimu. Ùn pruvate micca d'ospitu tutti i brokers in u stessu node, perchè questu riduce a dispunibilità. Se un node Kubernetes falla, tuttu u cluster Kafka falla. Inoltre, ùn disperse micca u cluster Kafka in tutti i centri di dati. U stessu passa per u cluster Kubernetes. Un bonu cumprumissu in questu casu hè di sceglie diverse zone di dispunibilità.

Cunfigurazione

Manifesti rigulari

U situ web di Kubernetes hà assai bona guida nantu à cumu cunfigurà ZooKeeper cù manifesti. Siccomu ZooKeeper face parte di Kafka, questu hè un bonu postu per cumincià à familiarizà cù quali cuncetti Kubernetes s'applicanu quì. Quandu avete capitu questu, pudete aduprà i stessi cuncetti cù un cluster Kafka.

• By: Un pod hè a più chjuca unità implementable in Kubernetes. Un pod cuntene a vostra carica di travagliu, è u pod stessu currisponde à un prucessu in u vostru cluster. Un pod cuntene unu o più cuntenituri. Ogni servitore ZooKeeper in l'inseme è ogni broker in u cluster Kafka correrà in un pod separatu.
• StatefulSet: Un StatefulSet hè un ughjettu Kubernetes chì gestisce parechje carichi di travagliu stateful, è tali carichi di travagliu necessitanu coordinazione. StatefulSets furnisce garanzii in quantu à l'ordine di pods è a so unicità.
• servizii senza testa: I servizii permettenu di staccà pods da i clienti cù un nome logicu. Kubernetes in questu casu hè rispunsevule per l'equilibriu di carica. Tuttavia, quandu operanu carichi di travagliu stateful, cum'è ZooKeeper è Kafka, i clienti anu bisognu di cumunicà cù una istanza specifica. Hè quì chì i servizii senza testa sò utili: in questu casu, u cliente hà sempre un nome lògicu, ma ùn avete micca bisognu di cuntattà u pod direttamente.
• Volume di almacenamento à longu andà: Questi volumi sò necessarii per cunfigurà l'almacenamiento persistente di bloccu non-lucale citatu sopra.

nantu Yolean Fornisce un inseme cumpletu di manifesti per aiutà à inizià cù Kafka in Kubernetes.

Grafici Helm

Helm hè un gestore di pacchetti per un Kubernetes chì pò esse paragunatu à i gestori di pacchetti OS cum'è yum, apt, Homebrew o Chocolatey. Facilita l'installazione di pacchetti software predefiniti descritti in i charts Helm. Un graficu Helm ben sceltu rende u travagliu difficiule di cumu cunfigurà bè tutti i paràmetri per aduprà Kafka in Kubernetes faciule. Ci sò parechji diagrammi Kafka: l'uffiziale hè situatu in cundizione d'incubatrice, ci hè unu da Confluente, unu di più - da Bitnami.

Operators

Perchè Helm hà certi difetti, un altru strumentu guadagna una popularità considerableu: l'operatori Kubernetes. L'operatore ùn solu pacchetti software per Kubernetes, ma permette ancu di implementà tali software è gestisce.

In a lista operatori maravigghiusu Sò citati dui operatori per Kafka. Unu di elli - Strimzi. Cù Strimzi, hè faciule fà mette in funzione u vostru cluster Kafka in pochi minuti. Praticamente nisuna cunfigurazione hè necessaria, in più, l'operatore stessu furnisce alcune caratteristiche piacevuli, per esempiu, criptografia TLS puntu à puntu in u cluster. Confluent furnisce ancu propiu operatore.

Produttività

Hè impurtante di pruvà a prestazione benchmarkendu a vostra istanza Kafka. Tali testi vi aiuteranu à truvà colli di bottiglia potenziale prima di prublemi. Per furtuna, Kafka furnisce digià dui strumenti di teste di rendiment: kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. Fate un usu attivu di elli. Per riferimentu, pudete riferite à i risultati descritti in stu postu Jay Kreps, o fucalizza nantu sta rivista Amazon MSK di Stéphane Maarek.

Operazioni

Monitoramentu

A trasparenza in u sistema hè assai impurtante - altri ùn capisce micca ciò chì succede in questu. Oghje ci hè un solidu toolkit chì furnisce un monitoraghju basatu in metriche in u stilu nativu di nuvola. Dui strumenti populari per questu scopu sò Prometheus è Grafana. Prometheus pò raccoglie metriche da tutti i prucessi Java (Kafka, Zookeeper, Kafka Connect) utilizendu un esportatore JMX - in u modu più simplice. Se aghjunghje metriche di cAdvisor, pudete capisce più cumpletamente cumu si usanu e risorse in Kubernetes.

Strimzi hà un esempiu assai convenientu di un dashboard Grafana per Kafka. Visualizeghja metriche chjave, per esempiu, nantu à i settori sottu-replicati o quelli chì sò offline. Tuttu hè assai chjaru quì. Queste metriche sò cumplementate da l'utilizazione di risorse è l'infurmazioni di rendiment, è ancu indicatori di stabilità. Allora uttene un monitoraghju di cluster Kafka di basa per nunda!

Source: streamzi.io/docs/master/#kafka_dashboard

Saria bellu di cumplementà tuttu questu cù u monitoraghju di i clienti (metriche nantu à i cunsumatori è i pruduttori), è ancu u monitoraghju di latenza (per questu ci hè Burrow) è u monitoraghju end-to-end - per questu usu Monitor Kafka.

Logging

Logging hè un altru compitu criticu. Assicuratevi chì tutti i cuntenituri in a vostra installazione Kafka sò logati stdout и stderr, è assicuratevi ancu chì u vostru cluster Kubernetes aggrega tutti i logs in una infrastruttura di logging centrale, per esempiu. Elasticsearch.

Pruvenzi funziunale

Kubernetes usa sonde di vivacità è di prontezza per verificà se i vostri pods funzionanu normalmente. Se a verificazione di vita fallisce, Kubernetes fermarà quellu containeru è poi riavvia automaticamente se a pulitica di riavviu hè stabilita in cunseguenza. Se a verificazione di a preparazione falla, Kubernetes isola u pod da e richieste di serviziu. Cusì, in tali casi, l'intervenzione manuale ùn hè più necessaria, chì hè un grande plus.

Stendu l'aghjurnamenti

StatefulSets supportanu l'aghjurnamenti automatichi: se selezziunate a strategia RollingUpdate, ognunu sottu Kafka serà aghjurnatu in turnu. In questu modu, u downtime pò esse ridutta à zero.

Scaling

Scaling un cluster Kafka ùn hè micca un compitu faciule. In ogni casu, Kubernetes rende assai faciule scalate pods à un certu nùmeru di rèpliche, chì significa chì pudete definisce in modu dichjarazione quanti brokers Kafka vulete. A cosa più difficiuli in questu casu hè riassignà i settori dopu à scaling up o prima di scaling down. In novu, Kubernetes vi aiuterà cù questu compitu.

Amministrazione

I travaglii ligati à l'amministrazione di u vostru cluster Kafka, cum'è a creazione di temi è a riassignazione di settori, ponu esse realizati cù script di shell esistenti aprendu l'interfaccia di linea di cumanda in i vostri pods. Tuttavia, sta suluzione ùn hè micca assai bella. Strimzi supporta a gestione di temi cù un operatore diversu. Ci hè qualchì spaziu per migliurà quì.

Salvà è restaurà

Avà a dispunibilità di Kafka dependerà ancu di a dispunibilità di Kubernetes. Se u vostru cluster Kubernetes falla, allora in u peghju scenariu, u vostru cluster Kafka falla ancu. Sicondu a lege di Murphy, questu sarà di sicuru accadutu, è perde dati. Per riduce stu tipu di risicu, avete un bonu cuncettu di salvezza. Pudete aduprà MirrorMaker, una altra opzione hè di utilizà S3 per questu, cum'è descrittu in questu postu da Zalando.

cunchiusioni

Quandu travaglia cù clusters Kafka di picculi è mediu, vale a pena aduprà Kubernetes perchè furnisce una flessibilità supplementaria è simplifica l'esperienza di l'operatore. Sì avete una latenza non-funzionale assai significativa è / o esigenze di throughput, allora pò esse megliu cunsiderà una altra opzione di implementazione.

Source: www.habr.com