Mirësevini, Habr!
Në kohën e saj, ne ishim të parët që sollëm në tregun rus temën dhe vazhdojmë ta zhvillojmë. Në veçanti, na duket interesante tema e bashkëpunimit mes Kafka dhe . Një përmbledhje (dhe mjaft e kujdesshme) në këtë temë u publikua në blogun e kompanisë Confluent në tetor të vitit të kaluar, nga autorja Gwen Shapiro. Sot, dëshirojmë të tërheqim vëmendjen tuaj në një artikull më të ri, të shkruar në prill nga Johann Gyger, i cili, megjithëse nuk shmangu një pikëpyetje në titull, e shqyrton temën në një mënyrë më të qartë, duke shoqëruar tekstin me lidhje interesante. Ju lutem, na falni për përkthimin e lirisht të "chaos monkey", nëse e mundeni!
Hyrje
Kubernetes është i destinuar për të punuar me ngarkesa që nuk mbajnë gjendje. Në përgjithësi, këto ngarkesa paraqiten në formën e një arkitekture mikroshërbimesh, janë të lehta, mirëmbahen mirë për shkallëzimin horizontal, përputhen me parimet e aplikacioneve 12-faktorëshe, lejojnë të punosh me qarkullues automatikë (circuit breaker) dhe majmunët e chaos (chaos monkeys).
Kafka, nga ana tjetër, në thelb vepron si një bazë të dhënash të shpërndara. Kështu, gjatë punës duhet të merresh me gjendjen, dhe ajo është shumë më e rëndë se një mikroshërbim. Kubernetes mbështet ngarkesa që mbajnë gjendje, por, siç thekson Kelsey Hightower në dy tweet-et e tij, ato duhet trajtuar me kujdes:
Disa mendojnë se, nëse aplikon Kubernetes në një ngarkesë që mban gjendje, ajo shndërrohet në një bazë të dhënash të menaxhuar plotësisht, e cila është në gjendje të konkurrojë me RDS. Kjo nuk është e vërtetë. Ndoshta, nëse punoni mjaftueshëm, urdhëroni komponente shtesë dhe angazhoni një ekip inxhinierësh SRE, do të arrini të vendosni një RDS mbi Kubernetes.
Gjithmonë rekomandoj të tregoni kujdes të jashtëzakonshëm kur lançoni ngarkesa që mbajnë gjendje në Kubernetes. Shumica e atyre që janë të interesuar, "a mund të ekzekutoj ngarkesa që mbajnë gjendje në Kubernetes" nuk kanë përvojë të mjaftueshme në punën me Kubernetes, dhe shpesh as me ngarkesën për të cilën pyesin.
Pra, a duhet të ekzekutohet Kafka në Kubernetes? Një pyetje tjetër: a do të funksionojë më mirë Kafka pa Kubernetes? Kështu që dëshiroj të theksoj në këtë artikull se si Kafka dhe Kubernetes plotësojnë njëri-tjetrin, dhe cilat janë pengesat që mund të hasen kur i kombinojë ato.
Koha e ekzekutimit
Le të flasim për një gjë bazike — mjedisi i ekzekutimit si një i tillë.
Procesi
Brokerat Kafka janë të përshtatshëm për punën me CPU. TLS mund të sjellë disa kosto. Megjithatë, klientët e Kafka mund të ngarkojnë më shumë CPU nëse përdorin enkriptim, por kjo nuk ndikon në brokerat.
Memoria
Brokerat Kafka konsumojnë memorie. Madhësia e grumbullit JVM zakonisht rekomandohet të kufizohet në 4–5 GB, por ju gjithashtu do t'ju nevojitet shumë memorie sistemike, pasi Kafka e përdor shumë aktivisht cache-in e faqeve. Në Kubernetes, caktoni në mënyrë të përshtatshme kufizimet e burimeve të konteinerëve dhe kërkesat.
Ruajtja e të dhënave
Ruajtja e të dhënave në konteinerë është efemere – të dhënat humbin gjatë rinisjes. Për të dhënat e Kafka, mund të përdorni volumin emptyDir, dhe efekti do të jetë i ngjashëm: të dhënat e brokerit tuaj do të humbasin pas përfundimit. Mesazhet tuaja mund të ruajnë ende në brokerë të tjerë si replika. Prandaj, pas rinisjes, brokeri i dëmtuar duhet të riprodhojë të gjitha të dhënat e para, dhe ky proces mund të marrë një kohë të konsiderueshme.
Kjo është arsyeja pse duhet përdorur ruajtja e të dhënave afatgjatë. Le të jetë kjo një ruajtje e jashtme afatgjatë me sistemin e skedarëve XFS ose, më saktësisht, ext4. Mos përdorni NFS. Të kam paralajmëruar. NFS versionet v3 ose v4 nuk do të funksionojnë. Në përmbledhje, brokeri Kafka do të përfundojë, nëse nuk arrin të fshijë katalogun e të dhënave për shkak të një problemi me "emërtimet e budallaqëve", që është aktual në NFS. Nëse deri tani nuk jam bindur, lexoni me kujdes . Ruajtja e të dhënave duhet të jetë e jashtme, në mënyrë që Kubernetes të mund të zgjedhë më fleksibël një nyje të re pas rinisjes ose relokimit.
RRjeti
Si dhe në shumicën e sistemeve të shpërndara, performanca e Kafka varet shumë nga minimizimi i vonesave në rrjet dhe maksimizimi i gjerësisë së brezit. Mos provoni të vendosni të gjithë brokerët në të njëjtën nyje, pasi ky do të ulë disponueshmërinë. Nëse ndalon një nyje Kubernetes, do të ndalojë gjithashtu tërë grumbullin Kafka. Gjithashtu, mos shpërndani grumbullin Kafka për qendra të plota të të dhënave. E njëjta gjë vlen për grumbullin Kubernetes. Një kompromis i mirë në këtë rast është të zgjidhni zona të ndryshme të disponueshmërisë.
Konfigurimi
Manifestet e zakonshme
Në faqen e Kubernetes ka rreth mënyrës se si tëKonfiguroni ZooKeeper me ndihmën e manifestëve. Duke qenë se ZooKeeper është pjesë e Kafka, kjo është një pikë e mirë për të filluar të njohësh konceptet e Kubernetes që janë të aplikueshme këtu. Pas kësaj, do të jeni në gjendje të aplikoni të njëjtat koncepte edhe për klasterin Kafka.
- Nën: pod – është njësia minimale e dislokueshme në Kubernetes. Në pod ndodhet ngarkesa juaj e punës, dhe vetë pod-i përkon me procesin tuaj në klaster. Në pod ndodhen një ose më shumë kontejnerë. Çdo server ZooKeeper në ansambël dhe çdo broker në klasterin Kafka do të operojnë në një pod të veçantë.
- StatefulSet: StatefulSet – është një objekt Kubernetes që punon me ngarkesa të shumta që ruajnë gjendjen, dhe këto ngarkesa kërkojnë koordinim. StatefulSet ofron garanci në lidhje me renditjen e podëve dhe unikalitetin e tyre.
- Shërbimet pa kokë: Shërbimet lejojnë ndarjen e podëve nga klientët përmes një emri logjik. Kubernetes në këtë rast merr përsipër balancimin e ngarkesës. Megjithatë, kur punoni me ngarkesa që ruajnë gjendjen, siç është rasti me ZooKeeper dhe Kafka, klientët duhet të komunikojnë me një instancë specifike. Këtu ju duhen shërbimet pa kokë: në atë rast, klienti do të ketë ende një emër logjik, por nuk do të nevojitet të drejtohet drejtpërdrejt te pod-i.
- Voli për ruajtje afatgjatë: këto voli janë të nevojshme për konfigurimin e ruajtjes afatgjatë jo-lokale të bllokut, e cila përmendet më parë.
Në ofron një set të plotë manifestesh, me të cilat është e lehtë të filloni punën me Kafka në Kubernetes.
Diagramet Helm
Helm – është një menaxher paketash për Kubernetes, i cili mund të krahasohet me menaxherët e paketave për OS, si yum, apt, Homebrew ose Chocolatey. Me ndihmën e tij, është e lehtë të instaloni paketa të definuara paraprakisht, të përshkruara në diagramet Helm. Një diagram Helm i mirë i përgatitur e lehtëson detyrën e vështirë: si të konfiguroni të gjitha parametrat për të përdorur Kafka në Kubernetes. Ka disa diagrame Kafka: ajo zyrtare është , ka një nga , dhe një tjetër – nga .
Operatorët
Duke pasur parasysh se Helm ka disa dobësi, një tjetër mjet i njohur po fiton popullaritet: operatorët e Kubernetes. Një operatore nuk thjesht paketizon softuerin për Kubernetes, por gjithashtu ju lejon ta dislokoni dhe menaxhoni atë.
Në listën përmenden dy operatorë për Kafka. Njëri prej tyre është Me Strimzi, ngritja e një klasteri Kafka është tepër e lehtë. Përveç kësaj, operatori ofron disa mundësi të dobishme, siç është enkriptimi TLS nga "pikë në pikë" brenda klasterit. Confluent gjithashtu ofron .
Performanca
Është shumë e rëndësishme të testoni performancën, duke ofruar pikë kontrolli për instancën tuaj të instaluar të Kafka. Këto teste do t'ju ndihmojnë të identifikoni ngushticat e mundshme, para se të fillojnë problemet. Fatmirësisht, Kafka ofron dy mjete për testimin e performancës: kafka-producer-perf-test.sh dhe kafka-consumer-perf-test.sh. Përdorni ato aktivisht. Për referencë, mund të kontrolloni rezultatet e përshkruara nga Jay Kreps, ose të bazoheni në Amazon MSK nga Stéphane Maarek.
Operacione
Monitorimi
Transparenca në sistem është shumë e rëndësishme – në të kundërt, nuk do të kuptoni se çfarë ndodh. Sot ka një gamë të gjerë mjetesh që ofrojnë monitorim të bazuar në metrika në stilin cloud native. Dy mjete të njohura për këtë qëllim janë – Prometheus dhe Grafana. Prometheus mund të mbledhë metrika nga të gjithë proceset Java (Kafka, Zookeeper, Kafka Connect) përmes eksportuesit JMX – në mënyrën më të thjeshtë. Nëse përfshini metrika cAdvisor, do të keni një pamje më të plotë të mënyrës se si burimet përdoren në Kubernetes.
Strimzi ka një shembull shumë të njohur të grafikut Grafana për Kafka. Ai vizualizon metrikat kryesore, siç janë sektori të pa riprodhuara ose ato që janë offline. Të gjitha janë shumë të qarta. Këto metrika kompletohen me informacion mbi përdorimin e burimeve dhe performancën, si dhe treguesit e stabilitetit. Kështu, ju merrni monitorimin themelor të klasterit Kafka falas!
Burimi:
E gjitha kjo do të ishte e dobishme të shoqërohej me monitorimin e klienteve (metrikat për konsumatorët dhe prodhuesit), si dhe monitorimin e vonesave (për këtë ka ) dhe monitorimin e plotë – për këtë shërbim përdorni .
Logimi
Regjistrimi është një detyrë tjetër shumë e rëndësishme. Sigurohuni që të gjitha kontejnerët në instalimin tuaj të Kafka janë regjistruar në stdout dhe stderr, dhe sigurohuni që klasteri juaj Kubernetes të grumbullojë të gjitha log-et në një infrastrukturë qendrore të regjistrit, për shembull, në .
Kontrolli i funksionalitetit
Kubernetes përdor sondat e ‘gjallërisë’ (liveness) dhe gatishmërisë (readiness) për të verifikuar nëse pod-et e tuaja funksionojnë siç duhet. Nëse testi i gjallërisë dështoi, Kubernetes do ta ndalë këtë konteiner dhe më pas do ta riparojë automatikisht, nëse politika e rimarrjes është vendosur siç duhet. Nëse testi i gatishmërisë dështoi, Kubernetes e izolun këtë pod nga shërbimet për kërkesa. Kështu, në këto raste nuk nevojitet ndërhyrje manuale, që është një avantazh i madh.
Kohëzgjatja e përditësimeve
StatefulSet mbështet përditësime automatike: me zgjedhjen e strategjisë RollingUpdate, çdo pod Kafka do të përditësohet një nga një. Kështu, koha e pezullimit mund të zvoglohet në zero.
Масштабирование
Zgjerimi i klasterit Kafka është një detyrë sfiduese. Megjithatë, në Kubernetes është shumë e lehtë të zgjeroni pod-et në një numër të caktuar replikash, që do të thotë se mund të përcaktoni deklarativisht aq shumë brokerë Kafka sa dëshironi. Problemi më i madh në këtë rast është riparimi i sektorëve pas zgjerimit ose përpara zvogëlimit. Edhe një herë, Kubernetes do t'ju ndihmojë në këtë detyrë.
Administrimi
Detyrat e administratës së klasterit tuaj Kafka, veçanërisht krijimi i temave dhe ribashkimi i sektorëve, mund të kryhen duke përdorur skripte shell ekzistuese, duke hapur ndërfaqen e komandës në pod-et tuaja. Megjithatë, kjo zgjidhje nuk është shumë estetike. Strimzi mbështet menaxhimin e temave përmes një operatori tjetër. Këtu ka për tu përmirësuar.
Backup dhe rikuperim
Tani disponueshmëria e Kafka do të varet gjithashtu nga disponueshmëria e Kubernetes. Nëse klasteri juaj Kubernetes dështon, në rastin më të keq, klasteri Kafka gjithashtu do të dështojë. Sipas ligjit të Murphy-t, kjo padyshim do të ndodhë dhe do të humbni të dhënat. Për të ulur rrezikun e tillë, planifikoni me kujdes konceptin e backup-it. Mund të përdorni MirrorMaker, një opsion tjetër është të angazhoni S3 për këtë, siç është përshkruar në këtë nga Zalando.
Përfundimi
Kur punoni me klasterë të vegjël ose mesatarë Kafka, me siguri ka kuptim të përdorni Kubernetes, pasi ai ofron fleksibilitet shtesë dhe e lehtëson punën me operatorët. Nëse keni kërkesat shumë të rënda jo-funzionale, të lidhura me vonesën dhe/ose kapacitetin, ndoshta është më mirë të shqyrtoni një opsion tjetër për shpërndarjen.
Burimi: habr.com
