Kafka Kuberneteses - kas see on hea?

Tere tulemast, Habr!

Oma ajal olime esimesed, kes tõid Venemaa turule teema Kafka ja jätkame jälgib selle arendamist. Eelkõige leidis meile huvi teema Kafka ja Kubernetes. Ülevaade (ja üsna ettevaatlik) artikkel selle teema kohta ilmus Confluenti ettevõtte blogis juba eelmise aasta oktoobris Gwen Shapiro autorlusega. Tänapäeval tahame aga juhtida teie tähelepanu värskemale, aprillis ilmunud artiklile Johann Gygerilt, kes, kuigi ei suutnud vältida küsimärki pealkirjas, käsitleb teemat konkreetsemalt, lisades tekstile huvitavaid linke. Palun andestage meile vabakäeline tõlge "chaos monkey", kui saate!

Sissejuhatus

Kubernetes on mõeldud töötama olekuta koormuste, st. tavaliselt mikroteenuste arhitektuuri vormis, mis on kerged, hästi skaleeritavad ja järgivad 12-faktori rakenduse põhimõtteid, võimaldades töötada automaatsete katkestajate (circuit breaker) ja kaose ahvidega (chaos monkeys).

Kafka, mis asub teisel pool, toimib sisuliselt jaotatud andmebaasina. Seega peate töötama olekuga, mis on palju raskem kui mikroteenus. Kubernetes toetab olekuga koormusi, kuid nagu osutab Kelsey Hightower oma kahe säutsu kaudu, tuleb nendega olla ettevaatlik:

Mõned arvavad, et kui paigaldada Kubernetes olekuga koormusele, muutub see täielikult hallatavaks andmebaasiks, mis suudab konkureerida RDS-iga. Nii see ei ole. Võib-olla, kui piisavalt vaeva näha, lisada täiendavad komponendid ja kaasata SRE-insenere, on võimalik rajada RDS Kubernetes'i peale.

Soovitan alati äärmiselt ettevaatlikult läheneda olekuga koormuste käivitamisele Kuberneteses. Enamik inimesi, kes küsivad, "kas ma saan Kuberneteses käitada olekuga koormusi", ei oma piisavat kogemust Kubernetesega töötamisel ja tihti – isegi selle koormuse osas, mille kohta küsitakse.

Nii et, kas peaksime käivitama Kafka Kubernetesel? Vastuküsimus: kas Kafka töötab paremini ilma Kuberneteseta? Just seetõttu tahan selles artiklis rõhutada, kuidas Kafka ja Kubernetes üksteist täiustavad ning millised takistused võivad tekkida nende kombinatsiooni korral.

Suunamine

Räägime alustest — jooksukeskkonnast kui sellisest.

Protsess

Kafka maaklerid sobivad hästi CPU kasutamiseks. TLS võib tuua kaasa teatud kulud. Sellegipoolest võivad Kafka kliendid koormata CPU-d rohkem, kui nad kasutavad krüpteerimist, kuid see ei mõjuta maaklereid.

Mälu

Kafka maaklerid kasutavad mälu. JVM-i kuhja suurust on tavaliselt soovitatav piirata 4–5 GB-ni, kuid teil on vaja ka palju süsteemimälu, kuna Kafka kasutab lehe vahemälu väga aktiivselt. Kuberneteses seadistage konteineri ressursside piirangud ja nõudmised vastavalt.

Andmete salvestamine

Konteineritesse salvestatud andmed on ajutised – andmed kaovad taaskäivitamisel. Kafka andmete jaoks võib kasutada volüümi, emptyDir, ja efekt on sama: teie maakleri andmed kaovad pärast sulgemist. Teie sõnumid võivad siiski jääda teistes maaklerites replikatena. Seetõttu peab pärast taaskäivitamist esmajoones replikatsiooniprotsessi käivitama ebaõnnestunud maakler, mis võib võtta päris kaua aega.

Seetõttu on soovitatav kasutada pikaajalist andmesalvestust. Olgu see mittelikealne pikaajaline salvestus XFS failisüsteemiga või täpsemalt ext4. Ärge kasutage NFS-i. Ma hoiatatud. NFS versioonid v3 või v4 ei tööta. Lühidalt kokku võttes, Kafka maakler lõpetab töö, kui ta ei saa andmekausta kustutada tänu probleemile "rumalate ümbernimetamisega", mis on NFS-is aktuaalne. Kui ma teid siiani ei veennud, vaadake väga tähelepanelikult lugeda seda artiklit. Andmesalvestus peab olema mittelikealne, et Kubernetes saaks taaskäivitamisel või uue sõlme valimisel olema paindlikum.

Võrk

Nagu enamikus hajutatud süsteemides, sõltub Kafka jõudlus tugevalt sellest, et võrgu hilinemine oleks minimaalne ja ribalaius maksimaalne. Ära püüa paigutada kõiki brokereid samale sõlmele, sest see vähendab kättesaadavust. Kui Kubernetes'i sõlm ebaõnnestub, ebaõnnestub ka kogu Kafka klaster. Samuti ära jaota Kafka klastrit laialdaselt erinevate andmekeskuste vahel. Sama kehtib Kubernetes'i klustreid. Heaks kompromissiks on valida erinevad kättesaadavuse tsoonid.

Konfiguratsioon

Tavalised manifestid

Kubernetes'i veebisaidil on väga hea juhend kuidas seadistada ZooKeeperit manifestide abil. Kuna ZooKeeper on osa Kafka'st, on sellest mugav alustada tutvumist nendega, millised Kubernetes'i kontseptsioonid siinkohal kohaldavad. Pärast nende mõistmist saad kasutada samu kontseptsioone ka Kafka klastris.

• Pod: pod – see on minimaalselt kasutusele võetav ühik Kubernetes'is. Pod sisaldab sinu töökoormust ja vastab protsessile sinu klastris. Pod'is on üks või rohkem konteinerit. Iga ZooKeeper'i server ansamblis ja iga broker Kafka klastris töötab eraldi pod'is.
• StatefulSet: StatefulSet – see on Kubernetes'i objekt, mis tegeleb mitme olekut säilitava töökoormusega, mis nõuab koordineerimist. StatefulSetid tagavad pod'ide järjekorra ja nende ainulaadsuse.
• Peata teenuseid: Teenused võimaldavad eraldada pod'id klientidest loogilise nime abil. Kubernetes vastutab sel juhul koormuse tasakaalustamise eest. Kuid oleku säilitavate töökoormuste, nagu ZooKeeper ja Kafka puhul, peavad kliendid suhtlema konkreetse instantsiga. Siin tulevad mängu peata teenused: antud juhul jääb kliendile loogiline nimi, kuid pod'ile saab otse ei pöörduda.
• Pikemaajalise salvestamise mahutid: sellised mahutid on vajalikud mitte-lokaalse blokis pikaajalise salvestuse konfigureerimiseks, mida mainiti varem.

Pealehe Yolean pakub põhjalikku komplekti manifeste, millega on mugav alustada töötamist Kafka'ga Kubernetes'is.

Helm-diagrammid

Helm on Kubernetesi paketihaldur, mida saab võrrelda operatsioonisüsteemide pakettide halduritega nagu yum, apt, Homebrew või Chocolatey. Selle abil on mugav installida eelnevalt määratud tarkvarapakette, mida on kirjeldatud Helm’i diagrammides. Hästi koostatud Helm’i diagramm lihtsustab keerulist ülesannet: kuidas õigesti konfigureerida kõiki parameetreid Kafka kasutamiseks Kuberneteses. On mitmeid Kafka diagramme: ametlik on inkubeerimisseisundis,üks on Confluent, veel üks – Bitnami..

Operaatorid

Kuna Helm’il on teatud puudused, on üha populaarsemaks saanud veel üks tööriist: Kubernetesi operaatorid. Operaator mitte ainult ei pakenda tarkvara Kuberneteseks, vaid võimaldab ka selle tarkvara juurutamist ning haldamist.

Loetelus imelistest operaatoritest mainitakse kahte operaatorit Kafka jaoks. Üks neist on Strimzi.Strimzi abil ei ole Kafka klastri püstitamine mingi probleem ja see võtab vaid paar minutit. Peaaegu mingit konfiguratsiooni ei pea tegema, lisaks pakub operaator mitmeid meeldivaid võimalusi, näiteks „punkt-punkt“ TLS-krüptimist klastris. Confluent pakub samuti oma operaatorit..

Tõhusus

On väga oluline testida jõudlust, varustades paigaldatud Kafka eksemplari kontrollpunktidega. Sellised testid aitavad tuvastada potentsiaalsed kitsaskohad, enne kui probleemid algavad. Õnneks pakub Kafka juba kahte jõudluse testimise tööriista: kafka-producer-perf-test.sh ja kafka-consumer-perf-test.sh.Kasutage neid aktiivselt. Viite saamiseks võite kontrollida tulemusi, mida on kirjeldanud selles postituses Jay Kreps, või orienteeruda sellele ülevaatele Amazon MSK poolt Stéphane Maarek.

Operatsioonid

Jälgimine

Süsteemis on läbipaistvus väga oluline – vastasel juhul ei saa te aru, mis seal toimub. Tänapäeval on olemas tugev tööriistakomplekt, mis tagab pilvepõhiste meetmete jälgimise. Kaks populaarset tööriista selle eesmärgi saavutamiseks on Prometheus ja Grafana. Prometheus saab koguda meetmeid kõigilt Java protsessidelt (Kafka, Zookeeper, Kafka Connect) JMX eksportija abil – kõige lihtsamal viisil. Kui lisada cAdvisor'i meetmed, on võimalik paremini mõista, kuidas Kuberneteses ressursse kasutatakse.

Strimzi'l on väga mugav Grafana armatuurlaud Kafka jaoks. See visualiseerib võtme mõõdikud, näiteks mitte-replitseeritud sektoreid või neid, mis on võrguühenduseta. Kõik on väga arusaadav. Need mõõdikud täiustatakse ressursside kasutamise ja jõudluse ning stabiilsuse näitajatega. Niisiis, saate baasil Kafkade klastrite jälgimise tasuta!

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

Kohandatud jälgimisse oleks hea lisada klientide monitorimine (mõõdikud tarbijate ja tootjate kohta) ning viibimise jälgimine (sel eesmärgil on olemas Burrow) ja lõppkasutaja jälgimine - selleks kasutage Kafka Monitor.

Logimine

Logimine on veel üks väga oluline ülesanne. Veenduge, et kõik teie Kafka seadistuse konteinerid logitakse stdout ja stderr, ja tehke kindlaks, et teie Kubernetes klaster kogub kõik logid keskse logimise infrastruktuuri, näiteks Elasticsearch.

Töötamise kontrollimine

Kubernetes kasutab „elujõu“ (liveness) ja valmisoleku (readiness) alasid, et kontrollida, kas teie podid töötavad korralikult. Kui elujõu kontroll ebaõnnestub, peatab Kubernetes selle konteineri ja seejärel taaskäivitab selle automaatselt, kui taaskäivitamise poliitika on vastavalt seadistatud. Kui valmisoleku kontroll ebaõnnestub, isoleerib Kubernetes selle podi teenuste taotlustest. Seega, sellistes olukordades ei ole enam vaja käsitsi sekkuda, mis on suur pluss.

Uuenduste juurutamine

StatefulSet'id toetavad automaatseid uuendusi: RollingUpdate strateegia valimisel uuendatakse iga Kafka podi järkjärgult. Seega on võimalik vähendada seisakute kestust nullini.

Mastaabis

Kafka klastrite suurendamine on keeruline ülesanne. Siiski on Kubernetesis väga lihtne podide skaleerimine kindlatele koopiaarvudele, mis tähendab, et saate deklaratiivselt määrata nii palju Kafka brokereid kui soovite. Kõige keerulisem asi on sektorite ümberjaotamine pärast suurendamist või enne vähendamist. Jällegi saab Kubernetes teid selle ülesanne täitmisel aidata.

Haldamine

Kafka klastrite haldamise ülesandeid, sealhulgas teema loomist ja jaotuste ümbersuunamist, saab teostada olemasolevate shell-skriptide abil, avades käsurea liidese teie podides. Kuid see lahendus ei ole just kõige ilusam. Strimzi toetab teemasid haldavat teist operaatorit. Siinkohal on kindlasti veel, millega töötada.

Kopeerimine ja taastamine

Nüüd sõltub meie Kafka kättesaadavus ka Kubernetesest. Kui teie Kubernetes klaster kukub, siis halvimal juhul kukub ka Kafka klaster. Murphy seaduse kohaselt juhtub see kindlasti ja te kaotate andmed. Selle riski vähendamiseks töötage välja tugev varundamisstrateegia. Võite kasutada MirrorMakerit, teine võimalus on kasutada S3, nagu on selgitatud siin. postitusest Zalando poolt.

Kokkuvõte

Kui töötate väikeste või keskmise suurusega Kafka klastritega, on Kubernetes kindlasti mõistlik, sest see pakub täiendavat paindlikkust ja lihtsustab operaatoritega töötamist. Kui teil on tõsised mittefunktsionaalsed nõuded, mis puudutavad latentsust ja/või läbilaskevõimet, võib-olla tasub kaaluda mõnda teist juurutusvarianti.

Allikas: habr.com