Ĉu Kafka sur Kubernetes estas bona?

Saluton, Habr!

Iam ni estis la unuaj enkonduki la temon al la rusa merkato Kafka kaj daŭrigu trako por ĝia evoluo. Precipe ni trovis la temon de interago inter Kafka kaj Kubernetoj. Observebla (kaj sufiĉe zorgema) artikolo ĉi tiu temo estis publikigita en la blogo Confluent en oktobro de la pasinta jaro sub la aŭtoreco de Gwen Shapira. Hodiaŭ ni ŝatus atentigi vin pri pli freŝa artikolo el aprilo de Johann Gyger, kiu, kvankam ne sen demandosigno en la titolo, ekzamenas la temon pli substantive, akompanante la tekston per interesaj ligiloj. Bonvolu pardoni al ni la senpagan tradukon de "kaosa simio" se vi povas!

Enkonduko

Kubernetes estas dizajnita por trakti sennaciajn laborŝarĝojn. Tipe, tiaj laborŝarĝoj estas prezentitaj en la formo de mikroserva arkitekturo, ili estas malpezaj, skalas bone horizontale, sekvas la principojn de 12-faktoraj aplikoj, kaj povas labori kun interrompiloj kaj kaosaj simioj.

Kafka, aliflanke, esence funkcias kiel distribuita datumbazo. Tiel, kiam vi laboras, vi devas trakti ŝtaton, kaj ĝi estas multe pli peza ol mikroservo. Kubernetes subtenas ŝtatajn ŝarĝojn, sed kiel Kelsey Hightower rimarkas en du tweets, ili devas esti pritraktataj zorge:

Iuj homoj opinias, ke se vi ruliĝas Kubernetes en ŝtatan laborŝarĝon, ĝi fariĝas plene administrita datumbazo, kiu konkuras kun RDS. Ĉi tio estas malĝusta. Eble, se vi sufiĉe laboras, aldonas pliajn komponantojn kaj altiros teamon de SRE-inĝenieroj, vi povos konstrui RDS sur Kubernetes.

Mi ĉiam rekomendas, ke ĉiuj ekzercu ekstreman singardon dum kurado de ŝtataj laborŝarĝoj sur Kubernetes. Plej multaj homoj, kiuj demandas "ĉu mi povas ruli ŝtatajn laborŝarĝojn sur Kubernetes", ne havas sufiĉe da sperto kun Kubernetes, kaj ofte kun la laborkvanto pri kiu ili demandas.

Do, ĉu vi rulu Kafka sur Kubernetes? Kontraŭdemando: ĉu Kafka funkcios pli bone sen Kubernetes? Tial mi volas reliefigi en ĉi tiu artikolo kiel Kafka kaj Kubernetes kompletigas unu la alian, kaj kiajn malfacilaĵojn povas veni kun kombini ilin.

Tempo de kompletigo

Ni parolu pri la baza afero - la rultempa medio mem

procezo

Kafka makleristoj estas CPU-amika. TLS povas enkonduki iom da superkosto. Tamen, Kafka klientoj povas esti pli CPU-intensaj se ili uzas ĉifradon, sed ĉi tio ne influas makleristojn.

memoro

Kafka makleristoj manĝas memoron. La amaso de JVM estas kutime limigita al 4-5 GB, sed vi ankaŭ bezonos multan sisteman memoron ĉar Kafka tre peze uzas la paĝan kaŝmemoron. En Kubernetes, starigu ujo-rimedon kaj petu limojn laŭe.

Datuma butiko

Datumstokado en ujoj estas efemera - datumoj perdiĝas kiam rekomencita. Por Kafka-datumoj vi povas uzi volumon emptyDir, kaj la efiko estos simila: viaj makleristaj datumoj perdiĝos post kompletigo. Viaj mesaĝoj ankoraŭ povas esti konservitaj ĉe aliaj makleristoj kiel kopioj. Sekve, post rekomenco, la malsukcesa broker unue devas reprodukti ĉiujn datumojn, kaj ĉi tiu procezo povas preni multan tempon.

Jen kial vi devus uzi longtempan datumstokadon. Estu ne-loka longdaŭra stokado kun la XFS-dosiersistemo aŭ, pli precize, ext4. Ne uzu NFS. Mi avertis vin. NFS-versioj v3 aŭ v4 ne funkcios. Mallonge, la Kafka makleristo kraŝos se ĝi ne povas forigi la datuman dosierujon pro la problemo de "stulta renomo" en NFS. Se mi ankoraŭ ne konvinkis vin, tre zorge legu ĉi tiun artikolon. La datumbutiko devus esti ne-loka por ke Kubernetes povu pli flekseble elekti novan nodon post rekomenco aŭ translokiĝo.

Reto

Kiel ĉe la plej multaj distribuitaj sistemoj, la agado de Kafka tre dependas de konservado de reto latenteco al minimumo kaj bendolarĝo al la maksimumo. Ne provu gastigi ĉiujn makleristojn sur la sama nodo, ĉar ĉi tio reduktos haveblecon. Se Kubernetes-nodo malsukcesos, la tuta Kafka areto malsukcesos. Ankaŭ ne disigu la Kafka-areton tra tutaj datumcentroj. La sama validas por la Kubernetes-areto. Bona kompromiso en ĉi tiu kazo estas elekti malsamajn havebleczonojn.

Agordo

Regulaj manifestoj

La retejo de Kubernetes havas tre bona gvidilo pri kiel agordi ZooKeeper uzante manifestojn. Ĉar ZooKeeper estas parto de Kafka, ĉi tio estas bona loko por komenci konatiĝi kun kiuj Kubernetes-konceptoj validas ĉi tie. Post kiam vi komprenas ĉi tion, vi povas uzi la samajn konceptojn kun Kafka-grupo.

• Sub: Pod estas la plej malgranda deplojebla unuo en Kubernetes. Pod enhavas vian laborŝarĝon, kaj la pod mem respondas al procezo en via areto. Pod enhavas unu aŭ plurajn ujojn. Ĉiu ZooKeeper-servilo en la ensemblo kaj ĉiu makleristo en la Kafka areto funkcios en aparta podo.
• StatefulSet: StatefulSet estas Kubernetes-objekto, kiu pritraktas multoblajn ŝtatajn laborŝarĝojn, kaj tiaj laborŝarĝoj postulas kunordigon. StatefulSets provizas garantiojn pri la mendado de balgoj kaj ilia unikeco.
• Senkapaj servoj: Servoj permesas al vi malligi podojn de klientoj uzante logikan nomon. Kubernetes en ĉi tiu kazo respondecas pri ŝarĝoekvilibro. Tamen, kiam funkciigas ŝtatajn laborŝarĝojn, kiel ekzemple ZooKeeper kaj Kafka, klientoj devas komuniki kun specifa kazo. Jen kie senkapaj servoj utilas: en ĉi tiu kazo, la kliento ankoraŭ havos logikan nomon, sed vi ne devos rekte kontakti la podon.
• Longtempa stokado-volumo: Ĉi tiuj volumoj estas bezonataj por agordi la ne-lokan blokan konstantan stokadon menciitan supre.

En Yolean Provizas ampleksan aron da manifestoj por helpi vin komenci kun Kafka en Kubernetes.

Helm-diagramoj

Helm estas pakaĵmanaĝero por Kubernetes, kiu povas esti komparita kun OS-pakadministrantoj kiel ekzemple yum, apt, Homebrew aŭ Chocolatey. Ĝi faciligas instali antaŭdifinitajn programarpakaĵojn priskribitajn en Helm-diagramoj. Bone elektita Helm-diagramo faciligas la malfacilan taskon kiel ĝuste agordi ĉiujn parametrojn por uzi Kafka ĉe Kubernetes. Estas pluraj Kafka diagramoj: la oficiala troviĝas en inkubatora stato, estas unu el Konflikto, unu pli - de Bitnami.

Telefonistoj

Ĉar Helm havas certajn mankojn, alia ilo akiras konsiderindan popularecon: Kubernetes-funkciigistoj. La funkciigisto ne nur pakas programaron por Kubernetes, sed ankaŭ permesas vin disfaldi tian programaron kaj administri ĝin.

En la listo mirindaj operatoroj Du funkciigistoj por Kafka estas menciitaj. Unu el ili - Strimzi. Kun Strimzi, estas facile ekfunkciigi vian Kafka-grupon en minutoj. Preskaŭ neniu agordo estas bezonata, krome, la funkciigisto mem provizas kelkajn belajn funkciojn, ekzemple, punkto-al-punkta TLS-ĉifrado ene de la areto. Confluent ankaŭ provizas propra operatoro.

Produkteco

Gravas testi agadon per benchmarking de via Kafka-instanco. Tiaj provoj helpos vin trovi eblajn botelojn antaŭ ol problemoj okazas. Feliĉe, Kafka jam provizas du rezultajn testajn ilojn: kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. Aktive uzu ilin. Por referenco, vi povas raporti al la rezultoj priskribitaj en ĉi tiu afiŝo Jay Kreps, aŭ koncentri sur ĉi tiu recenzo Amazon MSK de Stéphane Maarek.

Operacioj

Monitorado

Travidebleco en la sistemo estas tre grava - alie vi ne komprenos, kio okazas en ĝi. Hodiaŭ ekzistas solida ilaro, kiu disponigas metrik-bazitan monitoradon en la nuba indiĝena stilo. Du popularaj iloj por ĉi tiu celo estas Prometheus kaj Grafana. Prometheus povas kolekti metrikojn de ĉiuj Java-procezoj (Kafka, Zookeeper, Kafka Connect) uzante JMX-eksportilon - en la plej simpla maniero. Se vi aldonas cAdvisor-metrikojn, vi povas pli plene kompreni kiel rimedoj estas uzataj en Kubernetes.

Strimzi havas tre oportunan ekzemplon de Grafana panelo por Kafka. Ĝi bildigas ŝlosilajn metrikojn, ekzemple, pri subreproduktitaj sektoroj aŭ tiuj, kiuj estas eksterrete. Ĉio estas tre klara tie. Ĉi tiuj metrikoj estas kompletigitaj per informoj pri uzado de rimedoj kaj agado, same kiel indikiloj de stabileco. Do vi ricevas bazan Kafka-grupon monitoradon por nenio!

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

Estus bone kompletigi ĉion ĉi per klientmonitorado (metriko pri konsumantoj kaj produktantoj), same kiel latenta monitorado (por tio ekzistas Burrow) kaj fin-al-fina monitorado - por tiu ĉi uzo Kafka Monitoro.

Enhavo

Registrado estas alia kritika tasko. Certigu, ke ĉiuj ujoj en via Kafka-instalaĵo estas ensalutitaj stdout и stderr, kaj ankaŭ certigu, ke via Kubernetes-areto kunigas ĉiujn protokolojn en centran registran infrastrukturon, ekz. Elasta esploro.

Funkcia Atesto

Kubernetes uzas sondilojn pri viveco kaj preteco por kontroli ĉu viaj podoj funkcias normale. Se la vivkontrolo malsukcesas, Kubernetes haltigos tiun ujon kaj poste aŭtomate rekomencos ĝin se la rekomencpolitiko estas agordita laŭe. Se la preteca kontrolo malsukcesas, Kubernetes izolas la pod de servado de petoj. Tiel, en tiaj kazoj, mana interveno tute ne plu necesas, kio estas granda pluso.

Disvolviĝo de ĝisdatigoj

StatefulSets subtenas aŭtomatajn ĝisdatigojn: se vi elektas la RollingUpdate-strategion, ĉiu sub Kafka estos ĝisdatigita laŭvice. Tiamaniere, malfunkcio povas esti reduktita al nulo.

Skalo

Skali Kafka areton ne estas facila tasko. Tamen, Kubernetes tre facilas grimpi podojn al certa nombro da kopioj, kio signifas, ke vi povas deklara difini tiom da Kafka makleristoj kiel vi volas. La plej malfacila afero en ĉi tiu kazo estas reasigni sektorojn post pligrandigo aŭ antaŭ malpligrandigo. Denove, Kubernetes helpos vin kun ĉi tiu tasko.

Administrado

Taskoj rilataj al administrado de via Kafka-grupo, kiel krei temojn kaj reasigni sektorojn, povas esti faritaj uzante ekzistantajn ŝelajn skriptojn malfermante la komandlinian interfacon en viaj podoj. Tamen ĉi tiu solvo ne estas tre bela. Strimzi subtenas administri temojn uzante malsaman funkciigiston. Estas iom da loko por plibonigo ĉi tie.

Sekurkopio kaj restarigo

Nun la havebleco de Kafka ankaŭ dependos de la havebleco de Kubernetes. Se via Kubernetes-areto malsukcesas, tiam en la plej malbona kazo, via Kafka-areto ankaŭ malsukcesos. Laŭ la leĝo de Murphy, ĉi tio certe okazos, kaj vi perdos datumojn. Por redukti ĉi tiun tipon de risko, havu bonan rezervan koncepton. Vi povas uzi MirrorMaker, alia opcio estas uzi S3 por ĉi tio, kiel priskribite en ĉi tio afiŝi el Zalando.

konkludo

Kiam vi laboras kun malgrandaj ĝis mezgrandaj Kafka-aretoj, certe indas uzi Kubernetes ĉar ĝi provizas plian flekseblecon kaj simpligas la sperton de operaciisto. Se vi havas tre signifajn nefunkciajn latentecon kaj/aŭ traigajn postulojn, tiam eble estos pli bone konsideri iun alian deplojan opcion.

fonto: www.habr.com