A është Kafka mbi Kubernetes e mirë?

Mirësevini, Habr!

Në kohën e saj, ne ishim të parët që sollëm në tregun rus temën Kafka dhe vazhdojmë ndjekin me zhvillimin e saj. Në veçanti, na dukej interesante tema e ndërveprimit mes Kafka dhe Kubernetes. Një pasqyrë (dhe mjaft e kujdesshme) artikulli për këtë temë u publikua në blogun e kompanisë Confluent që në tetor të vitit të kaluar nga autorja Gwen Shapiro. Sot, ne duam të tërheqim vëmendjen tuaj në një artikull më të ri, të muajit prill, nga Johann Gyger, i cili, edhe pse nuk e evitoi pikëpyetjen në titull, e shqyrton temën me një qasje më të fokusuara, duke shoqëruar tekstin me lidhje interesante. Na falni për përkthimin e lirë të "chaos monkey", nëse mundeni!

Hyrje

Kubernetes është i dizajnuar për të punuar me ngarkesa që nuk ruajnë gjendjen. Në përgjithësi, këto ngarkesa paraqiten në formën e arkitekturës mikros services, janë të lehta, mirë përshtaten për shkallëzim horizontal, i përmbahen parimeve të aplikacioneve 12-faktorësh, lejojnë funksionimin me fikës automatikë (circuit breaker) dhe majmunë kaosi (chaos monkeys).

Kafka, e vendosur nga ana tjetër, në thelb funksionon si një bazë të dhënash të shpërndarë. Kështu, gjatë punës keni të bëni me gjendjen, dhe kjo është shumë më e rëndë se një mikrosërvër. Kubernetes mbështet ngarkesa që ruajnë gjendjen, por, siç e thekson Kelsey Hightower në dy nga tweet-et e tij, duhet të jeni të kujdesshëm me to:

Disa mendojnë se, nëse instalohet Kubernetes mbi një ngarkesë që ruan gjendjen, ajo shndërrohet në një bazë të dhënash të plotë menaxhuar, e cila mund të konkurrojë me RDS. Kjo nuk është e vërtetë. Ndoshta, nëse punoni mjaft, lidhni komponentë të tjerë dhe angazhoni një ekip inxhinierësh SRE, do të jeni në gjendje të krijoni një RDS mbi Kubernetes.

Gjithmonë rekomandoj kujdes të jashtëzakonshëm kur ekzekutoni ngarkesa që ruajnë gjendjen mbi Kubernetes. Shumica e atyre që janë të interesuar, "mund të ekzekutoj ngarkesa që ruajnë gjendjen mbi Kubernetes" nuk kanë përvojë të mjaftueshme në punën me Kubernetes, dhe shpesh kanë mungesë edhe me ngarkesën për të cilën bëhet fjalë.

Pra ndaj, a duhet të startohet Kafka në Kubernetes? Një pyetje e kundërt: a do ta ketë Kafka një funksionim më të mirë pa Kubernetes? Këtu është pse dua të theksoj në këtë artikull se si Kafka dhe Kubernetes plotësojnë njëri-tjetrin, dhe cilat janë pengesat që mund të hasni gjatë kombinimit të tyre.

Koha e ekzekutimit

Le të flasim për një gjë bazike — ambientin e ekzekutimit si i tillë.

Në ditën e fillimit të modulit, struktura e tij bëhet e disponueshme. Studimi në UoL përbëhet nga cikli në vijim:

Brokerat e Kafka janë efikasë kur punohet me CPU. TLS mund të sjellë disa kosto. Megjithatë, klientët e Kafka mund ta ngarkojnë më shumë CPU-në nëse përdorin enkriptimin, por kjo nuk ndikon te brokerat.

Memoria

Brokerat e Kafka marrin shumë memorje. Madhësia e grumbullit të JVM zakonisht duhet të kufizohet në 4–5 GB, por gjithashtu do të keni nevojë për shumë memorje sistemi, pasi Kafka e përdor shumë aktivisht cache-në e faqeve. Në Kubernetes, përcaktoni përkatësisht kufijtë e burimeve dhe kërkesat e kontejnerit.

Ruajtja e të dhënave

Ruajtja e të dhënave në konteinerë është efemere – të dhënat humbin gjatë ribashkimit. Për të dhënat e Kafka, mund të përdorni një volum, dhe efekti do të jetë i ngjashëm: të dhënat e brokerit tuaj do të humbin pas përfundimit. Mesazhet tuaja megjithatë mund të ruhen te brokerat e tjerë si replikat. Pra, pas ribashkimit, brokeri që dështoi duhet të riprodhojë të gjitha të dhënat si hapin e parë, dhe ky proces mund të marrë mjaft kohë. emptyDir, dhe efekti do të jetë i ngjashëm: të dhënat e brokerit tuaj do të humbin pas përfundimit. Mesazhet tuaja megjithatë mund të ruhen te brokerat e tjerë si replikat. Pra, pas ribashkimit, brokeri që dështoi duhet të riprodhojë të gjitha të dhënat si hapin e parë, dhe ky proces mund të marrë mjaft kohë.

Këtu është pse duhet të përdorni ruajtje të qëndrueshme të të dhënave. Le të jetë kjo një ruajtje e qëndrueshme jo-lokale me një sistem skedari XFS apo, më saktësisht, ext4. Mos përdorni NFS. Të kam paralajmëruar. NFS versionet v3 ose v4 nuk do të funksionojnë. Në mënyrë të përmbledhur, brokeri Kafka do të bjerë, nëse nuk arrin të heqë dosjen me të dhëna për shkak të problemeve me 'rilidhjet e mëdha', që janë aktuale në NFS. Nëse deri tani nuk ju kam bindur, shikoni me kujdes. lexoni këtë artikull. Ruajtja e të dhënave duhet të jetë jo-lokale, që Kubernetes të mund të zgjedhë më fleksibël një nyje të re pas ribashkimit ose relokimit.

Rrjeti

Si në rastin e shumicës së sistemeve të shpërndara, performanca e Kafka varet shumë nga minimizimi i vonesave në rrjet dhe maksimizimi i gjerësisë së brezit. Mos u përpiqni të vendosni të gjithë brokerët në një mënyrë të njëjtë, sepse kjo do të ulë disponueshmërinë. Nëse një nyje Kubernetes dështojnë, do të dështojë gjithashtu e gjithë klasteri Kafka. Po ashtu, mos e shpërndani klasterin Kafka në qendra të plota të të dhënave. E njëjta gjë vlen për klasterin 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 internetit të Kubernetes ka një udhëzues shumë të mirë për mënyrën e konfigurimit të ZooKeeper me anë të manifestesh. Duke qenë se ZooKeeper është pjesë e Kafka, kjo është një fillim i mirë për të njohur konceptet që zbatohen në Kubernetes këtu. Pas kuptimit të kësaj, do të jeni në gjendje të përdorni të njëjtat koncepte edhe me klasterin Kafka.

• Nën: pod – është njësia minimale e shpërndarë në Kubernetes. Pod-i përmban ngarkesën tuaj të punës, ndërsa vetë pod-i korrespondon me procesin tuaj në klaster. Në një pod përmbahen 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ë objekt Kubernetes që punon me ngarkesa të shumta të punës, që ruajnë gjendjet, dhe këto ngarkesa kërkojnë koordinim. StatefulSet ofron garanci në lidhje me renditjen e podëve dhe unikësinë e tyre.
• Shërbimet pa kokë: Shërbimet lejojnë shkëputjen e podëve nga klientët përmes një emri logjik. Kubernetes është përgjegjës për balancimin e ngarkesës në këtë rast. Megjithatë, gjatë operacioneve me ngarkesa pune që ruajnë gjendjen, siç është rasti me ZooKeeper dhe Kafka, klientët duhet të shkëmbejnë informacion me një instancë specifike. Këtu do t'ju nevojiten shërbimet pa kokë: në këtë rast, klienti do të ketë ende një emër logjik, por nuk do të jetë e nevojshme të drejtoheni drejtpërdrejt te pod-i.
• Voli për ruajtje afatgjatë: këto volime janë të nevojshme për konfigurimin e një ruajtjeje afatgjatë blloku jo-lokale, e cila u përmend më sipër.

Në Yolean ofron një grup të plotë manifestesh, përmes të cilave ë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ë lehtësisht e mundur të instaloni paketa të paracaktuara të software-it, të përshkruara në diagramet Helm. Një diagram Helm i mirë e lehtëson një detyrë të komplikuar: si të konfiguroni saktësisht të gjitha parametrat për të përdorur Kafka në Kubernetes. Ekzistojnë disa diagrame Kafka: zyrtarja ndodhet në gjendje inkubatorike, një tjetër është nga Confluent, një tjetër – nga Bitnami.

Operatorët

Pasi Helm ka disa disavantazhe, një mjet tjetër po fiton popullaritet të madh: operatorët e Kubernetes. Një operator jo vetëm që paketoi softuerin për Kubernetes, por gjithashtu ju lejon të shpërndani atë softuer dhe të menaxhoni atë.

Në listën e operatorëve mahnitës përmenden dy operatorë për Kafka. Një nga ta është Strimzi. Me ndihmën e Strimzi, ngritja e një klasteri Kafka është e lehtë dhe ndodh për pak minuta. Praktikisht nuk nevojitet konfigurim, përveç kësaj, vetë operatori ofron disa mundësi të këndshme, siç është enkriptimi TLS pikë në pikë brenda klasterit. Confluent gjithashtu ofron operatorin e tij.

Performanca

Është shumë e rëndësishme të testoni performancën duke i siguruar instalimit tuaj të Kafka piket e kontrollit. Testet e tilla do t'ju ndihmojnë të zbuloni ngushticat e mundshme, përpara se të fillojnë problemet. Fatmirësisht, Kafka tashmë ofron dy mjetet për testimin e performancës: kafka-producer-perf-test.sh dhe kafka-consumer-perf-test.sh. Shfrytëzoni ato aktivisht. Për referencë, mund të konsultoheni me rezultatet që janë përshkruar në this post Jay Kreps, ose të orientoheni në këtë rishikim Amazon MSK nga Stéphane Maarek.

Operacionet

Monitorimi

Transparenca në sistem është shumë e rëndësishme - përndryshe nuk do të kuptoni se çfarë ndodh. Sot ka një arsenal të fortë mjetesh që ofrojnë monitorim të bazuar në metrikat 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) nëpërmjet eksportuesit JMX - në mënyrën më të thjeshtë. Nëse ndihmojmë metrikat e cAdvisor, do të mund të kuptoni më plotësisht se si përdoren burimet në Kubernetes.

Strimzi ofron një shembull shumë të lehtë për t'u përdorur të panelit Grafana për Kafka. Ai vizualizon metrikat kryesore, siç janë sektorët që nuk janë replikuar ose ata që janë offline. E gjithë kjo është shumë e kuptueshme. Këto metrika plotësohen me informacion rreth përdorimit të burimeve dhe performancës, si dhe me treguesit e stabilitetit. Kështu, ju merrni mbikëqyrje bazike të klasterit Kafka falas!

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

Të gjitha këto do të ishte mirë të plotësoheshin me mbikëqyrjen e klientëve (metrikat për konsumatorët dhe prodhuesit), si dhe mbikëqyrjen e vonesave (për këtë ka Burrow) dhe mbikëqyrjen e përbashkët – për këtë përdorni Kafka Monitor.

Regjistrimi

Regjistrimi është një detyrë shumë e rëndësishme. Sigurohuni që të gjitha kontejnerët në instalimin tuaj Kafka të regjistrohen në stdout dhe stderr, dhe gjithashtu sigurohuni që klasteri juaj Kubernetes të grumbullojë të gjitha log-et në një infrastrukturë të centralizuar të regjistrimit, siç është Elasticsearch.

Kontrollimi i funksionimit

Kubernetes përdor sondat "të gjallë" (liveness) dhe "gatishmërisë" (readiness) për të kontrolluar nëse pods tuaj funksionojnë normalisht. Nëse kontrolli i gjallë dështon, Kubernetes do ta ndalë këtë kontejner dhe pastaj do ta rinisë automatikisht, nëse politika e rinisjes është vendosur siç duhet. Nëse kontrolli i gatishmërisë dështon, atëherë Kubernetes izolchon këtë pod nga shërbimi i kërkesave. Kështu, në raste të tilla nuk kërkohet ndërhyrje manuale, dhe kjo është një përfitim i madh.

Kryerja e përditësimeve

StatefulSet mbështet përditësime automatike: duke zgjedhur strategjinë RollingUpdate, çdo pod Kafka do të përditësohet një nga një. Kështu, mund të reduktoni kohëzgjatjen e ndalesave në zero.

Zgjerimi

Masa e klasterit Kafka është një detyrë e vështirë. Sidoqoftë, në Kubernetes është shumë e lehtë të masë pods deri në numrin e caktuar të replikave, dhe kjo do të thotë se mund të përcaktoni deklarativisht sa brokerë Kafka të doni. Më e komplikuara në këtë rast është rishpërndarja e sektorëve pas masës së sipërme ose para masës së poshtme. Përsëri, Kubernetes do t'ju ndihmojë me këtë detyrë.

Administrim

Detyrat e lidhura me administrimin e klasterit tuaj Kafka, në veçanti, krijimi i temave dhe ricaktimi i sektorëve, mund të realizohen me ndihmën e skripteve të disponueshme, duke hapur ndërfaqen e komandës në pod-et tuaja. Sidoqoftë, këtë zgjidhje nuk është shumë e bukur. Strimzi mbështet menaxhimin e temave përmes një operatori tjetër. Këtu ka vend për përmirësim.

Backup dhe rikuperim

Tani disponueshmëria e Kafka do të varet edhe nga disponueshmëria e Kubernetes. Nëse klasteri juaj Kubernetes bie, në rastin më të keq, do të bjerë edhe klasteri Kafka. Sipas ligjit të Murfit, kjo do të ndodhë patjetër dhe do të humbni të dhënat. Për të ulur rrezikun e këtij lloji, punoni me kujdes konceptin e backup-it. Mund të shfrytëzoni MirrorMaker, një alternativë është të përdorni S3, siç përshkruhet në këtë post nga Zalando.

Përfundim

Kur punoni me klastera të vegjël ose mesatarë Kafka, është me të vërtetë e arsyeshme të përdorni Kubernetes, pasi ofron fleksibilitet të shtuar dhe lehtëson punën me operatorët. Nëse keni kërkesa shumë serioze jo-funksionale, lidhur me vonesat dhe/apo kapacitetin, atëherë ndoshta është më mirë të shqyrtoni një opsion tjetër implementimi.

Burimi: habr.com