Sveikinimai, Habr!
Vienu metu mes pirmieji pristatėme temą Rusijos rinkai
į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
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
- 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
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
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
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
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:
Būtų gerai visa tai papildyti klientų stebėjimu (vartotojų ir gamintojų metrika), taip pat delsos stebėjimu (tam yra
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.
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
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