Je Kafka na Kubernetesu dober?

Lep pozdrav, Habr!

Nekoč smo bili prvi, ki smo to temo predstavili ruskemu trgu Kafka in nadaljujte skladbo za njen razvoj. Še posebej smo našli temo interakcije med Kafko in Kubernetes. Opazen (in precej previden) članek ta tema je bila objavljena na blogu Confluent oktobra lani pod avtorstvom Gwen Shapira. Danes vas želimo opozoriti na novejši aprilski članek Johanna Gygerja, ki, čeprav ne brez vprašaja v naslovu, tematiko obravnava bolj vsebinsko in besedilo pospremi z zanimivimi povezavami. Prosimo, oprostite nam brezplačen prevod "chaos monkey", če lahko!

Predstavitev

Kubernetes je zasnovan za obvladovanje delovnih obremenitev brez stanja. Običajno so takšne delovne obremenitve predstavljene v obliki arhitekture mikrostoritev, so lahke, dobro vodoravno skalirane, sledijo načelom 12-faktorskih aplikacij in lahko delujejo z odklopniki in opicami kaosa.

Kafka pa v bistvu deluje kot porazdeljena baza podatkov. Tako se morate pri delu ukvarjati s stanjem, ki je veliko težje od mikrostoritve. Kubernetes podpira obremenitve s stanjem, a kot poudarja Kelsey Hightower v dveh tvitih, je treba z njimi ravnati previdno:

Nekateri menijo, da če Kubernetes vključite v delovno obremenitev s stanjem, postane popolnoma upravljana baza podatkov, ki tekmuje z RDS. To je narobe. Če boste dovolj trdo delali, dodali dodatne komponente in pritegnili ekipo SRE inženirjev, boste morda lahko zgradili RDS na vrhu Kubernetesa.

Vsem vedno priporočam, da so zelo previdni pri izvajanju delovnih obremenitev s stanjem v Kubernetesu. Večina ljudi, ki vprašajo, ali lahko izvajam delovne obremenitve s stanjem v Kubernetesu, nima dovolj izkušenj s Kubernetesom in pogosto z delovno obremenitvijo, o kateri sprašujejo.

Bi torej morali zagnati Kafko na Kubernetesu? Nasprotno vprašanje: ali bo Kafka deloval bolje brez Kubernetesa? Zato želim v tem članku poudariti, kako se Kafka in Kubernetes dopolnjujeta in kakšne pasti lahko prinese njuno združevanje.

Čas dokončanja

Pogovorimo se o osnovni stvari – samem izvajalnem okolju

Postopek

Posredniki Kafka so prijazni do procesorja. TLS lahko povzroči nekaj dodatnih stroškov. Vendar so odjemalci Kafka morda bolj obremenjeni s procesorjem, če uporabljajo šifriranje, vendar to ne vpliva na posrednike.

spomin

Kafka posredniki žrejo spomin. Velikost kopice JVM je običajno omejena na 4–5 GB, vendar boste potrebovali tudi veliko sistemskega pomnilnika, saj Kafka zelo močno uporablja predpomnilnik strani. V Kubernetesu nastavite vir vsebnika in ustrezno omejite zahteve.

Shranjevanje podatkov

Shranjevanje podatkov v vsebnikih je kratkotrajno – podatki se ob ponovnem zagonu izgubijo. Za podatke Kafka lahko uporabite obseg emptyDir, učinek pa bo podoben: vaši posredniški podatki bodo po zaključku izgubljeni. Vaša sporočila se lahko še vedno shranijo pri drugih posrednikih kot replike. Zato mora po ponovnem zagonu neuspeli posrednik najprej ponoviti vse podatke, ta postopek pa lahko traja precej časa.

Zato bi morali uporabljati dolgoročno shranjevanje podatkov. Naj bo to nelokalno dolgoročno shranjevanje z datotečnim sistemom XFS ali natančneje ext4. Ne uporabljajte NFS. Posvaril sem te. Različice NFS v3 ali v4 ne bodo delovale. Skratka, posrednik Kafka se bo zrušil, če ne bo mogel izbrisati podatkovnega imenika zaradi problema "neumnega preimenovanja" v NFS. Če vas še nisem prepričal, zelo previdno preberi ta članek. Podatkovna shramba mora biti nelokalna, da lahko Kubernetes bolj prilagodljivo izbere novo vozlišče po ponovnem zagonu ali premestitvi.

Сеть

Kot pri večini porazdeljenih sistemov je delovanje Kafke zelo odvisno od ohranjanja minimalne zakasnitve omrežja in maksimalne pasovne širine. Ne poskušajte gostiti vseh posrednikov na istem vozlišču, saj bo to zmanjšalo razpoložljivost. Če odpove vozlišče Kubernetes, bo odpovedala celotna gruča Kafka. Prav tako ne razpršite gruče Kafka po celih podatkovnih centrih. Enako velja za gručo Kubernetes. Dober kompromis v tem primeru je izbira različnih območij razpoložljivosti.

Konfiguracija

Redni manifesti

Spletno mesto Kubernetes ima zelo dober vodnik o tem, kako konfigurirati ZooKeeper z uporabo manifestov. Ker je ZooKeeper del Kafke, je to dobro mesto za začetek seznanitve s tem, kateri koncepti Kubernetes veljajo tukaj. Ko to razumete, lahko uporabite iste koncepte s Kafkino gručo.

• Pod: Pod je najmanjša razporedljiva enota v Kubernetesu. Pod vsebuje vašo delovno obremenitev, sam pod pa ustreza procesu v vaši gruči. Strok vsebuje enega ali več vsebnikov. Vsak strežnik ZooKeeper v skupini in vsak posrednik v gruči Kafka bo deloval v ločenem paketu.
• StatefulSet: StatefulSet je objekt Kubernetes, ki obravnava več delovnih obremenitev s spremljanjem stanja, takšne delovne obremenitve pa zahtevajo koordinacijo. StatefulSets zagotavljajo jamstva glede naročanja podov in njihove edinstvenosti.
• Storitve brez glave: Storitve vam omogočajo, da ločite pode od strank z uporabo logičnega imena. Kubernetes je v tem primeru odgovoren za uravnoteženje obremenitve. Ko upravljate delovne obremenitve s stanjem, kot sta ZooKeeper in Kafka, pa morajo odjemalci komunicirati z določenim primerkom. Tukaj pridejo prav brezglave storitve: v tem primeru bo stranka še vedno imela logično ime, vendar vam ne bo treba neposredno stopiti v stik s podom.
• Prostornina za dolgoročno shranjevanje: Ti nosilci so potrebni za konfiguracijo zgoraj omenjenega nelokalnega blokovnega trajnega pomnilnika.

Na Yolean Zagotavlja obsežen nabor manifestov, ki vam bodo pomagali začeti uporabljati Kafko v Kubernetesu.

Karte za krmilo

Helm je upravitelj paketov za Kubernetes, ki ga je mogoče primerjati z upravitelji paketov OS, kot so yum, apt, Homebrew ali Chocolatey. Omogoča preprosto namestitev vnaprej določenih programskih paketov, opisanih v grafikonih Helm. Dobro izbran Helmov grafikon olajša težko nalogo, kako pravilno konfigurirati vse parametre za uporabo Kafke v Kubernetesu. Kafkovih diagramov je več: uradni se nahaja v stanju inkubatorja, obstaja ena od Sotočje, še eno - od Bitnami.

Operaterji

Ker ima Helm določene pomanjkljivosti, postaja precej priljubljeno drugo orodje: operaterji Kubernetes. Operater ne le pakira programsko opremo za Kubernetes, ampak vam tudi omogoča, da takšno programsko opremo namestite in jo upravljate.

Na seznamu neverjetni operaterji Omenjena sta dva operaterja za Kafko. En od njih - Strimzi. S Strimzijem je vašo gručo Kafka preprosto postaviti in zagnati v nekaj minutah. Konfiguracija praktično ni potrebna, poleg tega operater sam ponuja nekaj lepih funkcij, na primer TLS šifriranje od točke do točke znotraj gruče. Confluent ponuja tudi lastnega operaterja.

Produktivnost

Pomembno je, da preizkusite zmogljivost s primerjalno analizo svojega primerka Kafka. Takšni testi vam bodo pomagali najti morebitna ozka grla, preden se pojavijo težave. Na srečo Kafka že ponuja dve orodji za testiranje zmogljivosti: kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. Aktivno jih uporabljajte. Za referenco si lahko ogledate rezultate, opisane v ta objava Jay Kreps ali se osredotočite na ta pregled Amazon MSK, avtor Stéphane Maarek.

Operacije

Spremljanje

Transparentnost v sistemu je zelo pomembna – sicer ne boste razumeli, kaj se v njem dogaja. Danes obstaja soliden nabor orodij, ki zagotavlja spremljanje na podlagi meritev v izvirnem slogu v oblaku. Dve priljubljeni orodji za ta namen sta Prometheus in Grafana. Prometheus lahko zbira metrike iz vseh Java procesov (Kafka, Zookeeper, Kafka Connect) z uporabo JMX izvoznika - na najpreprostejši način. Če dodate meritve cAdvisor, lahko bolje razumete, kako se viri uporabljajo v Kubernetesu.

Strimzi ima zelo priročen primer nadzorne plošče Grafana za Kafko. Vizualizira ključne meritve, na primer o premalo podvojenih sektorjih ali tistih, ki so brez povezave. Tam je vse zelo jasno. Te meritve dopolnjujejo informacije o izkoriščenosti virov in zmogljivosti ter kazalniki stabilnosti. Tako dobite osnovno spremljanje grozdov Kafka za nič!

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

Lepo bi bilo vse to dopolniti s spremljanjem odjemalcev (metrike potrošnikov in proizvajalcev), pa tudi spremljanjem latence (za to obstaja burrow) in spremljanje od konca do konca - za to uporabo Monitor Kafka.

Sečnja

Beleženje je še ena kritična naloga. Prepričajte se, da so vsi vsebniki v vaši namestitvi Kafka prijavljeni stdout и stderr, prav tako zagotovite, da vaša gruča Kubernetes združuje vse dnevnike v osrednjo infrastrukturo za beleženje, npr. Elastično iskanje.

Zdravstveni pregled

Kubernetes uporablja sonde živahnosti in pripravljenosti, da preveri, ali vaši podi delujejo normalno. Če preverjanje delovanja ne uspe, bo Kubernetes ustavil ta vsebnik in ga nato samodejno znova zagnal, če je pravilnik o ponovnem zagonu ustrezno nastavljen. Če preverjanje pripravljenosti ne uspe, Kubernetes izolira pod od servisnih zahtev. Tako v takih primerih ročno posredovanje sploh ni več potrebno, kar je velik plus.

Uvajanje posodobitev

StatefulSets podpirajo samodejne posodobitve: če izberete strategijo RollingUpdate, bo vsak pod Kafko posodobljen po vrsti. Na ta način se lahko izpadi zmanjšajo na nič.

Skaliranje

Skaliranje Kafkinega grozda ni lahka naloga. Vendar Kubernetes omogoča zelo preprosto prilagajanje podov na določeno število replik, kar pomeni, da lahko deklarativno definirate poljubno število posrednikov Kafka. Najtežja stvar v tem primeru je ponovna dodelitev sektorjev po povečanju ali pred zmanjšanjem. Tudi pri tej nalogi vam bo pomagal Kubernetes.

Uprava

Naloge, povezane z upravljanjem gruče Kafka, kot je ustvarjanje tem in ponovno dodeljevanje sektorjev, je mogoče opraviti z uporabo obstoječih lupinskih skriptov, tako da odprete vmesnik ukazne vrstice v vaših podih. Vendar ta rešitev ni preveč lepa. Strimzi podpira upravljanje tem z uporabo drugega operaterja. Tukaj je nekaj prostora za izboljšave.

Varnostno kopiranje in obnovitev

Zdaj bo razpoložljivost Kafke odvisna tudi od razpoložljivosti Kubernetesa. Če vaša gruča Kubernetes odpove, bo v najslabšem primeru odpovedala tudi vaša gruča Kafka. Po Murphyjevem zakonu se bo to zagotovo zgodilo in izgubili boste podatke. Če želite zmanjšati to vrsto tveganja, imejte dober koncept varnostnega kopiranja. Lahko uporabite MirrorMaker, druga možnost je uporaba S3 za to, kot je opisano v tem post iz Zalanda.

Zaključek

Pri delu z majhnimi do srednje velikimi gručami Kafka je vsekakor smiselna uporaba Kubernetesa, saj zagotavlja dodatno fleksibilnost in poenostavi izkušnjo operaterja. Če imate zelo velike zahteve po nefunkcionalni zakasnitvi in/ali prepustnosti, je morda bolje razmisliti o kakšni drugi možnosti uvedbe.

Vir: www.habr.com