Vai Kafka uz Kubernetes ir laba lieta?

Sveicinām jūs, Habr!

Savam laikam mēs pirmie ieviesām tēmu Krievijas tirgū Kafka un turpinām sekot sektora attīstību. Īpaši mūs ieinteresēja tēma par Kafka un Kubernetes. Ieviešams (un diezgan piesardzīgs) raksts raksts par šo tēmu tika publicēts Confluent uzņēmuma blogā vēl pagājušā gada oktobrī, autors ir Gvens Šapira. Šodien mēs vēlamies pievērst jūsu uzmanību jaunākam, aprīļa rakstam no Johann Giger, kurš, lai arī nav izticis bez jautājuma zīmes virsrakstā, aplūko tēmu konkrētāk, papildinot tekstu ar interesantām saites. Piedodiet mums lūdzu brīvo tulkojumu "chaos monkey", ja iespējams!

Ievads

Kubernetes ir paredzēts darbam ar slodzēm, kas nesaglabā stāvokli. Parasti šādas darba slodzes ir attēlotas mikroservisu arhitektūrā, tās ir vieglas, labi horizontāli mērogojamas, pakļaujas 12 faktoru lietojumu principiem, ļauj strādāt ar automātiskajiem pārtraucējiem (circuit breaker) un haosa pērtiķiem (chaos monkeys).

Kafka, atrodoties otrā pusē, būtībā darbojas kā sadalīta datu bāze. Tādējādi, strādājot, jums jātiek galā ar stāvokli, kas ir daudz smagāks par mikroservisu. Kubernetes atbalsta slodzes ar saglabāto stāvokli, bet, kā norāda Kelsi Hightower divos savos tvītos, ar tām jāuzmanās:

Dažiem šķiet, ka, ja uzliks Kubernetes uz slodzes ar saglabāto stāvokli, tā kļūst par pilnībā pārvaldītu datu bāzi, kas spēj sacensties ar RDS. Tā nav. Varbūt, ja pietiekami grūti strādā, piesaisti papildu komponentus un pieaicini SRE inženieru komandu, var izveidot RDS virs Kubernetes.

Vienmēr visiem iesaku būt ārkārtīgi uzmanīgiem, uzsākot slodzes ar saglabāto stāvokli uz Kubernetes. Lielākā daļa no tiem, kas jautā: "Vai es varu palaist slodzes ar saglabāto stāvokli uz Kubernetes?", nenodrošina pietiekamu pieredzi darbā ar Kubernetes, un bieži arī ar konkrēto slodzi, par kuru jautā.

Tātad, vai ir vērts palaist Kafka uz Kubernetes? Pretjautājums: vai Kafka darbosies labāk bez Kubernetes? Tāpēc es vēlos uzsvērt šajā rakstā, kā Kafka un Kubernetes papildina viens otru un kādas ir tām kopējās problēmas.

Izpildes laiks

Pārskatīsim pamata lietu — izpildes laika vidi kopumā

Process

Kafka brokeri ir ērti, strādājot ar CPU. TLS var radīt dažas izmaksas. Tajā pašā laikā, Kafka klienti var stipri noslogot CPU, ja izmanto šifrēšanu, taču tas neietekmē brokerus.

Atmiņa

Kafka brokeri patērē daudz atmiņas. JVM kaudzes lielumu parasti var ierobežot līdz 4–5 GB, taču jums vajadzēs arī daudz sistēmas atmiņas, jo Kafka intensīvi izmanto lapu kešu. Kubernetes attiecīgi nosakiet konteineru resursu ierobežojumus un pieprasījumus.

Datu glabāšana

Datu glabāšana konteineros ir efemeriska — dati tiek zaudēti restartējot. Kafka datiem varat izmantot apjomu emptyDir, un efekts būs līdzīgs: jūsu brokera dati tiks zaudēti pēc iznākšanas. Jūsu ziņojumi tomēr var saglabāties citiem brokeriem kā replikas. Tāpēc, pēc restartēšanas neveiksmīgais brokeris vispirms ir jāreplikē visi dati, un šim procesam var būt nepieciešams ilgs laiks.

Tāpēc ir svarīgi izmantot ilgtermiņa datu glabāšanu. Tas jābūt ne-lokālam ilgtermiņa glabāšanai ar XFS failu sistēmu vai precīzāk, ext4. Neizmantojiet NFS. Es jūs brīdināju. NFS versijas v3 vai v4 nedarbosies. Īsumā, Kafka brokeris tiks apturēts, ja tas nespēs dzēst datu katalogu 'muļķīgu pārsaukšanu' problēmu dēļ, kas aktuāla NFS. Ja es jūs joprojām neesmu pārliecinājis, ļoti uzmanīgi izlasiet šo rakstu. Datu glabāšanai jābūt ne-lokālai, lai Kubernetes varētu elastīgāk izvēlēties jaunu mezglu pēc restartēšanas vai relokācijas.

Tīkls

Kā jau tas ir ar lielāko daļu izplatīto sistēmu, Kafka veiktspēja ļoti atkarīga no tā, lai tīkla aizture būtu minimāla, bet joslas platums maksimāls. Nemēģiniet izvietot visus brokerus vienā un tajā pašā mezglā, jo tas samazinās pieejamību. Ja Kubernetes mezgls neizdosies, neizdosies arī visa Kafka klase. Arī nestrādājiet ar Kafka klasi dažādās datu centros. Tas pats attiecas uz Kubernetes klasēm. Labs kompromiss šajā gadījumā ir izvēlēties dažādas pieejamības zonas.

Konfigurācija

Parastie manifesti

Kubernetes vietnē ir ļoti labs ceļvedis kā iestatīt ZooKeeper, izmantojot manifestus. Tā kā ZooKeeper ir daļa no Kafka, ērti ir sākt iepazīšanos ar to, kādas Kubernetes koncepcijas šeit ir piemērojamas. Sapratuši to, jūs varēsiet pielietot tās pašas koncepcijas arī Kafka klasē.

• Zem: pods – tas ir minimālais izvietojamais vienums Kubernetes. Podā atrodas jūsu darba slodze, bet pats pods atbilst procesam jūsu klasē. Podā var būt viens vai vairāki konteineri. Katrs ZooKeeper serveris ansamblī un katrs brokers Kafka klasē darbosies atsevišķā podā.
• StatefulSet: StatefulSet – tā ir Kubernetes objekts, kas strādā ar vairākiem darba slodzi, kas saglabā stāvokli, un šādām slodzēm ir nepieciešama koordinācija. StatefulSet nodrošina garantijas par podu secību un to unikālumu.
• Headless pakalpojumi: Pakalpojumi ļauj atvienot podus no klientiem, izmantojot loģisko nosaukumu. Kubernetes šajā gadījumā atbild par slodzes līdzsvarošanu. Tomēr, strādājot ar stāvokļa saglabājošām slodzēm, kā tas ir ar ZooKeeper un Kafka, klientiem ir nepieciešams apmainīties ar informāciju ar konkrētu instanci. Tieši šeit noderēs headless pakalpojumi: šādā gadījumā klientam būs loģisks nosaukums, bet tieši pie poda var nebūt jāpievēršas.
• Ilgtermiņa glabāšanas apjoms: šādi apjomi nepieciešami, lai konfigurētu ne-lokālo blokveida ilgtermiņa glabāšanas risinājumu, par kuru tika runāts iepriekš.

Uz Yolean nodrošina izsmeļošu manifestu kopumu, ar kura palīdzību ērti uzsākt darbu ar Kafka uz Kubernetes.

Helm diagrammas

Helm – ir pakotņu pārvaldnieks Kubernetes, ko var salīdzināt ar operētājsistēmu pakotņu pārvaldniekiem, piemēram, yum, apt, Homebrew vai Chocolatey. To ir ērti izmantot, lai instalētu iepriekš definētus programmatūras paketus, kas aprakstīti Helm diagrammās. Labi izstrādāta Helm diagramma atvieglo sarežģītu uzdevumu: kā pareizi konfigurēt visus parametrus, lai izmantotu Kafka Kubernetes. Ir vairākas Kafka diagrammas: oficiālā atrodas inkubatoru stāvoklī, ir viena no Confluent, vēl viena – no Bitnami.

Operatori

Tā kā Helm ir noteikti trūkumi, arvien vairāk popularitātes iegūst vēl viens rīks: Kubernetes operatori. Operators ne tikai iesaiņo programmatūru Kubernetes, bet arī ļauj jums to izvietot un pārvaldīt.

Sarakstā pārsteidzošu operatoru tiek minēti divi operatori Kafka. Viens no tiem ir Strimzi. Ar Strimzi nav grūti izveidot Kafka klasteri dažās minūtēs. Praktiski nav nepieciešama papildu konfigurācija, turklāt pats operators piedāvā dažas patīkamas iespējas, piemēram, TLS šifrēšanu „punktu uz punktu” klasterī. Confluent arī piedāvā savu operatoru.

Veiktspēja

Ļoti svarīgi ir testēt veiktspēju, aprīkojot jūsu uzstādīto Kafka instance ar kontrolpunktiem. Šādi testi palīdzēs atklāt potenciālos šaurus vietas, pirms rodas problēmas. Par laimi, Kafka jau piedāvā divus rīkus veiktspējas testēšanai: kafka-producer-perf-test.sh un kafka-consumer-perf-test.sh. Aktīvi izmantojiet tos. Jūs varat atsaukties uz rezultātiem, ko aprakstījis šajā postenī Džijs Krepss, vai arī orientēties uz šo pārskatu Amazon MSK no Stéphane Maarek.

Darbības

Uzraudzība

Caurspīdība sistēmā ir ļoti svarīga – citādi jūs nesapratīsiet, kas tajā notiek. Šodien ir pamatīgs rīku kopums, kas nodrošina metrikām balstītu monitoringu cloud native stilā. Divi populāri rīki šim mērķim ir Prometheus un Grafana. Prometheus var vākt metrikas no visām Java procesiem (Kafka, Zookeeper, Kafka Connect) ar JMX eksportētāju – visvienkāršākajā veidā. Ja pievienosiet cAdvisor metrikas, jūs varēsiet pilnīgāk saprast, kā Kubernetes tiek izmantoti resursi.

Strimzi piedāvā ļoti ērti izmantojamu Grafana dēli Kafka. Tas vizualizē galvenos metriku punktus, piemēram, par nedoreplicētiem sektoriem vai tiem, kas ir off-line. Viss ir ļoti saprotams. Šie metri tiek papildināti ar informāciju par resursu izmantošanu un veiktspēju, kā arī stabilitātes indikātoriem. Tādējādi jūs saņemat pamata Kafka klastera uzraudzību bez maksas!

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

Visu to būtu labi papildināt ar klientu uzraudzību (metriku par patērētājiem un ražotājiem), kā arī ar aizkavas uzraudzību (tam ir Burrow) un caurspīdīgu uzraudzību – tāpēc izmantojiet Kafka Monitor.

Datu pieraksts

Žurnālvadība ir vēl viena ļoti svarīga uzdevuma. Pārliecinieties, ka visi konteineri jūsu Kafka instalācijā ir reģistrēti stdout un stderr, kā arī rūpējieties, lai jūsu Kubernetes klasteris apkopotu visus žurnālus centrālajā žurnālu infrastruktūrā, piemēram, Elasticsearch.

Statusa pārbaude

Kubernetes izmanto "dzīvotspējas" (liveness) un gatavības (readiness) zondus, lai pārbaudītu, vai jūsu podi darbojas normāli. Ja dzīves pārbaude neizdodas, Kubernetes apturēs šo konteineru un tad automātiski to restartēs, ja restartēšanas politika ir pareizi iestatīta. Ja gatavības pārbaude neizdodas, Kubernetes izolēs šo podu no pieprasījumu apkalpošanas. Tādējādi šādos gadījumos vairs nav nepieciešama manuāla iejaukšanās, kas ir liela priekšrocība.

Atjauninājumu izlaide

StatefulSet atbalsta automātiskos atjauninājumus: izvēloties RollingUpdate stratēģiju, katrs Kafka pods tiks atjaunināts secīgi. Tādējādi var samazināt dīkstāves laiku līdz nullei.

Mērogošana

Kafka klastera mērogošana ir sarežģīta uzdevums. Tomēr Kubernetes ļoti viegli var mērogot podus līdz noteiktam repliku skaitam, kas nozīmē, ka jūs varat deklaratīvi noteikt tik daudz Kafka brokeru, cik vēlaties. Grūtākais šajā procesā ir sektoru pārdale pēc augšup mērogošanas vai pirms lejup mērogošanas. Atkal, šajā uzdevumā jums palīdzēs Kubernetes.

Administrācija

Uzdevumi, kas saistīti ar jūsu Kafka klastera administrēšanu, tostarp tēmu veidošanu un sektoru pārdali, var tikt veikti, izmantojot pieejamos shell skriptus, atverot komandu līnijas saskarni jūsu podos. Tomēr šāds risinājums nav pārāk estētisks. Strimzi atbalsta tēmu pārvaldību, izmantojot citu operatoru. Šeit ir, ko uzlabot.

Datu dublēšana un atjaunošana

Tagad mūsu Kafka pieejamība būs atkarīga arī no Kubernetes pieejamības. Ja jūsu Kubernetes klasteris sabruks, tad sliktākajā gadījumā var sabrukt arī Kafka klasteris. Saskaņā ar Mērfija likumu tas noteikti notiks, un jūs zaudēsiet datus. Lai samazinātu šāda riska iespējamību, rūpīgi izstrādājiet dublēšanas koncepciju. Varat izmantot MirrorMaker, cita iespēja ir izmantot S3, kā aprakstīts šajā ierakstā no Zalando.

Secinājums

Strādājot ar mazākiem vai vidējiem Kafka klasteriem, noteikti ir lietderīgi izmantot Kubernetes, jo tas nodrošina papildu elastību un vienkāršo darbu ar operatoriem. Ja jums ir ļoti nopietni nefunkcionālie prasījumi, kas attiecas uz aizturi un/vai caurlaidspēju, varat apsvērt kādu citu izvietošanas risinājumu.

Avots: habr.com