Da li je Kafka na Kubernetesu dobar?

Pozdrav, Habr!

Svojevremeno smo prvi uveli ovu temu na rusko tržište Kafka i nastavi track za njen razvoj. Posebno smo pronašli temu interakcije između Kafke i Kubernet. Uočljivo (i prilično oprezno) članak ova tema je objavljena na blogu Confluent još u oktobru prošle godine pod autorstvom Gwen Shapira. Danas vam skrećemo pažnju na noviji članak iz aprila Johanna Gygera, koji, iako ne bez znaka pitanja u naslovu, istražuje temu na sadržajniji način, prateći tekst zanimljivim linkovima. Oprostite nam besplatni prijevod “haos monkey” ako možete!

Uvod

Kubernetes je dizajniran za rukovanje radnim opterećenjima bez stanja. Obično su takva opterećenja predstavljena u obliku mikroservisne arhitekture, lagana su, dobro se skaliraju horizontalno, slijede principe aplikacija s 12 faktora i mogu raditi sa prekidačima i haos majmunima.

Kafka, s druge strane, u suštini djeluje kao distribuirana baza podataka. Dakle, kada radite, morate imati posla sa stanjem, a ono je mnogo teže od mikroservisa. Kubernetes podržava učitavanje stanja, ali kao što Kelsey Hightower ističe u dva tvita, njima treba postupati pažljivo:

Neki ljudi smatraju da, ako uključite Kubernetes u radno opterećenje sa stanjem, on postaje potpuno upravljana baza podataka koja je rival RDS-u. Ovo je pogrešno. Možda ćete, ako dovoljno radite, dodate dodatne komponente i privučete tim SRE inženjera, moći da napravite RDS na vrhu Kubernetesa.

Uvek preporučujem svima da budu izuzetno oprezni pri pokretanju radnih opterećenja na Kubernetesu. Većina ljudi koji pitaju „mogu li pokrenuti radna opterećenja s podacima o stanju na Kubernetesu“ nemaju dovoljno iskustva s Kubernetesom, a često i s radnim opterećenjem o kojem se pitaju.

Dakle, treba li pokrenuti Kafku na Kubernetesu? Protivpitanje: hoće li Kafka bolje raditi bez Kubernetesa? Zato želim da u ovom članku istaknem kako se Kafka i Kubernetes nadopunjuju i koje zamke mogu nastati pri njihovom kombinovanju.

Vrijeme završetka

Hajde da pričamo o osnovnoj stvari - samom runtime okruženju

proces

Kafka brokeri su prilagođeni procesoru. TLS može dovesti do nekih dodatnih troškova. Međutim, Kafka klijenti mogu biti intenzivniji za CPU ako koriste enkripciju, ali to ne utiče na brokere.

memorija

Kafkini brokeri jedu memoriju. Veličina JVM gomile je obično ograničena na 4-5 GB, ali će vam takođe trebati mnogo sistemske memorije pošto Kafka jako koristi keš stranice. U Kubernetesu postavite resurse kontejnera i ograničenja zahtjeva u skladu s tim.

Skladište podataka

Skladištenje podataka u kontejnerima je efemerno - podaci se gube pri ponovnom pokretanju. Za Kafka podatke možete koristiti volumen emptyDir, a efekat će biti sličan: vaši brokerski podaci će biti izgubljeni nakon završetka. Vaše poruke i dalje mogu biti pohranjene na drugim brokerima kao replike. Stoga, nakon ponovnog pokretanja, propali broker mora prvo replicirati sve podatke, a ovaj proces može potrajati mnogo vremena.

Zbog toga biste trebali koristiti dugotrajno skladištenje podataka. Neka to bude nelokalno dugotrajno skladištenje sa XFS sistemom datoteka ili, preciznije, ext4. Nemojte koristiti NFS. Upozorio sam te. NFS verzije v3 ili v4 neće raditi. Ukratko, Kafka broker će se srušiti ako ne može izbrisati direktorij podataka zbog problema "glupog preimenovanja" u NFS-u. Ako vas još nisam uvjerio, vrlo pažljivo pročitajte ovaj članak. Skladište podataka treba biti nelokalno kako bi Kubernetes mogao fleksibilnije izabrati novi čvor nakon ponovnog pokretanja ili premještanja.

Mreža

Kao i kod većine distribuiranih sistema, Kafkine performanse u velikoj meri zavise od održavanja mrežnog kašnjenja na minimumu i maksimalnog propusnog opsega. Ne pokušavajte ugostiti sve brokere na istom čvoru, jer će to smanjiti dostupnost. Ako Kubernetes čvor zakaže, cijeli Kafka klaster će otkazati. Takođe, nemojte rasipati Kafka klaster po čitavim centrima podataka. Isto važi i za Kubernetes klaster. Dobar kompromis u ovom slučaju je odabir različitih zona dostupnosti.

Konfiguracija

Redovni manifesti

Kubernetes web stranica ima veoma dobar vodič o tome kako konfigurirati ZooKeeper koristeći manifeste. Budući da je ZooKeeper dio Kafke, ovo je dobro mjesto za početak da se upoznate s tim koji se Kubernetes koncepti ovdje primjenjuju. Kada ovo shvatite, možete koristiti iste koncepte sa Kafka klasterom.

• By: Pod je najmanja jedinica koja se može rasporediti u Kubernetesu. Pod sadrži vaše radno opterećenje, a sam pod odgovara procesu u vašem klasteru. Mahuna sadrži jedan ili više kontejnera. Svaki ZooKeeper server u ansamblu i svaki broker u Kafka klasteru će raditi u zasebnoj podlozi.
• StatefulSet: StatefulSet je Kubernetes objekat koji rukuje višestrukim radnim opterećenjima sa stanjem, a takva radna opterećenja zahtijevaju koordinaciju. StatefulSets pružaju garancije u vezi s redoslijedom podova i njihove jedinstvenosti.
• Bezglave usluge: Usluge vam omogućavaju da odvojite podove od klijenata koristeći logično ime. Kubernetes je u ovom slučaju odgovoran za balansiranje opterećenja. Međutim, kada upravljaju radnim opterećenjima sa stanjem, kao što su ZooKeeper i Kafka, klijenti moraju komunicirati sa određenom instancom. Ovdje dobro dolaze usluge bez glave: u ovom slučaju, klijent će i dalje imati logično ime, ali nećete morati direktno kontaktirati pod.
• Obim dugotrajnog skladištenja: Ovi volumeni su potrebni za konfiguriranje ne-lokalnog blok trajne memorije spomenute gore.

U Yolean Pruža sveobuhvatan skup manifesta koji će vam pomoći da počnete s Kafkom na Kubernetesu.

Helm charts

Helm je menadžer paketa za Kubernetes koji se može porediti sa menadžerima paketa OS kao što su yum, apt, Homebrew ili Chocolatey. Olakšava instalaciju unaprijed definiranih softverskih paketa opisanih u Helmovim grafikonima. Dobro odabran Helm grafikon čini težak zadatak kako pravilno konfigurirati sve parametre za korištenje Kafke na Kubernetesu. Postoji nekoliko Kafkinih dijagrama: zvanični se nalazi u stanju inkubatora, ima jedan iz Konfuntno, još jedan - od BitNami.

Operatori

Pošto Helm ima određene nedostatke, još jedan alat dobija značajnu popularnost: Kubernetes operateri. Operater ne samo da pakuje softver za Kubernetes, već vam omogućava i da postavite takav softver i upravljate njime.

Na listi neverovatni operateri Pominju se dva operatera za Kafku. Jedan od njih - Strimzi. Sa Strimzijem, lako je pokrenuti svoj Kafka klaster za nekoliko minuta. Gotovo nikakva konfiguracija nije potrebna, osim toga, sam operater pruža neke lijepe karakteristike, na primjer, point-to-point TLS enkripcija unutar klastera. Confluent također pruža sopstveni operater.

Produktivnost

Važno je testirati performanse benchmarkingom vaše Kafka instance. Takvi testovi će vam pomoći da pronađete potencijalna uska grla prije nego što se pojave problemi. Srećom, Kafka već nudi dva alata za testiranje performansi: kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. Aktivno ih koristite. Za referencu, možete pogledati rezultate opisane u ovaj post Jay Kreps, ili se fokusirati na ovu recenziju Amazon MSK autora Stéphanea Maareka.

operacije

Monitoring

Transparentnost u sistemu je veoma važna - inače nećete razumeti šta se u njemu dešava. Danas postoji solidan komplet alata koji pruža praćenje zasnovano na metrikama u izvornom stilu oblaka. Dva popularna alata za ovu svrhu su Prometheus i Grafana. Prometheus može prikupiti metriku iz svih Java procesa (Kafka, Zookeeper, Kafka Connect) koristeći JMX eksporter - na najjednostavniji način. Ako dodate cAdvisor metriku, možete potpunije razumjeti kako se resursi koriste u Kubernetesu.

Strimzi ima vrlo zgodan primjer Grafana kontrolne ploče za Kafku. Vizualizira ključne metrike, na primjer, o sektorima koji se nedovoljno repliciraju ili onima koji su van mreže. Tu je sve vrlo jasno. Ove metrike su dopunjene informacijama o korištenju resursa i performansama, kao i indikatorima stabilnosti. Dakle, uzalud dobijate osnovno praćenje Kafka klastera!

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

Bilo bi lijepo sve ovo dopuniti praćenjem klijenata (metrika o potrošačima i proizvođačima), kao i praćenjem kašnjenja (za to postoji Burrow) i praćenje od kraja do kraja - za ovu upotrebu Kafka Monitor.

Logging

Evidentiranje je još jedan kritičan zadatak. Provjerite jesu li svi kontejneri u vašoj Kafka instalaciji prijavljeni stdout и stderr, a također osigurajte da vaš Kubernetes klaster agregira sve zapise u centralnu infrastrukturu za evidentiranje, npr. Elasticsearch.

Funkcionalno testiranje

Kubernetes koristi sonde za živost i spremnost da provjeri da li vaši podovi rade normalno. Ako provjera živosti ne uspije, Kubernetes će zaustaviti taj kontejner, a zatim ga automatski ponovo pokrenuti ako je politika ponovnog pokretanja postavljena u skladu s tim. Ako provjera spremnosti ne uspije, Kubernetes izolira pod od zahtjeva za servisiranje. Dakle, u takvim slučajevima ručna intervencija više uopće nije potrebna, što je veliki plus.

Uvođenje ažuriranja

StatefulSets podržava automatska ažuriranja: ako odaberete strategiju RollingUpdate, svaki pod Kafka će se ažurirati redom. Na ovaj način se vrijeme zastoja može svesti na nulu.

Skaliranje

Skaliranje Kafka klastera nije lak zadatak. Međutim, Kubernetes olakšava skaliranje podova na određeni broj replika, što znači da možete deklarativno definirati koliko god Kafka brokera želite. Najteža stvar u ovom slučaju je ponovno dodjeljivanje sektora nakon povećanja ili prije smanjenja. Opet, Kubernetes će vam pomoći u ovom zadatku.

Administracija

Zadaci koji se odnose na administriranje vašeg Kafka klastera, kao što je kreiranje tema i preraspodjela sektora, mogu se obaviti korištenjem postojećih shell skripti otvaranjem sučelja komandne linije u vašim podovima. Međutim, ovo rješenje nije baš lijepo. Strimzi podržava upravljanje temama pomoću drugog operatora. Ovdje ima prostora za napredak.

Rezervno kopiranje i odsustvovanje

Sada će dostupnost Kafke zavisiti i od dostupnosti Kubernetesa. Ako vaš Kubernetes klaster ne uspije, onda će u najgorem slučaju i vaš Kafka klaster otkazati. Prema Murphyjevom zakonu, to će se definitivno dogoditi, a vi ćete izgubiti podatke. Da biste smanjili ovu vrstu rizika, imajte dobar koncept rezervne kopije. Možete koristiti MirrorMaker, druga opcija je korištenje S3 za ovo, kao što je opisano u ovome pošta iz Zalanda.

zaključak

Kada radite s malim i srednjim Kafka klasterima, svakako vrijedi koristiti Kubernetes jer pruža dodatnu fleksibilnost i pojednostavljuje iskustvo operatera. Ako imate vrlo značajne nefunkcionalne zahtjeve za kašnjenje i/ili propusnost, onda bi možda bilo bolje razmotriti neku drugu opciju implementacije.

izvor: www.habr.com