Vai Kafka uz Kubernetes ir laba?

Sveicināti, Habr!

Savulaik bijām pirmie, kas Å”o tēmu iepazÄ«stināja Krievijas tirgÅ« Kafka un turpināt trase tās attÄ«stÄ«bai. Jo Ä«paÅ”i mēs atradām tēmu par mijiedarbÄ«bu starp Kafku un Kubernetes. Novērojams (un diezgan uzmanÄ«gs) raksts Ŕī tēma tika publicēta Confluent emuārā pagājuŔā gada oktobrÄ« ar Gvenas Å apiras autorÄ«bu. Å odien vēlamies pievērst jÅ«su uzmanÄ«bu nesenākam aprīļa rakstam, ko rakstÄ«jis Johans GÄ«gers, kurÅ”, lai arÄ« nosaukumā ne bez jautājuma zÄ«mes, tomēr aplÅ«ko Å”o tēmu saturiskāk, papildinot tekstu ar interesantām saitēm. Ja varat, lÅ«dzu, piedodiet mums bezmaksas ā€œhaosa pērtiÄ·aā€ tulkojumu!

Vai Kafka uz Kubernetes ir laba?

Ievads

Kubernetes ir paredzēts bezvalsts darba slodzes apstrādei. Parasti Ŕādas darba slodzes tiek parādÄ«tas mikropakalpojumu arhitektÅ«ras veidā, tās ir vieglas, labi mērogotas horizontāli, atbilst 12 faktoru lietojumprogrammu principiem un var strādāt ar automātiskiem slēdžiem un haosa pērtiÄ·iem.

No otras puses, Kafka būtībā darbojas kā izplatīta datu bāze. Līdz ar to strādājot nākas saskarties ar stāvokli, un tas ir daudz smagāks par mikropakalpojumu. Kubernetes atbalsta statusa slodzes, taču, kā Kelsija Haitaure norāda divos tvītos, ar tām jārīkojas uzmanīgi:

Dažiem cilvēkiem Ŕķiet, ka, ja Kubernetes pievienosit statusa darba slodzei, tā kļūst par pilnÄ«bā pārvaldÄ«tu datu bāzi, kas konkurē ar RDS. Tas ir nepareizi. VarbÅ«t, ja pietiekami smagi strādāsi, pievienosi papildu komponentus un piesaistÄ«si SRE inženieru komandu, varēsi uzbÅ«vēt RDS virsÅ« Kubernetes.

Es vienmēr iesaku ikvienam ievērot Ä«paÅ”u piesardzÄ«bu, veicot Kubernetes statusa slodzes. Lielākajai daļai cilvēku, kas jautā ā€œvai varu palaist statusful workloads uz Kubernetesā€, nav pietiekamas pieredzes darbā ar Kubernetes, un bieži vien arÄ« ar darba slodzi, par kuru viņi jautā.

Tātad, vai jums vajadzētu vadÄ«t Kafku vietnē Kubernetes? Pretjautājums: vai Kafka labāk strādās bez Kubernetes? Tāpēc Å”ajā rakstā vēlos izcelt, kā Kafka un Kubernetes viens otru papildina un kādas nepilnÄ«bas var rasties, tos apvienojot.

PabeigŔanas laiks

Parunāsim par pamata lietu ā€“ paÅ”u izpildlaika vidi

process

Kafka brokeri ir draudzÄ«gi centrālajam procesoram. TLS var radÄ«t papildu izmaksas. Tomēr Kafka klienti var izmantot vairāk CPU, ja viņi izmanto Å”ifrÄ“Å”anu, taču tas neietekmē brokerus.

Atmiņa

Kafkas brokeri apēd atmiņu. JVM kaudzes lielums parasti ir ierobežots lÄ«dz 4ā€“5 GB, taču jums bÅ«s nepiecieÅ”ams arÄ« daudz sistēmas atmiņas, jo Kafka ļoti intensÄ«vi izmanto lapas keÅ”atmiņu. Programmā Kubernetes iestatiet attiecÄ«gi konteinera resursu un pieprasÄ«jumu ierobežojumus.

Datu krātuve

Datu glabāŔana konteineros ir Ä«slaicÄ«ga ā€” dati tiek zaudēti, restartējot. Kafka datiem varat izmantot sējumu emptyDir, un efekts bÅ«s lÄ«dzÄ«gs: pēc pabeigÅ”anas jÅ«su brokera dati tiks zaudēti. JÅ«su ziņojumus joprojām var saglabāt citos brokeros kā kopijas. Tāpēc pēc restartÄ“Å”anas neveiksmÄ«gajam brokerim vispirms ir jāreplicē visi dati, un Å”is process var aizņemt daudz laika.

Tāpēc jums vajadzētu izmantot ilgtermiņa datu glabāŔanu. Lai tā bÅ«tu nelokāla ilgtermiņa glabāŔana ar XFS failu sistēmu vai, precÄ«zāk, ext4. Neizmantojiet NFS. ES tevi brÄ«dināju. NFS versijas v3 vai v4 nedarbosies. ÄŖsāk sakot, Kafka brokeris avarēs, ja nevarēs izdzēst datu direktoriju NFS "stulbās pārdēvÄ“Å”anas" problēmas dēļ. Ja es tevi vēl neesmu pārliecinājis, tad ļoti uzmanÄ«gi izlasi Å”o rakstu. Datu krātuvei jābÅ«t nelokālai, lai Kubernetes pēc restartÄ“Å”anas vai pārvietoÅ”anas varētu elastÄ«gāk izvēlēties jaunu mezglu.

TÄ«kls

Tāpat kā lielākajā daļā izplatÄ«to sistēmu, Kafka veiktspēja ir ļoti atkarÄ«ga no tÄ«kla latentuma samazināŔanas lÄ«dz minimumam un joslas platumam lÄ«dz maksimālajam. Nemēģiniet mitināt visus brokerus vienā mezglā, jo tas samazinās pieejamÄ«bu. Ja Kubernetes mezgls neizdodas, viss Kafka klasteris neizdosies. Tāpat neizkliedējiet Kafka kopu visos datu centros. Tas pats attiecas uz Kubernetes klasteru. Labs kompromiss Å”ajā gadÄ«jumā ir izvēlēties dažādas pieejamÄ«bas zonas.

Konfigurācija

Regulāri manifesti

Vietnē Kubernetes ir ļoti labs ceļvedis par to, kā konfigurēt ZooKeeper, izmantojot manifestus. Tā kā ZooKeeper ir daļa no Kafka, Ŕī ir laba vieta, kur sākt iepazÄ«ties ar Kubernetes koncepcijām. Kad to saprotat, varat izmantot tos paÅ”us jēdzienus ar Kafka kopu.

  • Saskaņā ar: Pods ir mazākā izvietojamā vienÄ«ba Kubernetes. Aplikumā ir ietverta jÅ«su darba slodze, un pats pods atbilst procesam jÅ«su klasterÄ«. Pāksts satur vienu vai vairākus konteinerus. Katrs ZooKeeper serveris ansamblÄ« un katrs brokeris Kafka klasterÄ« darbosies atseviŔķā podā.
  • StatefulSet: StatefulSet ir Kubernetes objekts, kas apstrādā vairākas statusa darba slodzes, un Ŕādas darba slodzes ir jāsaskaņo. StatefulSets sniedz garantijas par pākstu pasÅ«tÄ«Å”anu un to unikalitāti.
  • Pakalpojumi bez galvas: pakalpojumi ļauj atdalÄ«t aplikumus no klientiem, izmantojot loÄ£isku nosaukumu. Kubernetes Å”ajā gadÄ«jumā ir atbildÄ«gs par slodzes lÄ«dzsvaroÅ”anu. Tomēr, strādājot ar statusa darba slodzi, piemēram, ZooKeeper un Kafka, klientiem ir jāsazinās ar konkrētu gadÄ«jumu. Å eit noder bezgalvu pakalpojumi: Å”ajā gadÄ«jumā klientam joprojām bÅ«s loÄ£isks vārds, taču jums nebÅ«s tieÅ”i jāsazinās ar podziņu.
  • Ilgtermiņa uzglabāŔanas apjoms: Å”ie sējumi ir nepiecieÅ”ami, lai konfigurētu iepriekÅ” minēto nelokālo bloku pastāvÄ«go krātuvi.

uz Yolean NodroÅ”ina visaptveroÅ”u manifestu kopu, lai palÄ«dzētu jums sākt darbu ar Kafka vietnē Kubernetes.

Stūres diagrammas

Helm ir Kubernetes pakotņu pārvaldnieks, ko var salÄ«dzināt ar OS pakotņu pārvaldniekiem, piemēram, yum, apt, Homebrew vai Chocolatey. Tas atvieglo iepriekÅ” definētu programmatÅ«ras pakotņu instalÄ“Å”anu, kas aprakstÄ«tas Helm diagrammās. Pareizi izvēlēta Helm diagramma atvieglo sarežģīto uzdevumu, kā pareizi konfigurēt visus parametrus, lai izmantotu Kafka vietnē Kubernetes. Ir vairākas Kafkas diagrammas: atrodas oficiālā inkubatora stāvoklÄ«, ir viens no krustojums, vēl viens - no BitNami.

Operatori

Tā kā Helm ir zināmi trÅ«kumi, ievērojamu popularitāti iegÅ«st vēl viens rÄ«ks: Kubernetes operatori. Operators ne tikai iepako programmatÅ«ru Kubernetes, bet arÄ« ļauj izvietot Ŕādu programmatÅ«ru un pārvaldÄ«t to.

Sarakstā pārsteidzoÅ”i operatori Ir minēti divi Kafkas operatori. Viens no viņiem - Strimzi. Izmantojot Strimzi, savu Kafka kopu ir viegli izveidot un palaist dažu minÅ«Å”u laikā. Praktiski nav nepiecieÅ”ama konfigurācija, turklāt pats operators nodroÅ”ina dažas jaukas iespējas, piemēram, point-to-point TLS Å”ifrÄ“Å”anu klastera ietvaros. Confluent arÄ« nodroÅ”ina savs operators.

ŠŸŃ€Š¾ŠøŠ·Š²Š¾Š“ŠøтŠµŠ»ŃŒŠ½Š¾ŃŃ‚ŃŒ

Ir svarÄ«gi pārbaudÄ«t veiktspēju, veicot Kafka eksemplāra salÄ«dzinoÅ”o novērtÄ“Å”anu. Šādi testi palÄ«dzēs jums atrast iespējamās vājās vietas, pirms rodas problēmas. Par laimi Kafka jau piedāvā divus veiktspējas testÄ“Å”anas rÄ«kus: kafka-producer-perf-test.sh Šø kafka-consumer-perf-test.sh. AktÄ«vi izmantojiet tos. Uzziņai varat atsaukties uz rezultātiem, kas aprakstÄ«ti sadaļā Å”o ziņu Jay Kreps, vai koncentrēties uz Å”o apskatu Amazon MSK, autors StĆ©phane Maarek.

Operācijas

Uzraudzība

PārredzamÄ«ba sistēmā ir ļoti svarÄ«ga ā€“ pretējā gadÄ«jumā jÅ«s nesapratÄ«siet, kas tajā notiek. MÅ«sdienās ir pieejams stabils rÄ«ku komplekts, kas nodroÅ”ina uz metriku balstÄ«tu uzraudzÄ«bu mākoņdatoÅ”anas stilā. Divi populāri rÄ«ki Å”im nolÅ«kam ir Prometheus un Grafana. Prometheus var apkopot metriku no visiem Java procesiem (Kafka, Zookeeper, Kafka Connect), izmantojot JMX eksportētāju ā€“ vienkārŔākajā veidā. Ja pievienojat cAdvisor metriku, varat pilnÄ«gāk izprast, kā resursi tiek izmantoti Kubernetes.

Strimzi ir ļoti ērts Grafana informācijas paneļa piemērs priekÅ” Kafka. Tas vizualizē galvenos rādÄ«tājus, piemēram, par nepietiekami replicētiem vai bezsaistē esoÅ”ajiem sektoriem. Tur viss ir ļoti skaidrs. Å os rādÄ«tājus papildina informācija par resursu izmantoÅ”anu un veiktspēju, kā arÄ« stabilitātes rādÄ«tāji. Tātad jÅ«s saņemat pamata Kafka klasteru uzraudzÄ«bu par velti!

Vai Kafka uz Kubernetes ir laba?

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

BÅ«tu jauki to visu papildināt ar klientu uzraudzÄ«bu (metrika par patērētājiem un ražotājiem), kā arÄ« latentuma uzraudzÄ«bu (tam ir BurzÄ«ties) un pilnÄ«ga uzraudzÄ«ba ā€” Å”im lietojumam Kafka monitors.

Mežizstrāde

Mežizstrāde ir vēl viens svarÄ«gs uzdevums. Pārliecinieties, vai visi konteineri jÅ«su Kafka instalācijā ir reÄ£istrēti stdout Šø stderr, kā arÄ« nodroÅ”iniet, lai jÅ«su Kubernetes klasteris visus žurnālus apkopotu centrālajā reÄ£istrÄ“Å”anas infrastruktÅ«rā, piemēram, Elastikas meklÄ“Å”ana.

Funkcionālā pārbaude

Kubernetes izmanto dzÄ«vÄ«guma un gatavÄ«bas zondes, lai pārbaudÄ«tu, vai jÅ«su podi darbojas normāli. Ja dzÄ«vÄ«guma pārbaude neizdodas, Kubernetes apturēs Å”o konteineru un pēc tam automātiski restartēs to, ja restartÄ“Å”anas politika ir iestatÄ«ta atbilstoÅ”i. Ja gatavÄ«bas pārbaude neizdodas, Kubernetes izolē apkopi no apkalpoÅ”anas pieprasÄ«jumiem. Tādējādi Ŕādos gadÄ«jumos manuāla iejaukÅ”anās vairs nemaz nav nepiecieÅ”ama, kas ir liels pluss.

Notiek atjauninājumu izlaiŔana

StatefulSets atbalsta automātiskos atjauninājumus: ja atlasāt RollingUpdate stratēģiju, katrs sadaļā Kafka tiks atjaunināts pēc kārtas. Tādā veidā dīkstāves laiku var samazināt līdz nullei.

MērogoÅ”ana

Kafka klastera mērogoÅ”ana nav viegls uzdevums. Tomēr Kubernetes ļauj ļoti vienkārÅ”i mērogot aplikācijas lÄ«dz noteiktam kopiju skaitam, kas nozÄ«mē, ka varat deklaratÄ«vi definēt tik daudz Kafka brokeru, cik vēlaties. Sarežģītākā lieta Å”ajā gadÄ«jumā ir sektoru maiņa pēc mērogoÅ”anas vai pirms samazināŔanas. Atkal Kubernetes jums palÄ«dzēs ar Å”o uzdevumu.

Administrācija

Uzdevumus, kas saistÄ«ti ar jÅ«su Kafka klastera administrÄ“Å”anu, piemēram, tēmu izveidi un sektoru atkārtotu pieŔķirÅ”anu, var veikt, izmantojot esoÅ”os čaulas skriptus, atverot komandrindas interfeisu savos podiņos. Tomēr Å”is risinājums nav Ä«paÅ”i skaists. Strimzi atbalsta tēmu pārvaldÄ«bu, izmantojot citu operatoru. Å eit ir daži uzlabojumi.

DublēŔana un atjaunoŔana

Tagad Kafkas pieejamÄ«ba bÅ«s atkarÄ«ga arÄ« no Kubernetes pieejamÄ«bas. Ja jÅ«su Kubernetes klasteris neizdosies, sliktākajā gadÄ«jumā neizdosies arÄ« jÅ«su Kafka klasteris. Saskaņā ar Mērfija likumu tas noteikti notiks, un jÅ«s zaudēsiet datus. Lai samazinātu Ŕāda veida risku, izveidojiet labu rezerves koncepciju. Varat izmantot MirrorMaker, cita iespēja ir izmantot S3, kā aprakstÄ«ts Å”ajā pastu no Zalando.

Secinājums

Strādājot ar maziem un vidējiem Kafka klasteriem, noteikti ir vērts izmantot Kubernetes, jo tas nodroÅ”ina papildu elastÄ«bu un vienkārÅ”o operatora pieredzi. Ja jums ir ļoti nozÄ«mÄ«gas nefunkcionālas latentuma un/vai caurlaidspējas prasÄ«bas, iespējams, labāk ir apsvērt kādu citu izvietoÅ”anas iespēju.

Avots: www.habr.com

Pievieno komentāru