Kveðja, Habr!
Á sínum tíma vorum við fyrstir til að kynna efnið á rússneska markaðnum og halda áfram fyrir þróun þess. Sérstaklega fundum við umræðuefnið um samskipti Kafka og . Áberandi (og alveg varkár) þetta efni var birt á Confluent blogginu í október á síðasta ári undir höfundarrétti Gwen Shapira. Í dag viljum við vekja athygli á nýrri grein frá því í apríl eftir Johann Gyger, sem, þó ekki sé án spurningamerkis í titlinum, skoðar efnið á efnislegri hátt og fylgir textanum áhugaverðum hlekkjum. Vinsamlegast fyrirgefðu okkur ókeypis þýðinguna á „kaos api“ ef þú getur!
Inngangur
Kubernetes er hannað til að takast á við ríkisfangslaust vinnuálag. Venjulega er slíkt vinnuálag sett fram í formi örþjónustuarkitektúrs, það er létt, mælist vel lárétt, fylgir meginreglum 12-þátta forrita og getur unnið með aflrofum og óreiðuöpum.
Kafka, aftur á móti, virkar í meginatriðum sem dreifður gagnagrunnur. Þannig að þegar þú vinnur þarftu að takast á við ríkið og það er miklu þyngra en örþjónusta. Kubernetes styður ástandslegt álag, en eins og Kelsey Hightower bendir á í tveimur tístum, ætti að meðhöndla þau með varúð:
Sumum finnst að ef þú rúllar Kubernetes inn í staðbundið vinnuálag verði það fullstýrður gagnagrunnur sem keppir við RDS. Þetta er rangt. Kannski, ef þú vinnur nógu mikið, bætir við viðbótarhlutum og laðar að þér hóp SRE verkfræðinga, muntu geta byggt RDS ofan á Kubernetes.
Ég mæli alltaf með því að allir sýni ýtrustu varkárni þegar þeir keyra staðbundið vinnuálag á Kubernetes. Flestir sem spyrja „get ég keyrt staðbundið vinnuálag á Kubernetes“ hafa ekki næga reynslu af Kubernetes, og oft með vinnuálagið sem þeir eru að spyrja um.
Svo, ættir þú að keyra Kafka á Kubernetes? Gagnspurning: mun Kafka virka betur án Kubernetes? Þess vegna vil ég draga fram í þessari grein hvernig Kafka og Kubernetes bæta hvort annað upp og hvaða gildrur geta fylgt því að sameina þau.
Tími verkloka
Við skulum tala um grunnatriðið - keyrsluumhverfið sjálft
ferlið
Kafka miðlari eru CPU vingjarnlegur. TLS kann að kynna nokkur kostnaður. Hins vegar geta Kafka viðskiptavinir verið örgjörvafrekari ef þeir nota dulkóðun, en það hefur ekki áhrif á miðlara.
minni
Kafka-miðlarar éta upp minnið. JVM hrúgustærðin er venjulega takmörkuð við 4-5 GB, en þú þarft líka mikið kerfisminni þar sem Kafka notar skyndiminni síðunnar mjög mikið. Í Kubernetes skaltu stilla gámaforða og biðja um takmörk í samræmi við það.
Gagnageymsla
Gagnageymsla í gámum er skammvinn - gögn glatast þegar þau eru endurræst. Fyrir Kafka gögn er hægt að nota bindi emptyDir, og áhrifin verða svipuð: miðlaragögnin þín munu glatast eftir að þeim er lokið. Skilaboðin þín geta samt verið geymd á öðrum miðlarum sem eftirlíkingar. Þess vegna, eftir endurræsingu, verður misheppnaður miðlari fyrst að endurtaka öll gögn og þetta ferli getur tekið mikinn tíma.
Þess vegna ættir þú að nota langtíma gagnageymslu. Láttu það vera óstaðbundin langtímageymslu með XFS skráarkerfinu eða, nánar tiltekið, ext4. Ekki nota NFS. Ég varaði þig við. NFS útgáfur v3 eða v4 virka ekki. Í stuttu máli mun Kafka miðlarinn hrynja ef hann getur ekki eytt gagnaskránni vegna „heimskulegra endurnefna“ vandamálsins í NFS. Ef ég hef ekki enn sannfært þig, mjög varlega . Gagnageymslan ætti að vera ekki staðbundin svo Kubernetes geti valið nýjan hnút á sveigjanlegri hátt eftir endurræsingu eða flutning.
Сеть
Eins og með flest dreifð kerfi er frammistaða Kafka mjög háð því að halda netleynd í lágmarki og bandbreidd í hámarki. Ekki reyna að hýsa alla miðlara á sama hnút, þar sem það mun draga úr framboði. Ef Kubernetes hnút mistekst mun allur Kafka þyrpingin bila. Einnig, ekki dreifa Kafka þyrpingunni yfir heilu gagnaverin. Sama gildir um Kubernetes klasann. Góð málamiðlun í þessu tilfelli er að velja mismunandi framboðssvæði.
Stillingar
Regluleg stefnuskrá
Vefsíðan Kubernetes hefur um hvernig á að stilla ZooKeeper með því að nota upplýsingaskrá. Þar sem ZooKeeper er hluti af Kafka er þetta góður staður til að byrja til að kynnast hvaða hugtök Kubernetes eiga við hér. Þegar þú hefur skilið þetta geturðu notað sömu hugtökin með Kafka-þyrpingum.
- undir: Pod er minnsta einingin sem hægt er að nota í Kubernetes. Belg inniheldur vinnuálag þitt og belgurinn sjálfur samsvarar ferli í klasanum þínum. Belg inniheldur eitt eða fleiri ílát. Hver ZooKeeper netþjónn í hópnum og hver miðlari í Kafka þyrpingunni munu keyra í sérstökum belg.
- StatefulSet: StatefulSet er Kubernetes hlutur sem meðhöndlar mörg ástandsálag og slíkt vinnuálag krefst samræmingar. StatefulSets veita tryggingar varðandi röðun á belgjum og sérstöðu þeirra.
- Höfuðlaus þjónusta: Þjónusta gerir þér kleift að aftengja belg frá viðskiptavinum með því að nota rökrétt nafn. Kubernetes í þessu tilfelli ber ábyrgð á álagsjafnvægi. Hins vegar, þegar þeir nota ástandsbundið vinnuálag, eins og ZooKeeper og Kafka, þurfa viðskiptavinir að eiga samskipti við ákveðið tilvik. Þetta er þar sem höfuðlaus þjónusta kemur sér vel: í þessu tilfelli mun viðskiptavinurinn enn hafa rökrétt nafn, en þú þarft ekki að hafa samband beint við hólfið.
- Langtíma geymslumagn: Þessar bindi eru nauðsynlegar til að stilla viðvarandi geymslu sem er ekki staðbundin og nefnd hér að ofan.
Á Býður upp á yfirgripsmikið sett af upplýsingaskrám til að hjálpa þér að byrja með Kafka á Kubernetes.
Hjálmartöflur
Helm er pakkastjóri fyrir Kubernetes sem hægt er að líkja við OS pakkastjóra eins og yum, apt, Homebrew eða Chocolatey. Það gerir það auðvelt að setja upp fyrirfram skilgreinda hugbúnaðarpakka sem lýst er í Helm töflum. Vel valið stýrikort gerir það erfiða verkefni að stilla allar færibreytur rétt til að nota Kafka á Kubernetes auðvelt. Það eru nokkrar Kafka skýringarmyndir: hin opinbera er staðsett , það er einn frá , einn í viðbót - frá .
Stjórnandi
Vegna þess að Helm hefur ákveðna annmarka nýtur annað tól töluverðum vinsældum: Kubernetes rekstraraðilar. Rekstraraðili pakkar ekki aðeins hugbúnaði fyrir Kubernetes heldur gerir þér einnig kleift að nota slíkan hugbúnað og stjórna honum.
Í listanum Tveir rekstraraðilar fyrir Kafka eru nefndir. Einn af þeim - . Með Strimzi er auðvelt að koma Kafka þyrpingunni þinni í gang á nokkrum mínútum. Nánast engar stillingar eru nauðsynlegar, auk þess veitir rekstraraðilinn sjálfur nokkra góða eiginleika, til dæmis, punkt-til-punkt TLS dulkóðun innan þyrpingarinnar. Confluent veitir einnig .
Framleiðni
Það er mikilvægt að prófa frammistöðu með því að mæla Kafka dæmið þitt. Slík próf munu hjálpa þér að finna hugsanlega flöskuhálsa áður en vandamál koma upp. Sem betur fer býður Kafka nú þegar tvö frammistöðuprófunartæki: kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. Notaðu þau á virkan hátt. Til viðmiðunar geturðu vísað í niðurstöðurnar sem lýst er í Jay Kreps, eða einblína á Amazon MSK eftir Stéphane Maarek.
Aðgerðir
Eftirlit
Gagnsæi í kerfinu er mjög mikilvægt - annars skilurðu ekki hvað er að gerast í því. Í dag er til traustur verkfærakista sem veitir mælikvarða sem byggir á eftirliti í skýjaættum stíl. Tvö vinsæl verkfæri í þessu skyni eru Prometheus og Grafana. Prometheus getur safnað mælingum úr öllum Java ferlum (Kafka, Zookeeper, Kafka Connect) með því að nota JMX útflytjanda - á einfaldasta hátt. Ef þú bætir við cAdvisor mæligildum geturðu skilið betur hvernig auðlindir eru notaðar í Kubernetes.
Strimzi er með mjög þægilegt dæmi um Grafana mælaborð fyrir Kafka. Það sýnir lykilmælikvarða, til dæmis um vanafritaðar geira eða þá sem eru ótengdir. Þar er allt mjög skýrt. Þessar mælikvarðar eru bættar við auðlindanýtingu og frammistöðuupplýsingar, svo og stöðugleikavísa. Svo þú færð grunn Kafka klasa eftirlit fyrir ekki neitt!
Heimild:
Það væri gaman að bæta við þetta allt með eftirliti viðskiptavina (mælingar á neytendum og framleiðendum), sem og töfvöktun (til þess er ) og eftirlit frá enda til enda - fyrir þessa notkun .
Skógarhögg
Skógarhögg er annað mikilvægt verkefni. Gakktu úr skugga um að allir ílát í Kafka uppsetningunni þinni séu skráðir inn stdout и stderr, og tryggðu líka að Kubernetes þyrpingin þín safnar öllum annálum í miðlægan skráningarinnviði, t.d. .
Heilbrigðiseftirlit
Kubernetes notar lífleika- og viðbúnaðarkannanir til að athuga hvort belgirnir þínir gangi eðlilega. Ef virkniathugunin mistekst mun Kubernetes stöðva þann gám og endurræsa hann síðan sjálfkrafa ef endurræsingarstefnan er stillt í samræmi við það. Ef viðbúnaðarathugunin mistekst, einangrar Kubernetes hólfið frá þjónustubeiðnum. Í slíkum tilfellum er því alls ekki lengur þörf á handvirkri íhlutun, sem er stór plús.
Rúlla út uppfærslur
StatefulSets styðja sjálfvirkar uppfærslur: ef þú velur RollingUpdate stefnuna verður hver undir Kafka uppfærð í röð. Þannig er hægt að minnka niður í miðbæ niður í núll.
Skala
Það er ekki auðvelt verkefni að stækka Kafka-þyrpinguna. Hins vegar, Kubernetes gerir það mjög auðvelt að skala fræbelg í ákveðinn fjölda eftirmynda, sem þýðir að þú getur skilgreint með yfirlýsandi hætti eins marga Kafka miðlara og þú vilt. Það erfiðasta í þessu tilfelli er að endurúthluta geirum eftir að hafa stækkað eða áður en stækkað er. Aftur, Kubernetes mun hjálpa þér með þetta verkefni.
Stjórnsýsla
Verkefni sem tengjast stjórnun Kafka þyrpingarinnar, eins og að búa til efni og endurúthluta geirum, er hægt að gera með því að nota núverandi skeljaforskriftir með því að opna skipanalínuviðmótið í belgunum þínum. Hins vegar er þessi lausn ekki mjög falleg. Strimzi styður stjórnun efnis með því að nota annan símafyrirtæki. Hér er nokkurt svigrúm til úrbóta.
Afritaðu og endurheimtu
Nú mun framboð Kafka einnig ráðast af framboði á Kubernetes. Ef Kubernetes þyrpingin þín mistekst, þá mun Kafka þyrpingin þín líka bila í versta falli. Samkvæmt lögum Murphys mun þetta örugglega gerast og þú munt tapa gögnum. Til að draga úr þessari tegund áhættu skaltu hafa gott öryggisafrit. Þú getur notað MirrorMaker, annar valkostur er að nota S3 fyrir þetta, eins og lýst er í þessu frá Zalando.
Ályktun
Þegar unnið er með litla til meðalstóra Kafka-þyrpinga er það örugglega þess virði að nota Kubernetes þar sem það veitir aukinn sveigjanleika og einfaldar upplifun rekstraraðila. Ef þú ert með mjög verulegar óvirkar leynd og/eða afköst kröfur, þá gæti verið betra að íhuga einhvern annan dreifingarvalkost.
Heimild: www.habr.com