Ona al da Kafka Kubernetes-en?

Zorionak, Habr!

Garai batean, gaia Errusiako merkatuan sartzen lehenak izan ginen Kafka eta jarraitu pista bere garapenerako. Bereziki, Kafkaren eta elkarrekintzaren gaia aurkitu dugu Kubernetes. Behagarria (eta nahiko kontuz) artikuluan gai hau Confluent blogean argitaratu zen iazko urrian, Gwen Shapiraren egiletzapean. Gaurkoan, Johann Gygerrek apirileko artikulu berri bati eman nahi dizuegu arreta, zeinak, izenburuan galdera-ikurrik gabe egon ez arren, gaia modu mamitsuago batean aztertzen baitu, testuari esteka interesgarriekin batera. Mesedez, barka iezaguzu "kaosaren tximinoa"ren doako itzulpena ahal baduzu!

Sarrera

Kubernetes estaturik gabeko lan-kargak kudeatzeko diseinatuta dago. Normalean, horrelako lan-kargak mikrozerbitzuen arkitektura moduan aurkezten dira, arinak dira, horizontalki ondo eskalatzen dira, 12 faktoreko aplikazioen printzipioak jarraitzen dituzte eta etengailuekin eta kaos tximinoekin lan egin dezakete.

Kafkak, berriz, funtsean datu-base banatu gisa jokatzen du. Horrela, lanean ari zarenean, egoerari aurre egin behar diozu, eta mikrozerbitzu bat baino askoz astunagoa da. Kubernetes-ek egoera-kargak onartzen ditu, baina Kelsey Hightower-ek bi txiotan adierazi duenez, kontu handiz kudeatu behar dira:

Batzuek uste dute Kubernetes lan-karga egoera batera eramaten baduzu, RDSren aurka dagoen guztiz kudeatutako datu-base bat bihurtzen dela. Hau gaizki dago. Agian, nahikoa lan egiten baduzu, osagai osagarriak gehitu eta SRE ingeniari talde bat erakartzen baduzu, Kubernetesen gainean RDS eraikitzeko gai izango zara.

Beti gomendatzen dut denei kontu handia izatea Kubernetesen lan-karga egoerak exekutatzen direnean. "Kubernetesen egoera-kargak exekutatu al ditzaket" galdetzen duten gehienek ez dute Kubernetes-ekin behar adina esperientzia, eta askotan galdetzen ari diren lan-kargarekin.

Beraz, Kafka exekutatu beharko zenuke Kubernetes-en? Kontrako galdera: hobeto funtzionatuko al du Kafkak Kubernetes gabe? Horregatik nabarmendu nahi dut artikulu honetan Kafka eta Kubernetes nola osatzen diren elkarren artean, eta horiek konbinatzeak zer arrisku ekar ditzakeen.

Amaitzeko ordua

Hitz egin dezagun oinarrizko gauzari buruz: exekuzio-inguruneari berari

Prozesu

Kafka artekariek CPU errespetatzen dute. TLS-k gainkostu batzuk sor ditzake. Hala ere, Kafka bezeroek PUZ intentsiboagoak izan daitezke enkriptatzea erabiltzen badute, baina horrek ez die eraginik artekariei.

Память

Kafka artekariek memoria jaten dute. JVM-ren pila-tamaina 4-5 GB-ra mugatzen da normalean, baina sistemaren memoria asko ere beharko duzu Kafkak orrialde-cachea oso asko erabiltzen baitu. Kubernetesen, ezarri edukiontzien baliabidea eta eskatu mugak horren arabera.

Datu biltegia

Datuak edukiontzietan biltegiratzea iragankorra da - berrabiaraztean datuak galtzen dira. Kafka datuetarako bolumen bat erabil dezakezu emptyDir, eta efektua antzekoa izango da: zure brokerren datuak amaitu ondoren galduko dira. Zure mezuak beste bitartekari batzuetan gorde daitezke oraindik erreplika gisa. Hori dela eta, berrabiarazi ondoren, huts egin duen artekariak lehenik eta behin datu guztiak errepikatu behar ditu, eta prozesu honek denbora asko iraun dezake.

Horregatik, epe luzerako datu biltegiratzea erabili beharko zenuke. Epe luzerako biltegiratzea ez den tokikoa izan dadila XFS fitxategi-sistemarekin edo, zehatzago, ext4. Ez erabili NFS. ohartarazi dizut. NFS v3 edo v4 bertsioek ez dute funtzionatuko. Laburbilduz, Kafka broker-ak huts egingo du datu-direktorioa ezabatu ezin badu NFS-ko "izen-izen ergel" arazoa dela eta. Oraindik konbentzitu ez bazaitut, kontu handiz irakurri artikulu hau. Datu biltegiak tokikoa ez den izan behar du, Kubernetes-ek berrabiarazi edo lekuz aldatu ondoren nodo berri bat malguagoa izan dezan.

Sarea

Banatutako sistema gehienekin gertatzen den bezala, Kafkaren errendimendua sarearen latentzia minimoa eta banda zabalera ahalik eta gehien mantentzearen mende dago. Ez saiatu artekari guztiak nodo berean hartzen, horrek erabilgarritasuna murriztuko baitu. Kubernetes nodo batek huts egiten badu, Kafka kluster osoak huts egingo du. Gainera, ez sakabanatu Kafka klusterra datu-zentro osoetan. Gauza bera gertatzen da Kubernetes klusterrekin. Konpromiso ona kasu honetan erabilgarritasun-gune desberdinak aukeratzea da.

konfigurazioa

Ohiko manifestuak

Kubernetes webguneak badu oso gida ona ZooKeeper manifestuak erabiliz konfiguratzeko moduari buruz. ZooKeeper Kafkaren parte denez, hemen Kubernetes kontzeptuak aplikatzen diren ezagutzen hasteko leku ona da. Hau ulertu ondoren, kontzeptu berdinak erabil ditzakezu Kafka kluster batekin.

• azpian: Pod bat Kubernetes-en zabal daitekeen unitate txikiena da. Pod batek zure lan-karga dauka, eta poda bera zure klusterreko prozesu bati dagokio. Lekak ontzi bat edo gehiago ditu. Multzoko ZooKeeper zerbitzari bakoitza eta Kafka klusterreko broker bakoitza pod bereizi batean exekutatuko dira.
• StatefulSet: StatefulSet egoera-karga anitz kudeatzen dituen Kubernetes objektu bat da, eta lan-karga horiek koordinazioa behar dute. StatefulSets-ek bermeak eskaintzen ditu lekak ordenatzeari eta haien berezitasunari buruz.
• Bururik gabeko zerbitzuak: Zerbitzuek aukera ematen dizute pods-ak bezeroetatik bereizteko izen logiko bat erabiliz. Kasu honetan Kubernetes arduratzen da karga orekatzeaz. Hala ere, egoera-kargak funtzionatzen dituztenean, adibidez, ZooKeeper eta Kafka, bezeroek instantzia zehatz batekin komunikatu behar dute. Hona hemen bururik gabeko zerbitzuak: kasu honetan, bezeroak izen logiko bat izango du oraindik, baina ez duzu podarekin zuzenean harremanetan jarri beharko.
• Epe luzerako biltegiratze bolumena: Bolumen hauek beharrezkoak dira goian aipatutako bloke iraunkorreko biltegiratze lokala konfiguratzeko.

On Yolean Kubernetes-en Kafka-rekin hasten laguntzeko manifestuen multzo osoa eskaintzen du.

Helm taulak

Helm Kubernetes baterako pakete kudeatzailea da, eta sistema eragilearen paketeen kudeatzaileekin alderatu daiteke, hala nola yum, apt, Homebrew edo Chocolatey. Helm zerrendetan deskribatutako aurrez definitutako software paketeak instalatzea errazten du. Ondo aukeratutako Helm diagramak errazten du Kubernetes-en Kafka erabiltzeko parametro guztiak behar bezala konfiguratzeko lan zaila. Hainbat Kafka diagrama daude: ofiziala kokatzen da inkubagailu egoeran, bada bat confluent, bat gehiago --tik Bitnami.

Operadore

Helm-ek zenbait gabezia dituenez, beste tresna bat ospe handia lortzen ari da: Kubernetes-eko operadoreak. Operadoreak Kubernetes-erako softwarea paketatzeaz gain, software hori zabaldu eta kudeatzeko aukera ere ematen dizu.

Zerrendan operadore harrigarriak Kafkaren bi operadore aipatzen dira. Haietako bat - Strimzi. Strimzi-rekin, erraza da zure Kafka klusterra minutu batzuetan martxan jartzea. Ia ez da konfiguraziorik behar, gainera, operadoreak berak ezaugarri polit batzuk eskaintzen ditu, adibidez, puntuz puntu TLS enkriptatzea kluster barruan. Confluent-ek ere ematen du operadore propioa.

produktibitatea

Garrantzitsua da errendimendua probatzea zure Kafka instantzia erreferentzia eginez. Proba horiek arazoak sortu aurretik potentzial oztopoak aurkitzen lagunduko dizute. Zorionez, Kafkak dagoeneko bi errendimendua probatzeko tresna eskaintzen ditu: kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. Erabili horiek aktiboki. Erreferentzia gisa, atalean deskribatutako emaitzak ikus ditzakezu mezu hau Jay Kreps, edo zentratu berrikuspen hau Stéphane Maarek-en Amazon MSK.

operazioak

jarraipenaren

Sistemaren gardentasuna oso garrantzitsua da; bestela, ez duzu ulertuko bertan gertatzen dena. Gaur egun, hodeiko jatorrizko estiloan metriketan oinarritutako monitorizazioa eskaintzen duen tresna-kit sendo bat dago. Horretarako bi tresna ezagun Prometheus eta Grafana dira. Prometheus-ek Java prozesu guztietako metrikak bil ditzake (Kafka, Zookeeper, Kafka Connect) JMX esportatzaile bat erabiliz, modu errazenean. cAdvisor neurriak gehitzen badituzu, Kubernetesen baliabideak nola erabiltzen diren hobeto uler dezakezu.

Strimzi-k Grafana panel baten adibide oso erosoa du Kafkarentzat. Funtsezko neurketak bistaratzen ditu, adibidez, gutxiegi errepikatutako sektoreei edo lineaz kanpo daudenei buruz. Han dena oso argi dago. Neurri hauek baliabideen erabileraren eta errendimenduaren informazioarekin osatzen dira, baita egonkortasun-adierazleekin ere. Beraz, Kafka klusterraren oinarrizko monitorizazioa lortzen duzu ezertarako!

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

Ondo legoke hori guztia bezeroen monitorizazioarekin (kontsumitzaile eta ekoizleen neurketak), baita latentziaren monitorizazioarekin ere (horretarako dago Burrow) eta amaierako monitorizazioa - erabilera honetarako Kafka monitorea.

Erregistratzea

Erregistratzea beste zeregin kritiko bat da. Ziurtatu zure Kafka instalazioko edukiontzi guztiak saioa hasita daudela stdout и stderr, eta ziurtatu zure Kubernetes klusterrak erregistro guztiak erregistro-azpiegitura zentral batean biltzen dituela, adibidez. Elasticsearch.

Proba funtzionala

Kubernetes-ek bizitasun- eta prestutasun-zundak erabiltzen ditu zure pod-ak normaltasunez funtzionatzen ari diren egiaztatzeko. Bizitasun-egiaztapenak huts egiten badu, Kubernetes-ek edukiontzi hori geldituko du eta, ondoren, automatikoki berrabiaraziko du berrabiarazi politika horren arabera ezartzen bada. Prestakuntza egiaztapenak huts egiten badu, Kubernetes-ek poda zerbitzu-eskaeretatik isolatzen du. Horrela, halakoetan, eskuzko esku-hartzea ez da batere behar, eta hori abantaila handia da.

Eguneratzeak zabaltzea

StatefulSets-ek eguneratze automatikoak onartzen ditu: RollingUpdate estrategia hautatzen baduzu, Kafkaren azpian bakoitza txandaka eguneratuko da. Horrela, geldialdi-denbora zerora murriztu daiteke.

Eskalatzea

Kafka kluster bat eskalatzea ez da lan erraza. Hala ere, Kubernetes-ek oso erraz egiten du pods erreplika kopuru jakin batera eskalatzea, eta horrek esan nahi du nahi adina Kafka artekari deklaratiboki defini ditzakezula. Kasu honetan zailena sektoreak eskalatu ondoren edo txikitu aurretik berriro esleitzea da. Berriz ere, Kubernetes-ek zeregin honetan lagunduko dizu.

Administrazioa

Zure Kafka cluster-a administratzearekin erlazionatutako zereginak, hala nola gaiak sortzea eta sektoreak berriro esleitzea, lehendik dauden shell script-ak erabiliz egin daitezke komando-lerroko interfazea irekiz zure podetan. Hala ere, irtenbide hau ez da oso polita. Strimzi gaiak beste operadore bat erabiliz kudeatzen onartzen du. Hemen badago zer hobetu.

Babeskopia egin eta leheneratu

Orain Kafkaren erabilgarritasuna Kubernetesen erabilgarritasunaren araberakoa izango da ere. Zure Kubernetes klusterrak huts egiten badu, kasurik txarrenean, zure Kafka klusterrak ere huts egingo du. Murphyren legearen arabera, hori gertatuko da zalantzarik gabe, eta datuak galduko dituzu. Arrisku mota hori murrizteko, eduki babeskopia-kontzeptu on bat. MirrorMaker erabil dezakezu, beste aukera bat S3 erabiltzea da, honetan deskribatzen den moduan mezua Zalandotik.

Ondorioa

Kafka kluster txiki eta ertainekin lan egiten duzunean, zalantzarik gabe, merezi du Kubernetes erabiltzea, malgutasun gehigarria eskaintzen baitu eta operadorearen esperientzia errazten baitu. Latentzia ez-funtzionala eta/edo errendimendu-eskakizun oso esanguratsuak badituzu, agian hobe izango da beste inplementazio aukeraren bat kontuan hartzea.

Iturria: www.habr.com