Ar Kafka „Kubernetes“ gera?

Sveikinimai, Habr!

Vienu metu mes pirmieji pristatėme temą Rusijos rinkai Kafka ir tęskite takelis jo plėtrai. Visų pirma, mes radome Kafkos ir sąveikos temą Kubernetes. Pastebimas (ir gana atsargus) straipsnis ši tema buvo paskelbta „Confluent“ tinklaraštyje praėjusių metų spalį, autorė Gwen Shapira. Šiandien norime atkreipti jūsų dėmesį į naujesnį balandžio mėnesio Johanno Gygerio straipsnį, kuris, nors ir be klaustuko pavadinime, temą nagrinėja iš esmės, tekstą palydi įdomiomis nuorodomis. Jei galite, atleiskite mums už nemokamą „chaoso beždžionės“ vertimą!

įvedimas

„Kubernetes“ sukurta dirbti be būsenos darbo krūvius. Paprastai tokie darbo krūviai pateikiami mikroservisų architektūros forma, jie yra lengvi, gerai mastomi horizontaliai, atitinka 12 faktorių taikomųjų programų principus, gali dirbti su grandinės pertraukikliais ir chaoso beždžionėmis.

Kita vertus, Kafka iš esmės veikia kaip paskirstyta duomenų bazė. Taigi dirbant tenka susidurti su valstybe, o tai yra daug sunkesnė už mikropaslaugą. „Kubernetes“ palaiko būsenos apkrovas, tačiau, kaip Kelsey Hightower nurodo dviejuose „Twitter“ pranešimuose, su jais reikia elgtis atsargiai:

Kai kurie žmonės mano, kad jei „Kubernetes“ įvesite į būsenos darbo krūvį, ji taps visiškai valdoma duomenų baze, kuri konkuruoja su RDS. Tai yra blogai. Galbūt, jei pakankamai sunkiai dirbsite, pridėsite papildomų komponentų ir pritrauksite SRE inžinierių komandą, galėsite sukurti RDS ant Kubernetes.

Aš visada rekomenduoju visiems būti ypač atsargiems, kai „Kubernetes“ atlieka būsenos darbo krūvius. Dauguma žmonių, kurie klausia „ar galiu vykdyti būseną nustatančius darbo krūvius Kubernetes“, neturi pakankamai patirties su „Kubernetes“, o dažnai ir su darbo krūviu, apie kurį jie klausia.

Taigi, ar turėtumėte paleisti Kafka „Kubernetes“? Priešingas klausimas: ar Kafka veiks geriau be Kubernetes? Štai kodėl šiame straipsnyje noriu pabrėžti, kaip Kafka ir Kubernetes papildo vienas kitą ir kokių spąstų gali kilti juos derinant.

Baigimo laikas

Pakalbėkime apie pagrindinį dalyką – pačią vykdymo aplinką

procesas

Kafka brokeriai yra draugiški procesoriams. TLS gali sukelti papildomų išlaidų. Tačiau „Kafka“ klientai gali naudoti daugiau procesoriaus, jei naudoja šifravimą, tačiau tai neturi įtakos brokeriams.

atmintis

Kafka brokeriai valgo atmintį. JVM krūvos dydis paprastai ribojamas iki 4–5 GB, tačiau jums taip pat reikės daug sistemos atminties, nes „Kafka“ labai intensyviai naudoja puslapio talpyklą. „Kubernetes“ nustatykite konteinerio išteklius ir atitinkamai užklausų apribojimus.

Duomenų saugykla

Duomenų saugojimas konteineriuose yra trumpalaikis – duomenys prarandami paleidus iš naujo. Kafka duomenims galite naudoti tomą emptyDir, ir efektas bus panašus: baigus bus prarasti brokerio duomenys. Jūsų pranešimai vis tiek gali būti saugomi kituose brokeriuose kaip kopijos. Todėl po perkrovimo nesėkmingas brokeris pirmiausia turi pakartoti visus duomenis, o šis procesas gali užtrukti daug laiko.

Štai kodėl turėtumėte naudoti ilgalaikį duomenų saugojimą. Tebūnie tai nevietinis ilgalaikis saugojimas su XFS failų sistema arba, tiksliau, ext4. Nenaudokite NFS. Aš tave įspėjau. NFS versijos v3 arba v4 neveiks. Trumpai tariant, „Kafka“ brokeris sugenda, jei negalės ištrinti duomenų katalogo dėl „kvailos pervadinimo“ problemos NFS. Jeigu aš tavęs dar neįtikinau, tai labai atsargiai perskaitykite šį straipsnį. Duomenų saugykla turėtų būti ne lokali, kad „Kubernetes“ galėtų lanksčiau pasirinkti naują mazgą po pakartotinio paleidimo ar perkėlimo.

Tinklas

Kaip ir daugumos paskirstytų sistemų, „Kafka“ našumas labai priklauso nuo to, ar tinklo delsa bus minimali ir pralaidumas būtų maksimalus. Nebandykite priglobti visų brokerių tame pačiame mazge, nes tai sumažins pasiekiamumą. Jei Kubernetes mazgas sugenda, suges visas Kafka klasteris. Be to, neišsklaidykite Kafka klasterio visuose duomenų centruose. Tas pats pasakytina apie „Kubernetes“ klasterį. Geras kompromisas šiuo atveju – pasirinkti skirtingas prieinamumo zonas.

Konfigūravimas

Reguliarūs manifestai

Kubernetes svetainė turi labai geras vadovas apie tai, kaip sukonfigūruoti „ZooKeeper“ naudojant manifestus. Kadangi „ZooKeeper“ yra „Kafka“ dalis, tai yra gera vieta pradėti susipažinti su „Kubernetes“ koncepcijomis. Kai tai suprasite, galėsite naudoti tas pačias sąvokas su Kafka klasteris.

• po: Pod yra mažiausias dislokuotinas Kubernetes vienetas. Grupėje yra jūsų darbo krūvis, o pati grupė atitinka procesą jūsų grupėje. Ankštyje yra vienas ar daugiau talpyklų. Kiekvienas „ZooKeeper“ serveris ansamblyje ir kiekvienas „Kafka“ klasterio brokeris veiks atskirame bloke.
• StatefulSet: „StatefulSet“ yra „Kubernetes“ objektas, kuris tvarko kelis būsenos darbo krūvius, todėl tokie darbo krūviai reikalauja derinimo. StatefulSets suteikia garantijas dėl ankščių užsakymo ir jų unikalumo.
• Paslaugos be galvos: paslaugos leidžia atskirti blokus nuo klientų naudojant loginį pavadinimą. Kubernetes šiuo atveju yra atsakinga už apkrovos balansavimą. Tačiau, kai naudojate būsenos darbo krūvius, pvz., „ZooKeeper“ ir „Kafka“, klientai turi susisiekti su konkrečiu atveju. Čia praverčia paslaugos be galvos: tokiu atveju klientas vis tiek turės logišką pavadinimą, tačiau jums nereikės tiesiogiai susisiekti su podeliu.
• Ilgalaikio saugojimo tūris: Šie tomai reikalingi anksčiau minėtai ne vietinio bloko nuolatinei saugyklai sukonfigūruoti.

Apie Yolean Pateikiamas išsamus aprašų rinkinys, padėsiantis pradėti dirbti su Kafka „Kubernetes“.

Vairo diagramos

„Helm“ yra „Kubernetes“ paketų tvarkyklė, kurią galima palyginti su OS paketų tvarkytuvais, tokiais kaip „yum“, „apt“, „Homebrew“ ar „Chocolatey“. Tai leidžia lengvai įdiegti iš anksto nustatytus programinės įrangos paketus, aprašytus Helm diagramose. Gerai parinkta Helm diagrama palengvina sudėtingą užduotį, kaip tinkamai sukonfigūruoti visus parametrus, kad būtų galima naudoti Kafka „Kubernetes“. Yra kelios Kafkos diagramos: oficiali yra inkubatoriaus būklės, yra vienas iš Konfidenciali, dar vienas – iš BitNami.

Operatoriai

Kadangi Helm turi tam tikrų trūkumų, nemažą populiarumą sulaukia dar vienas įrankis – Kubernetes operatoriai. Operatorius ne tik pakuoja programinę įrangą Kubernetes, bet ir leidžia tokią programinę įrangą diegti bei ją valdyti.

Sąraše nuostabūs operatoriai Minimi du Kafkos operatoriai. Vienas iš jų - Strimzi. Su Strimzi lengva sukurti ir paleisti Kafka grupę per kelias minutes. Praktiškai nereikia konfigūruoti, be to, pats operatorius suteikia keletą malonių funkcijų, pavyzdžiui, TLS šifravimas nuo taško iki taško klasteryje. Confluentas taip pat numato nuosavas operatorius.

Našumas

Svarbu patikrinti našumą palyginus savo Kafka egzempliorių. Tokie testai padės jums rasti galimas kliūtis prieš atsirandant problemoms. Laimei, Kafka jau pateikia du našumo testavimo įrankius: kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. Aktyviai naudokite juos. Norėdami gauti informacijos, galite peržiūrėti rezultatus, aprašytus šis įrašas Jay Kreps, arba sutelkite dėmesį į šią apžvalgą „Amazon MSK“, autorius Stéphane'as Maarekas.

Operacijos

Stebėjimas

Skaidrumas sistemoje labai svarbus – kitaip nesuprasi, kas joje vyksta. Šiandien yra patikimas įrankių rinkinys, teikiantis metrika pagrįstą stebėjimą debesies savuoju stiliumi. Du populiarūs įrankiai šiam tikslui yra Prometheus ir Grafana. Prometheus gali rinkti visų Java procesų metrikas (Kafka, Zookeeper, Kafka Connect) naudodamas JMX eksportuotoją – paprasčiausiu būdu. Jei pridėsite cAdvisor metriką, galėsite geriau suprasti, kaip ištekliai naudojami Kubernetes.

„Strimzi“ turi labai patogų „Grafana“ prietaisų skydelio pavyzdį, skirtą „Kafka“. Tai vizualizuoja pagrindinę metriką, pavyzdžiui, apie nepakankamai atkartojamus sektorius arba tuos, kurie yra neprisijungę. Ten viskas labai aišku. Šias metrikas papildo išteklių panaudojimo ir našumo informacija, taip pat stabilumo rodikliai. Taigi jūs gaunate pagrindinį Kafka klasterio stebėjimą už dyką!

Šaltinis: streamzi.io/docs/master/#kafka_dashboard

Būtų gerai visa tai papildyti klientų stebėjimu (vartotojų ir gamintojų metrika), taip pat delsos stebėjimu (tam yra Burzas) ir stebėjimas nuo galo iki galo – šiam naudojimui Kafka monitorius.

Miško ruoša

Dar viena svarbi užduotis yra registravimas. Įsitikinkite, kad visi „Kafka“ diegimo konteineriai yra prisijungę stdout и stderr, taip pat įsitikinkite, kad jūsų „Kubernetes“ klasteris sujungia visus žurnalus į centrinę registravimo infrastruktūrą, pvz. Elasticearch.

Funkcinis testavimas

„Kubernetes“ naudoja gyvumo ir parengties zondus, kad patikrintų, ar jūsų ankštys veikia normaliai. Jei gyvumo patikra nepavyks, „Kubernetes“ sustabdys tą konteinerį ir automatiškai paleis jį iš naujo, jei bus atitinkamai nustatyta pakartotinio paleidimo politika. Jei pasirengimo patikra nepavyksta, „Kubernetes“ izoliuoja bloką nuo aptarnavimo užklausų. Taigi tokiais atvejais rankinio įsikišimo visiškai nebereikia, o tai yra didelis pliusas.

Išleidžiami naujinimai

„StatefulSets“ palaiko automatinius naujinimus: jei pasirinksite „RollingUpdate“ strategiją, kiekvienas iš „Kafka“ bus atnaujintas paeiliui. Tokiu būdu prastovos laikas gali būti sumažintas iki nulio.

Mastelio keitimas

Kafkos klasterio mastelis nėra lengva užduotis. Tačiau „Kubernetes“ leidžia labai lengvai pritaikyti priedus iki tam tikro kopijų skaičiaus, o tai reiškia, kad galite deklaratyviai apibrėžti tiek „Kafka“ brokerių, kiek norite. Sunkiausias dalykas šiuo atveju yra perskirstyti sektorius padidinus mastelį arba prieš sumažinant mastelį. Vėlgi, Kubernetes padės jums atlikti šią užduotį.

Administravimas

Užduotys, susijusios su Kafka klasterio administravimu, pvz., temų kūrimas ir sektorių perskirstymas, gali būti atliekamos naudojant esamus apvalkalo scenarijus atidarius komandų eilutės sąsają savo ankštyse. Tačiau šis sprendimas nėra labai gražus. Strimzi palaiko temų valdymą naudojant kitą operatorių. Čia yra kur tobulėti.

Резервное копирование ir восстановление

Dabar „Kafka“ prieinamumas taip pat priklausys nuo „Kubernetes“ prieinamumo. Jei jūsų „Kubernetes“ klasteris sugenda, blogiausiu atveju suges ir „Kafka“ klasteris. Pagal Merfio dėsnį tai tikrai įvyks, ir jūs prarasite duomenis. Norėdami sumažinti tokio tipo riziką, turėkite gerą atsarginės kopijos koncepciją. Galite naudoti MirrorMaker, kita galimybė yra naudoti S3, kaip aprašyta čia paštu iš Zalando.

išvada

Dirbant su mažomis ir vidutinio dydžio Kafka klasteriais tikrai verta naudoti Kubernetes, nes tai suteikia papildomo lankstumo ir supaprastina operatoriaus patirtį. Jei turite labai didelių nefunkcinių delsos ir (arba) pralaidumo reikalavimų, gali būti geriau apsvarstyti kitą diegimo parinktį.

Šaltinis: www.habr.com