Je li Kafka na Kubernetesu dobar?

Pozdrav, Habr!

Svojedobno smo tu temu prvi uveli na rusko tržište Kafka i nastavi staza za njegov razvoj. Konkretno, pronašli smo temu interakcije između Kafke i Kubernetes. Uočljiv (i prilično oprezan) članak ova je tema objavljena na blogu Confluent još u listopadu prošle godine pod autorstvom Gwen Shapira. Danas vam želimo skrenuti pozornost na noviji članak iz travnja Johanna Gygera, koji, iako ne bez upitnika u naslovu, temu obrađuje sadržajnije, prateći tekst zanimljivim poveznicama. Molimo vas da nam oprostite besplatni prijevod "majmuna kaosa" ako možete!

Uvod

Kubernetes je dizajniran za rukovanje radnim opterećenjima bez stanja. Obično su takva radna opterećenja predstavljena u obliku mikrouslužne arhitekture, lagana su, dobro se skaliraju vodoravno, slijede načela 12-faktorskih aplikacija i mogu raditi s prekidačima i kaos majmunima.

Kafka, s druge strane, u biti djeluje kao distribuirana baza podataka. Dakle, u radu se morate nositi sa stanjem, a ono je puno teže od mikroservisa. Kubernetes podržava učitavanja stanja, ali kako ističe Kelsey Hightower u dva tweeta, s njima treba postupati pažljivo:

Neki ljudi smatraju da ako ubacite Kubernetes u radno opterećenje s praćenjem stanja, on postaje potpuno upravljana baza podataka koja je konkurent RDS-u. To je pogrešno. Možda ćete, ako se dovoljno potrudite, dodate dodatne komponente i privučete tim SRE inženjera, moći izgraditi RDS na vrhu Kubernetesa.

Uvijek preporučujem da svi budu krajnje oprezni pri pokretanju radnih opterećenja sa stanjem na Kubernetesu. Većina ljudi koji pitaju "mogu li pokrenuti statusna radna opterećenja na Kubernetesu" nema dovoljno iskustva s Kubernetesom, a često i s radnim opterećenjem o kojem pitaju.

Dakle, trebate li pokrenuti Kafku na Kubernetesu? Protupitanje: hoće li Kafka raditi bolje bez Kubernetesa? Zato u ovom članku želim istaknuti kako se Kafka i Kubernetes međusobno nadopunjuju i koje zamke mogu naići na njihovo kombiniranje.

Vrijeme završetka

Razgovarajmo o osnovnoj stvari – samom vremenu izvođenja

proces

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

memorija

Kafka brokeri izjedaju sjećanje. Veličina hrpe JVM-a obično je ograničena na 4-5 GB, ali također ćete trebati mnogo sistemske memorije budući da Kafka vrlo intenzivno koristi predmemoriju stranice. U Kubernetesu postavite resurs spremnika i ograničenja zahtjeva u skladu s tim.

Pohrana podataka

Pohranjivanje podataka u spremnike je kratkotrajno - podaci se gube prilikom ponovnog pokretanja. Za Kafkine podatke možete koristiti volumen emptyDir, a učinak će biti sličan: podaci o brokeru bit će izgubljeni nakon završetka. Vaše poruke i dalje mogu biti pohranjene na drugim brokerima kao replike. Stoga, nakon ponovnog pokretanja, neuspjeli broker prvo mora replicirati sve podatke, a taj proces može potrajati dosta vremena.

Zbog toga biste trebali koristiti dugoročnu pohranu podataka. Neka to bude ne-lokalna dugoročna pohrana s XFS datotečnim sustavom ili, točnije, 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 podatkovni direktorij zbog problema "glupog preimenovanja" u NFS-u. Ako vas još nisam uvjerio, vrlo pažljivo pročitajte ovaj članak. Pohrana podataka ne bi trebala biti lokalna kako bi Kubernetes mogao fleksibilnije odabrati novi čvor nakon ponovnog pokretanja ili premještanja.

Mreža

Kao i kod većine distribuiranih sustava, izvedba Kafke uvelike ovisi o održavanju latencije mreže na minimumu i maksimiziranju propusnosti. Ne pokušavajte ugostiti sve brokere na istom čvoru jer će to smanjiti dostupnost. Ako Kubernetes čvor zakaže, otkazat će cijeli Kafka klaster. Također, nemojte disperzirati Kafka klaster po cijelim podatkovnim centrima. Isto vrijedi i za Kubernetes klaster. Dobar kompromis u ovom slučaju je odabir različitih zona dostupnosti.

Konfiguracija

Redoviti manifesti

Web stranica Kubernetes ima vrlo dobar vodič o tome kako konfigurirati ZooKeeper pomoću manifesta. Budući da je ZooKeeper dio Kafke, ovo je dobro mjesto za početak upoznavanja s konceptima Kubernetesa koji se ovdje primjenjuju. Kad ovo shvatite, možete koristiti iste koncepte s Kafkinim klasterom.

• ispod: 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 spremnika. Svaki ZooKeeper poslužitelj u ansamblu i svaki posrednik u Kafka klasteru radit će u zasebnom modulu.
• StatefulSet: StatefulSet je Kubernetesov objekt koji obrađuje višestruka radna opterećenja s praćenjem stanja, a takva radna opterećenja zahtijevaju koordinaciju. StatefulSets pružaju jamstva u vezi s redoslijedom mahuna i njihovom jedinstvenošću.
• Usluge bez glave: Usluge vam omogućuju da odvojite module od klijenata koristeći logično ime. Kubernetes je u ovom slučaju odgovoran za balansiranje opterećenja. Međutim, kada rade s radnim opterećenjima s praćenjem stanja, kao što su ZooKeeper i Kafka, klijenti moraju komunicirati s određenom instancom. Ovdje su korisne usluge bez glave: u ovom slučaju klijent će i dalje imati logično ime, ali nećete morati izravno kontaktirati pod.
• Volumen dugotrajne pohrane: Ovi su volumeni potrebni za konfiguriranje gore spomenute nelokalne blokovne trajne pohrane.

Na Yolean Pruža opsežan skup manifesta koji će vam pomoći da započnete s Kafkom na Kubernetesu.

Karte kormila

Helm je upravitelj paketa za Kubernetes koji se može usporediti s upraviteljima paketa OS-a kao što su yum, apt, Homebrew ili Chocolatey. Olakšava instalaciju unaprijed definiranih softverskih paketa opisanih u Helmovim kartama. Dobro odabran Helm grafikon olakšava težak zadatak pravilnog konfiguriranja svih parametara za korištenje Kafke na Kubernetesu. Postoji nekoliko Kafkinih dijagrama: službeni se nalazi u stanju inkubatora, postoji jedan od pritoka, još jedan - od Bitnami.

operatori

Budući da Helm ima određene nedostatke, još jedan alat dobiva značajnu popularnost: Kubernetes operatori. Operater ne samo da pakira softver za Kubernetes, već vam također omogućuje implementaciju takvog softvera i upravljanje njime.

Na popisu nevjerojatni operateri Spominju se dva operatera za Kafku. Jedan od njih - Strimzi. Uz Strimzi, lako je pokrenuti vaš Kafka klaster u nekoliko minuta. Gotovo nije potrebna nikakva konfiguracija, osim toga, sam operater pruža neke zgodne značajke, na primjer, point-to-point TLS enkripciju unutar klastera. Confluent također pruža vlastiti operater.

Performanse

Važno je testirati izvedbu usporednom analizom svoje Kafka instance. Takvi testovi pomoći će vam pronaći 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 usredotočite se na ovu recenziju Amazon MSK Stéphanea Maareka.

operacije

nadgledanje

Transparentnost u sustavu je vrlo važna - inače nećete razumjeti što se u njemu događa. Danas postoji solidan skup alata koji omogućuje praćenje temeljeno na mjernim podacima u izvornom stilu oblaka. Dva popularna alata za tu svrhu su Prometheus i Grafana. Prometheus može prikupiti metriku iz svih Java procesa (Kafka, Zookeeper, Kafka Connect) koristeći JMX exporter - na najjednostavniji način. Ako dodate cAdvisor metriku, možete potpunije razumjeti kako se resursi koriste u Kubernetesu.

Strimzi ima vrlo zgodan primjer Grafana nadzorne ploče za Kafku. Vizualizira ključne metrike, na primjer, o nedovoljno repliciranim sektorima ili onima koji su izvan mreže. Tu je sve vrlo jasno. Ove metrike nadopunjuju informacije o korištenju resursa i performansama, kao i pokazatelji stabilnosti. Dakle, dobivate osnovni Kafka nadzor klastera za ništa!

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

Bilo bi lijepo sve to nadopuniti praćenjem klijenta (metrike potrošača i proizvođača), kao i praćenjem latencije (za to postoji jazbina) i praćenje od početka do kraja - za ovu upotrebu Monitor Kafka.

Sječa drva

Zapisivanje je još jedan važan zadatak. Provjerite jesu li svi spremnici u vašoj Kafka instalaciji prijavljeni stdout и stderr, a također osigurajte da vaš Kubernetes klaster agregira sve zapisnike u središnju infrastrukturu zapisivanja, npr. Elasticsearch.

Provjera funkcionalnosti

Kubernetes koristi sonde živosti i spremnosti da provjeri rade li vaši moduli normalno. Ako provjera živosti ne uspije, Kubernetes će zaustaviti taj spremnik i zatim ga automatski ponovno pokrenuti ako je pravilo ponovnog pokretanja postavljeno u skladu s tim. Ako provjera spremnosti ne uspije, Kubernetes izolira modul od zahtjeva za servisiranjem. Dakle, u takvim slučajevima više uopće nije potrebna ručna intervencija, što je veliki plus.

Izvođenje ažuriranja

StatefulSetovi podržavaju automatska ažuriranja: ako odaberete strategiju RollingUpdate, svaki pod Kafkom će se redom ažurirati. Na taj se način vrijeme zastoja može svesti na nulu.

Skaliranje

Skaliranje Kafkinog klastera nije lak zadatak. Međutim, Kubernetes čini vrlo jednostavnim skaliranje podova na određeni broj replika, što znači da možete deklarativno definirati onoliko Kafka brokera koliko želite. Najteža stvar u ovom slučaju je ponovno dodjeljivanje sektora nakon skaliranja ili prije skaliranja. Opet, Kubernetes će vam pomoći s ovim zadatkom.

uprava

Zadaci koji se odnose na administriranje vašeg Kafka klastera, kao što je stvaranje tema i ponovno dodjeljivanje sektora, mogu se obaviti pomoću postojećih skripti ljuske otvaranjem sučelja naredbenog retka u vašim podovima. Međutim, ovo rješenje nije baš lijepo. Strimzi podržava upravljanje temama pomoću drugog operatera. Ovdje ima prostora za napredak.

Rezervno kopiranje i odsustvovanje

Sada će dostupnost Kafke također ovisiti o dostupnosti Kubernetesa. Ako vaš Kubernetes klaster zakaže, tada će u najgorem slučaju zakazati i vaš Kafka klaster. Prema Murphyjevom zakonu, to će se sigurno dogoditi, a vi ćete izgubiti podatke. Kako biste smanjili ovu vrstu rizika, imajte dobar koncept sigurnosne kopije. Možete koristiti MirrorMaker, druga opcija je korištenje S3 za ovo, kao što je opisano u ovome post iz Zalanda.

Zaključak

Kada radite s malim do srednjim Kafka klasterima, svakako se isplati koristiti Kubernetes jer pruža dodatnu fleksibilnost i pojednostavljuje iskustvo operatera. Ako imate vrlo značajnu nefunkcionalnu latenciju i/ili zahtjeve za propusnost, možda bi bilo bolje razmotriti neku drugu opciju postavljanja.

Izvor: www.habr.com