Je Kafka na Kubernetes dobra ideja?

Pozdravljamo vas, Habr!

V svoj čas smo prvi predstavili temo na ruski trg Kafka in še vedno slediti smo njeno razvijanje. Zlasti se nam je zdelo zanimivo sodelovanje med Kafka in Kubernetes. Pregledna (in precej previdna) članek o tej temi je bila objavljena na blogu podjetja Confluent že oktobra lani, avtorica je bila Gwen Shapira. Danes bi vam želeli opozoriti na nekoliko novejši aprilski članek Johann Gygerja, kiče obstaja s vprašajem v naslovu, obravnava temo na bolj vsebinski način, in spremlja besedilo z zanimivimi povezavami. Opravičujemo se za prosto prevajanje "chaos monkey", če lahko!

Uvod

Kubernetes je zasnovan za delo z obremenitvami, ki ne ohranjajo stanja. Običajno so takšne delovne obremenitve predstavljene v obliki mikroservisne arhitekture, so lahke, dobro se razširijo horizontalno, spoštujejo načela 12 faktor aplikacij, omogočajo delovanje z avtomatskimi odklopniki (circuit breaker) in kaos opicami (chaos monkeys).

Kafka pa z druge strani v resnici deluje kot razdeljena baza podatkov. Tako ob delu naletite na stanje, ki je precej težje od mikroservisa. Kubernetes podpira obremenitve z ohranjanjem stanja, vendar, kot opozarja Kelsey Hightower v dveh svojih tweetih, je s temi potrebno ravnati previdno:

Nekaterim se zdi, da če se na obremenitev z ohranjanjem stanja namesti Kubernetes, ta postane popolnoma upravljana baza podatkov, ki je zmožna tekmovati z RDS. To ne drži. Morda, če se dovolj potrudite, dodate dodatne komponente in pritegnete ekipo SRE inženirjev, lahko uspete ustvariti RDS na vrhu Kubernetesa.

Vedno priporočam izjemno previdnost pri zagonu obremenitev z ohranjanjem stanja na Kubernetesu. Večina tistih, ki se sprašujejo: "Ali lahko na Kubernetesu zagnati obremenitve z ohranjanjem stanja" nima dovolj izkušenj z delom s Kubernetesom, v mnogih primerih pa tudi z obremenitvijo, o kateri sprašujejo.

Torej, ali naj se Kafka poganja na Kubernetesu? Nasprotno vprašanje: ali bi Kafka delovala bolje brez Kubernetes? Zato želim v tem članku poudariti, kako se Kafka in Kubernetes dopolnjujeta ter katere pasti se lahko pojavijo pri njunem kombiniranju.

Vreme izvođenja

Pogovorimo se o osnovni stvari — o okolju za izvrševanje kot takem.

Postopek

Brokerski strežniki Kafka so priročni pri delu s procesorjem. TLS lahko prinese določene stroške. Hkrati lahko stranke Kafka močneje obremenijo procesor, če uporabljajo šifriranje, a to ne vpliva na brokerje.

Pomnilnik

Brokerski strežniki Kafka hitro zasedejo pomnilnik. Velikost JVM kupa je običajno omejena na 4–5 GB, vendar boste potrebovali tudi veliko sistemskega pomnilnika, saj Kafka zelo aktivno uporablja predpomnilnik strani. V Kubernetesu ustrezno nastavite omejitve virov in zahteve za kontejner.

Shramba podatkov

Shramba podatkov v kontejnerjih je efemerna – podatki se izgubijo ob ponovnem zagonu. Za podatke Kafka lahko uporabite volumen emptyDir, in učinek bo podoben: podatki vašega brokerja bodo izgubljeni po končanem delu. Vaša sporočila se vseeno lahko ohranijo na drugih brokerjih kot replike. Zato mora broker, ki je odpovedal, najprej replicirati vse podatke, kar lahko traja kar nekaj časa.

Zato je treba uporabiti dolgoročno shrambo podatkov. Naj bo to neolokalna dolgoročna shramba s datotečnim sistemom XFS ali, natančneje, ext4. Nefunkcionirajte NFS. Opozoril sem vas. NFS različic v3 ali v4 ne bo delovala. Na kratko, broker Kafka bo končal delo, če ne bo mogel izbrisati imenika s podatki zaradi težave z "neumnimi preimeničenji", ki velja za NFS. Če vas do sedaj še nisem prepričal, bodite zelo pozorni preberite ta članek. Shramba podatkov mora biti neolokalna, da bo Kubernetes lahko bolj fleksibilno izbral nov vozlišče po ponovnem zagonu ali preselitvi.

Omrežje

Kot v primeru večine distribuiranih sistemov, je uspešnost Kafke močno odvisna od minimalnih zamud v omrežju in maksimalne pasovne širine. Ne poskušajte spraviti vseh posrednikov na isto vozlišče, saj se bo s tem zmanjšala razpoložljivost. Če se vozlišče Kubernetes ustavi, bo celoten grozd Kafke prav tako odpovedal. Prav tako ne porazdeli energijo Kafke čez celotna podatkovna središča. Enako velja za grozd Kubernetes. Dober kompromis v tem primeru je izbira različnih območij dostopnosti.

Конфигурация

Običajni manifesti

Na spletni strani Kubernetes je zelo dobra smernica o tem, kako nastaviti ZooKeeper s pomočjo manifestov. Ker je ZooKeeper del Kafke, je to dobro izhodišče za spoznavanje konceptov, ki se tukaj uporabljajo v Kuberneteseu. Ko se s tem tekoče spoznate, boste lahko uporabili iste koncepte tudi za grozd Kafke.

• Pod: pod - to je najmanjša enota, ki jo je mogoče razporediti v Kubernetesu. V podu se nahaja vaša delovna obremenitev, pod pa ustreza procesu v vašem grozdu. V podu je lahko en ali več vsebnika. Vsaka strežnik ZooKeeper v ansamblu in vsak posrednik v grozdu Kafke delujeta v ločenem podu.
• StatefulSet: StatefulSet je Kubernetes objekt, ki deluje z več delovnimi obremenitvami, ki ohranjajo stanje, kar te obremenitve zahtevajo usklajevanje. StatefulSet zagotavlja zagotovila glede zaporedja podov in njihove edinstvenosti.
• Bezne storitve: Storitve omogočajo ločevanje podov od strank z uporabo logičnega imena. Kubernetes v tem primeru skrbi za obremenitev. Vendar pa, pri delovnih obremenitvah, ki ohranjajo stanje, kot so ZooKeeper in Kafka, morajo stranke komunicirati s specifično instanco. Takrat pridejo prav bezne storitve: v tem primeru bo stranka še vedno imela logično ime, vendar se ne bo treba neposredno povezati s podom.
• Prostor za dolgotrajno shranjevanje: take prostori so potrebni za konfiguracijo nelokalnega blokiranega dolgotrajnega shranjevanja, ki je bilo omenjena zgoraj.

Na Yolean ponuja izčrpen nabor manifestov, s katerimi se enostavno začnete ukvarjati s Kafko v Kubernetesu.

Helm-diagrami

Helm je upravitelj paketa za Kubernetes koji se može usporediti s upraviteljima paketa za operacijske sustave, poput yum, apt, Homebrew ili Chocolatey. Uz njegovu pomoć, lako je instalirati unaprijed definirane programske pakete opisane u Helm dijagramima. Dobro osmišljen Helm dijagram olakšava složen zadatak: kako pravilno konfigurirati sve postavke za korištenje Kafke na Kubernetesu. Postoji nekoliko dijagrama Kafke: službeni se nalazi u inkubacijskom stanju, jedan dolazi od Confluent, a još jedan od Bitnami.

Operaterji

Budući da Helm ima određene nedostatke, drugo sredstvo postaje sve popularnije: operateri Kubernetes-a. Operater ne samo da pakuje softver za Kubernetes, već vam omogućuje i njegovo implementiranje i upravljanje njime.

Na popisu izvrsnih operatera spominju se dva operatera za Kafku. Jedan od njih je Strimzi. Uz pomoć Strimzija nije teško pokrenuti Kafkin klaster u nekoliko minuta. Praktički nije potrebno nikakvo podešavanje, osim toga, sam operater nudi nekoliko ugodnih mogućnosti, poput TLS enkripcije tipa "točka-točka" unutar klastera. Confluent također pruža svoj operater.

Performansa

Vrlo je važno testirati performanse, opskrbljujući vaš instalirani primjerak Kafke kontrolnim točkama. Takva testiranja će vam pomoći otkriti potencijalna uska grla prije nego što problemi počnu. Na sreću, Kafka već ima dva alata za testiranje performansi: kafka-producer-perf-test.sh in kafka-consumer-perf-test.sh. Aktivno ih koristite. Za referencu se možete usporediti s rezultatima opisanim u ovom postu Jaya Krepsa, ili se usmjeriti na ovu recenziju Amazon MSK od Stéphanea Maareka.

Operacije

Nadzor

Transparentnost u sustavu je izuzetno važna – inače nećete razumjeti što se u njemu događa. Danas postoji solidan set alata koji pružaju nadzor na temelju mjernih podataka u stilu cloud native. Dva popularna alata za ovu svrhu su Prometheus i Grafana. Prometheus može prikupljati mjerni podaci sa svih Java procesa (Kafka, Zookeeper, Kafka Connect) koristeći JMX izvođač – na najjednostavniji način. Ako pridružite metrike cAdvisor-a, moći ćete bolje razumjeti kako se resursi koriste u Kubernetesu.

Strimzi ima vrlo korisnu Grafana nadzornu ploču za Kafka. Vizualizira ključne metrike, kao što su nedovoljno replikirani sektori ili oni koji su izvan mreže. Sve je to vrlo jasno. Ove metrike se dopunjuju informacijama o korišćenju resursa i performansama, kao i indikatorima stabilnosti. Tako dobijate osnovni nadzor nad Kafka klasterom potpuno besplatno!

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

Sve ovo bi bilo dobro dopuniti praćenjem klijenata (metrike za konzumente i producite), kao i monitoringom latencije (za to postoji Burrow) i sveobuhvatnim monitoringom – za to koristite Kafka Monitor.

Zapisovanje

Logiranje je još jedan veoma važan zadatak. Uverite se da svi kontejneri u vašoj Kafka instalaciji logiraju u stdout in stderr, a takođe se postarajte da vaš Kubernetes klaster agregira sve logove u centralnu infrastrukturu za logove, na primer, u Elasticsearch.

Preverjanje delovanja

Kubernetes koristi probe „životnosti“ (liveness) i spremnosti (readiness) kako bi proverio da li su vaši podovi u normalnom stanju. Ako proba životnosti ne uspe, Kubernetes će zaustaviti taj kontejner, a zatim ga automatski ponovo pokrenuti, ako je politika ponovnog pokretanja podešena odgovarajuće. Ako proba spremnosti ne uspe, Kubernetes će izolovati taj pod od obrada zahteva. Tako u takvim slučajevima više nije potrebno ručno intervenirati, a to je velika prednost.

Provođenje ažuriranja

StatefulSet podržava automatska ažuriranja: pri izboru strategije RollingUpdate svaki pod Kafka će se ažurirati jedan po jedan. Tako se može smanjiti vreme zastoja na nulu.

Skaliranje

Širenje Kafka klastera nije lak zadatak. Međutim, u Kubernetes-u je veoma lako skalirati podove na određeni broj replika, što znači da možete deklarativno odrediti koliko god želite Kafka brokera. Najteži deo u ovom slučaju je ponovna dodela sektora nakon povećanja ili smanjenja skaliranja. Ponovo, Kubernetes će vam pomoći u ovom zadatku.

Administracija

Naloge, povezane z upravljanjem vašega Kafka klasterja, kot so ustvarjanje tem in prerazporejanje particij, lahko opravite s pomočjo obstoječih shell skriptov, tako da odprete ukazno vrstico v vaših podih. Vendar to ni najbolj estetska rešitev. Strimzi podpira upravljanje tem z drugim operaterjem. Tu je še veliko prostora za izboljšave.

Varnostno kopiranje in obnova

Zdaj bo naša razpoložljivost Kafka odvisna tudi od razpoložljivosti Kubernetes. Če pride do odpovedi vašega Kubernetes klasterja, bo v najslabšem primeru odpovedal tudi klaster Kafka. Po Murphyjevem zakonu se to nujno zgodi in tako boste izgubili podatke. Da bi zmanjšali tveganje takšnega dogodka, skrbno načrtujte koncept varnostnega kopiranja. Lahko uporabite MirrorMaker, druga možnost pa je uporaba S3, kot je opisano v tem objavi od Zalanda.

Zaključek

Pri delu z manjšimi ali srednjimi klasterji Kafka je zagotovo smiselno uporabljati Kubernetes, saj omogoča dodatno prilagodljivost in poenostavi delo z operaterji. Če imate resne nefunkcionalne zahteve glede zakasnitve in/ali propustnosti, bi morda bilo bolje razmisliti o drugi možnosti uvajanja.

Izvor: habr.com