A është i mirë Kafka në Kubernetes?

Përshëndetje, Habr!

Në një kohë, ne ishim të parët që prezantuam temën në tregun rus Kafka dhe vazhdoni udhë për zhvillimin e saj. Në veçanti, gjetëm temën e ndërveprimit midis Kafkës dhe Kubernetes. E vëzhgueshme (dhe mjaft e kujdesshme) artikull kjo temë u publikua në blogun Confluent në tetorin e vitit të kaluar nën autorësinë e Gwen Shapira. Sot dëshirojmë t'ju tërheqim vëmendjen tek një artikull më i fundit nga prilli i Johann Gyger, i cili, megjithëse jo pa pikëpyetje në titull, e shqyrton temën në një mënyrë më përmbajtësore, duke e shoqëruar tekstin me lidhje interesante. Ju lutemi, na falni përkthimin falas të "majmunit të kaosit" nëse mundeni!

Paraqitje

Kubernetes është krijuar për të trajtuar ngarkesat e punës pa shtetësi. Në mënyrë tipike, ngarkesa të tilla paraqiten në formën e një arkitekture mikroservice, ato janë të lehta, shkallëzohen mirë horizontalisht, ndjekin parimet e aplikacioneve me 12 faktorë dhe mund të punojnë me ndërprerësit dhe majmunët e kaosit.

Kafka, nga ana tjetër, në thelb vepron si një bazë të dhënash e shpërndarë. Kështu, kur punoni, duhet të keni të bëni me shtetin, dhe është shumë më i rëndë se një mikroshërbim. Kubernetes mbështet ngarkesat me status, por siç thekson Kelsey Hightower në dy postime në Twitter, ato duhet të trajtohen me kujdes:

Disa njerëz mendojnë se nëse futni Kubernetes në një ngarkesë pune të plotë, ai bëhet një bazë të dhënash plotësisht e menaxhuar që rivalizon RDS. Kjo eshte e gabuar. Ndoshta, nëse punoni mjaftueshëm, shtoni komponentë shtesë dhe tërheqni një ekip inxhinierësh SRE, do të jeni në gjendje të ndërtoni RDS në krye të Kubernetes.

Unë gjithmonë rekomandoj që të gjithë të kenë kujdes ekstrem kur kryejnë ngarkesa të rregullta pune në Kubernetes. Shumica e njerëzve që pyesin "a mund të ekzekutoj ngarkesa shtetërore të punës në Kubernetes" nuk kanë përvojë të mjaftueshme me Kubernetes, dhe shpesh me ngarkesën e punës për të cilën po pyesin.

Pra, a duhet ta drejtoni Kafkën në Kubernetes? Kundërpyetje: A do të funksionojë Kafka më mirë pa Kubernetes? Kjo është arsyeja pse unë dua të nënvizoj në këtë artikull se si Kafka dhe Kubernetes plotësojnë njëri-tjetrin dhe çfarë grackash mund të vijnë nga kombinimi i tyre.

Koha e përfundimit

Le të flasim për gjënë themelore - vetë mjedisin e ekzekutimit

proces

Agjentët Kafka janë miqësorë me CPU-në. TLS mund të prezantojë disa shpenzime. Sidoqoftë, klientët e Kafka mund të jenë më intensivë të CPU-së nëse përdorin enkriptim, por kjo nuk ndikon tek ndërmjetësit.

kujtim

Agjentët e Kafkës hanë kujtesën. Madhësia e grumbullit të JVM zakonisht kufizohet në 4-5 GB, por do t'ju duhet gjithashtu shumë memorie të sistemit pasi Kafka përdor shumë memorien e faqeve. Në Kubernetes, vendosni burimet e kontejnerit dhe kërkoni kufijtë në përputhje me rrethanat.

Ruajtja e të dhënave

Ruajtja e të dhënave në kontejnerë është kalimtare - të dhënat humbasin kur riniset. Për të dhënat e Kafkës mund të përdorni një vëllim emptyDir, dhe efekti do të jetë i ngjashëm: të dhënat tuaja të ndërmjetësit do të humbasin pas përfundimit. Mesazhet tuaja ende mund të ruhen në agjentë të tjerë si kopje. Prandaj, pas një rifillimi, ndërmjetësi i dështuar duhet së pari të përsërisë të gjitha të dhënat dhe ky proces mund të marrë shumë kohë.

Kjo është arsyeja pse ju duhet të përdorni ruajtjen afatgjatë të të dhënave. Le të jetë ruajtja afatgjatë jo-lokale me sistemin e skedarëve XFS ose, më saktë, ext4. Mos përdorni NFS. Te paralajmerova. Versionet NFS v3 ose v4 nuk do të funksionojnë. Me pak fjalë, ndërmjetësi Kafka do të rrëzohet nëse nuk mund të fshijë drejtorinë e të dhënave për shkak të problemit të "riemërtimit budalla" në NFS. Nëse nuk ju kam bindur akoma, me shumë kujdes lexoni këtë artikull. Ruajtja e të dhënave duhet të jetë jo-lokale në mënyrë që Kubernetes të mund të zgjedhë në mënyrë më fleksibël një nyje të re pas një rifillimi ose zhvendosjeje.

Сеть

Ashtu si me shumicën e sistemeve të shpërndara, performanca e Kafkës varet shumë nga mbajtja e vonesës së rrjetit në minimum dhe gjerësia e brezit në maksimum. Mos u përpiqni të strehoni të gjithë ndërmjetësit në të njëjtën nyje, pasi kjo do të zvogëlojë disponueshmërinë. Nëse një nyje Kubernetes dështon, i gjithë grupi Kafka do të dështojë. Gjithashtu, mos e shpërndani grupin Kafka në të gjitha qendrat e të dhënave. E njëjta gjë vlen edhe për grupin Kubernetes. Një kompromis i mirë në këtë rast është zgjedhja e zonave të ndryshme të disponueshmërisë.

konfiguracion

Manifestet e rregullta

Faqja e internetit Kubernetes ka udhëzues shumë i mirë se si të konfiguroni ZooKeeper duke përdorur manifestet. Meqenëse ZooKeeper është pjesë e Kafkës, ky është një vend i mirë për t'u njohur me të cilat konceptet Kubernetes zbatohen këtu. Pasi ta kuptoni këtë, mund të përdorni të njëjtat koncepte me një grup Kafka.

• Nën: Një pod është njësia më e vogël e vendosshme në Kubernetes. Një pod përmban ngarkesën tuaj të punës dhe vetë podi korrespondon me një proces në grupin tuaj. Një pod përmban një ose më shumë kontejnerë. Çdo server ZooKeeper në ansambël dhe çdo ndërmjetës në grupin Kafka do të funksionojë në një pod të veçantë.
• StatfulSet: Një StatefulSet është një objekt Kubernetes që trajton ngarkesa të shumta pune me status dhe ngarkesa të tilla kërkojnë koordinim. StatefulSets ofrojnë garanci në lidhje me renditjen e pods dhe uniken e tyre.
• Shërbime pa kokë: Shërbimet ju lejojnë të shkëputni pods nga klientët duke përdorur një emër logjik. Kubernetes në këtë rast është përgjegjës për balancimin e ngarkesës. Megjithatë, kur operojnë ngarkesa pune të qëndrueshme, si ZooKeeper dhe Kafka, klientët duhet të komunikojnë me një shembull specifik. Këtu janë të dobishme shërbimet pa kokë: në këtë rast, klienti do të ketë ende një emër logjik, por nuk do të duhet të kontaktoni drejtpërdrejt me podin.
• Vëllimi i ruajtjes afatgjatë: Këto vëllime nevojiten për të konfiguruar ruajtjen e vazhdueshme të bllokut jo-lokal të përmendur më sipër.

Mbi Yolean Ofron një grup gjithëpërfshirës manifestimesh për t'ju ndihmuar të filloni me Kafka në Kubernetes.

Tabelat e timonit

Helm është një menaxher paketash për një Kubernetes që mund të krahasohet me menaxherët e paketave OS si yum, apt, Homebrew ose Chocolatey. E bën të lehtë instalimin e paketave softuerike të paracaktuara të përshkruara në diagramet Helm. Një grafik Helm i zgjedhur mirë e bën të lehtë detyrën e vështirë se si të konfiguroni siç duhet të gjithë parametrat për të përdorur Kafka në Kubernetes. Ka disa diagrame të Kafkës: ndodhet ajo zyrtare ne gjendje inkubator, ka një nga që bashkohet, një tjetër - nga BitNami.

Операторы

Për shkak se Helm ka disa mangësi, një mjet tjetër po fiton popullaritet të konsiderueshëm: operatorët Kubernetes. Operatori jo vetëm që paketon softuer për Kubernetes, por gjithashtu ju lejon të vendosni një softuer të tillë dhe ta menaxhoni atë.

Në listë operatorë të mrekullueshëm Për Kafkën përmenden dy operatorë. Një prej tyre - Strimzi. Me Strimzi, është e lehtë të vihet në funksion grupi juaj Kafka në pak minuta. Praktikisht nuk kërkohet asnjë konfigurim, përveç kësaj, vetë operatori ofron disa veçori të këndshme, për shembull, kriptim TLS pikë-për-pikë brenda grupit. Confluent gjithashtu ofron operatori i vet.

prodhimtari

Është e rëndësishme të testoni performancën duke krahasuar shembullin tuaj Kafka. Teste të tilla do t'ju ndihmojnë të gjeni pengesat e mundshme përpara se të shfaqen problemet. Për fat të mirë, Kafka tashmë ofron dy mjete të testimit të performancës: kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. Përdorni ato në mënyrë aktive. Për referencë, mund t'i referoheni rezultateve të përshkruara në këtë postim Jay Kreps, ose fokusohu tek 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ë po ndodh në të. Sot ekziston një paketë mjetesh solide që ofron monitorim të bazuar në metrikë në stilin origjinal të cloud. Dy mjete të njohura për këtë qëllim janë Prometheus dhe Grafana. Prometheus mund të mbledhë metrikë nga të gjitha proceset Java (Kafka, Zookeeper, Kafka Connect) duke përdorur një eksportues JMX - në mënyrën më të thjeshtë. Nëse shtoni matjet e cAdvisor, mund të kuptoni më plotësisht se si përdoren burimet në Kubernetes.

Strimzi ka një shembull shumë të përshtatshëm të një pulti Grafana për Kafka. Ai vizualizon matjet kryesore, për shembull, në lidhje me sektorët e nën-përsëritur ose ata që janë jashtë linje. Gjithçka është shumë e qartë atje. Këto metrika plotësohen nga informacioni i përdorimit të burimeve dhe performancës, si dhe treguesit e stabilitetit. Kështu që ju merrni monitorimin bazë të grupimeve të Kafkës për asgjë!

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

Do të ishte mirë të plotësohej e gjithë kjo me monitorimin e klientit (metrikat për konsumatorët dhe prodhuesit), si dhe monitorimin e vonesës (për këtë ekziston strofull) dhe monitorimi nga fundi në fund - për këtë përdorim Kafka Monitor.

Prerjet

Regjistrimi është një detyrë tjetër kritike. Sigurohuni që të gjithë kontejnerët në instalimin tuaj Kafka të jenë të regjistruar stdout и stderr, dhe gjithashtu sigurohuni që grupi juaj Kubernetes grumbullon të gjitha regjistrat në një infrastrukturë qendrore të regjistrimit, p.sh. Elasticsearch.

Kontrolli shëndetësor

Kubernetes përdor sondat e gjallërisë dhe gatishmërisë për të kontrolluar nëse podet tuaja funksionojnë normalisht. Nëse kontrolli i gjallërisë dështon, Kubernetes do ta ndalojë atë kontejner dhe më pas do ta rifillojë automatikisht nëse politika e rinisjes caktohet në përputhje me rrethanat. Nëse kontrolli i gatishmërisë dështon, Kubernetes izolon podin nga kërkesat për servisim. Kështu, në raste të tilla, ndërhyrja manuale nuk kërkohet më, gjë që është një plus i madh.

Përditësimet në qarkullim

StatefulSets mbështesin përditësimet automatike: nëse zgjidhni strategjinë RollingUpdate, secili nën Kafka do të përditësohet me radhë. Në këtë mënyrë, koha e ndërprerjes mund të reduktohet në zero.

Shkallëzimi

Shkallëzimi i një grupi Kafka nuk është një detyrë e lehtë. Sidoqoftë, Kubernetes e bën shumë të lehtë shkallëzimin e pod-ve në një numër të caktuar kopjesh, që do të thotë se mund të përcaktoni në mënyrë deklarative sa më shumë ndërmjetës Kafka që dëshironi. Gjëja më e vështirë në këtë rast është ricaktimi i sektorëve pas shkallëzimit ose para zvogëlimit. Përsëri, Kubernetes do t'ju ndihmojë me këtë detyrë.

administratë

Detyrat që lidhen me administrimin e grupit tuaj Kafka, të tilla si krijimi i temave dhe ricaktimi i sektorëve, mund të bëhen duke përdorur skriptet ekzistuese të guaskës duke hapur ndërfaqen e linjës së komandës në podet tuaja. Megjithatë, kjo zgjidhje nuk është shumë e bukur. Strimzi mbështet menaxhimin e temave duke përdorur një operator tjetër. Këtu ka hapësirë ​​për përmirësim.

Rezervoni dhe rivendosni

Tani disponueshmëria e Kafkës do të varet edhe nga disponueshmëria e Kubernetes. Nëse grupi juaj Kubernetes dështon, atëherë në skenarin më të keq, grupi juaj Kafka gjithashtu do të dështojë. Sipas ligjit të Murphy, kjo do të ndodhë patjetër, dhe ju do të humbni të dhënat. Për të reduktuar këtë lloj rreziku, keni një koncept të mirë rezervë. Ju mund të përdorni MirrorMaker, një tjetër mundësi është të përdorni S3 për këtë, siç përshkruhet në këtë postim nga Zalando.

Përfundim

Kur punoni me grupe Kafka të vogla dhe të mesme, patjetër që ia vlen të përdorni Kubernetes pasi ofron fleksibilitet shtesë dhe thjeshton përvojën e operatorit. Nëse keni kërkesa shumë të rëndësishme jofunksionale për vonesë dhe/ose xhiro, atëherë mund të jetë më mirë të konsideroni një opsion tjetër vendosjeje.

Burimi: www.habr.com