Kas Kafka on Kubernetes hea?

Tervitused, Habr!

Omal ajal olime esimesed, kes teemat Venemaa turule tutvustasid Kafka ja jätka järgi selle arendamiseks. Eelkõige leidsime teema Kafka ja Kubernetes. Jälgitav (ja üsna ettevaatlik) artikkel see teema avaldati Confluenti ajaveebis eelmise aasta oktoobris Gwen Shapira autorluse all. Täna juhime teie tähelepanu aprillikuu värskemale artiklile Johann Gygerilt, kes küll mitte ilma küsimärgita pealkirjas käsitleb teemat sisulisemalt, saates teksti huvitavate linkidega. Palun andke meile andeks vaba tõlge sõna "chaos monkey", kui saate!

Sissejuhatus

Kubernetes on loodud olekuta töökoormusega toimetulemiseks. Tavaliselt on sellised töökoormused esitatud mikroteenuste arhitektuuri kujul, need on kerged, hästi horisontaalselt mastaapsed, järgivad 12-faktoriliste rakenduste põhimõtteid ning võivad töötada kaitselülitite ja kaoseahvidega.

Kafka seevastu toimib sisuliselt hajutatud andmebaasina. Seega tuleb tööd tehes tegeleda olekuga ja see on palju raskem kui mikroteenus. Kubernetes toetab olekupõhiseid koormusi, kuid nagu Kelsey Hightower kahes säutsudes märgib, tuleks neid käsitleda ettevaatlikult:

Mõned inimesed arvavad, et kui lülitate Kubernetese olekupõhisesse töökoormusesse, muutub see täielikult hallatavaks andmebaasiks, mis konkureerib RDS-iga. See on vale. Kui teete piisavalt palju tööd, lisate täiendavaid komponente ja meelitate SRE inseneride meeskonna, saate Kubernetese peale ehitada RDS-i.

Soovitan alati kõigil Kubernetes olekupõhise töökoormuse käitamisel olla äärmise ettevaatlik. Enamikul inimestel, kes küsivad „kas ma saan Kubernetesis olekupõhiseid töökoormusi käivitada”, pole Kubernetesega piisavalt kogemusi ja sageli ka küsitava töökoormusega.

Niisiis, kas peaksite Kafkat Kubernetesis juhtima? Vastuküsimus: kas Kafka töötab paremini ilma Kubernetesita? Seetõttu tahan selles artiklis rõhutada, kuidas Kafka ja Kubernetes üksteist täiendavad ning milliseid lõkse võib nende kombineerimine kaasa tuua.

Valmimise aeg

Räägime põhiasjast – käituskeskkonnast endast

protsess

Kafka maaklerid on protsessorisõbralikud. TLS võib kaasa tuua mõningaid üldkulusid. Kuid Kafka kliendid võivad krüptimise korral olla protsessorimahukamad, kuid see ei mõjuta maaklereid.

mälu

Kafka maaklerid söövad mälu ära. JVM-i hunniku suurus on tavaliselt piiratud 4–5 GB-ga, kuid vajate ka palju süsteemimälu, kuna Kafka kasutab lehe vahemälu väga palju. Kuberneteses määrake konteineri ressurss ja päringu limiidid vastavalt.

Andmehoidla

Andmete salvestamine konteinerites on lühiajaline – taaskäivitamisel lähevad andmed kaotsi. Kafka andmete jaoks saate kasutada helitugevust emptyDir, ja mõju on sarnane: teie maakleri andmed lähevad pärast lõpetamist kaotsi. Teie sõnumeid saab endiselt koopiatena salvestada teistele vahendajatele. Seetõttu peab ebaõnnestunud maakler pärast taaskäivitamist esmalt kõik andmed kopeerima ja see protsess võib võtta palju aega.

Seetõttu peaksite kasutama pikaajalist andmesalvestust. Olgu selleks siis mittelokaalne pikaajaline salvestamine XFS-failisüsteemiga või täpsemalt ext4-ga. Ärge kasutage NFS-i. Ma hoiatasin sind. NFS-i versioonid v3 või v4 ei tööta. Lühidalt öeldes jookseb Kafka maakler kokku, kui ta ei saa NFS-i "rumala ümbernimetamise" probleemi tõttu andmekataloogi kustutada. Kui ma pole teid veel veennud, siis väga hoolikalt lugege seda artiklit. Andmesalv peaks olema mittelokaalne, et Kubernetes saaks pärast taaskäivitamist või ümberpaigutamist paindlikumalt valida uue sõlme.

Сеть

Nagu enamiku hajutatud süsteemide puhul, sõltub Kafka jõudlus suuresti sellest, kas võrgu latentsusaeg on minimaalne ja ribalaius on maksimaalne. Ärge püüdke majutada kõiki maaklereid samas sõlmes, kuna see vähendab saadavust. Kui Kubernetese sõlm ebaõnnestub, ebaõnnestub kogu Kafka klaster. Samuti ärge hajutage Kafka klastrit tervete andmekeskuste vahel. Sama kehtib ka Kubernetese klastri kohta. Hea kompromiss on sel juhul erinevate saadavustsoonide valimine.

Konfiguratsioon

Regulaarsed manifestid

Kubernetese veebisaidil on väga hea juhend kuidas konfigureerida ZooKeeperit manifestide abil. Kuna ZooKeeper on osa Kafkast, on see hea koht tutvumiseks sellega, millised Kubernetese kontseptsioonid siin kehtivad. Kui olete sellest aru saanud, saate samu mõisteid kasutada Kafka klastris.

• Alla: Pod on Kubernetese väikseim juurutav üksus. Pod sisaldab teie töökoormust ja pod ise vastab teie klastri protsessile. Kaun sisaldab ühte või mitut anumat. Iga ZooKeeperi server ansamblis ja iga maakler Kafka klastris töötavad eraldi kaustas.
• StatefulSet: StatefulSet on Kubernetese objekt, mis tegeleb mitme olekuga töökoormusega ja sellised töökoormused nõuavad kooskõlastamist. StatefulSets annab garantiid kaunade tellimise ja unikaalsuse osas.
• Peata teenused: Teenused võimaldavad teil loogilist nime kasutades eemaldada kaustad klientidelt. Kubernetes vastutab sel juhul koormuse tasakaalustamise eest. Olekupõhise töökoormuse (nt ZooKeeper ja Kafka) kasutamisel peavad kliendid aga suhtlema konkreetse eksemplariga. Siin tulevad kasuks peata teenused: sel juhul jääb kliendile ikkagi loogiline nimi, kuid te ei pea otse podiga ühendust võtma.
• Pikaajaline ladustamismaht: neid köiteid on vaja ülalmainitud mittekohaliku ploki püsiva salvestusruumi konfigureerimiseks.

Edasi Yolean Pakub laiaulatuslikku manifestide komplekti, mis aitavad teil Kubernetesis Kafka kasutamist alustada.

Helmi graafikud

Helm on Kubernetese paketihaldur, mida saab võrrelda OS-i paketihalduritega, nagu yum, apt, Homebrew või Chocolatey. See muudab Helmi diagrammides kirjeldatud eelmääratletud tarkvarapakettide installimise lihtsaks. Hästi valitud Helmi diagramm muudab keerulise ülesande, kuidas õigesti konfigureerida kõik parameetrid Kafka kasutamiseks Kubernetesis. Kafka diagramme on mitu: ametlik asub inkubaatori seisukorras, on üks alates Konfidentsiaalne, veel üks - alates Bitnami.

Ettevõtjad

Kuna Helmil on teatud puudused, kogub märkimisväärset populaarsust veel üks tööriist: Kubernetese operaatorid. Operaator mitte ainult ei paken Kubernetese jaoks tarkvara, vaid võimaldab teil ka sellist tarkvara juurutada ja hallata.

Loendis hämmastavad operaatorid Nimetatakse kahte Kafka operaatorit. Üks nendest - Strimzi. Strimzi abil on lihtne Kafka klastri minutitega tööle panna. Konfigureerimist pole praktiliselt vaja, lisaks pakub operaator ise mõningaid toredaid funktsioone, näiteks punkt-punkti TLS-krüptimist klastris. Confluent annab ka oma operaator.

Производительность

Tähtis on testida jõudlust Kafka eksemplari võrdlusuuringuga. Sellised testid aitavad enne probleemide tekkimist leida võimalikud kitsaskohad. Õnneks pakub Kafka juba kahte jõudluse testimise tööriista: kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. Kasutage neid aktiivselt. Viitamiseks võite vaadata jaotises kirjeldatud tulemusi see postitus Jay Kreps või keskenduge sellele seda arvustust Amazon MSK autor Stéphane Maarek.

Operatsioonid

Jälgimine

Süsteemi läbipaistvus on väga oluline – muidu ei saa te aru, mis selles toimub. Tänapäeval on olemas kindel tööriistakomplekt, mis pakub mõõdikutepõhist jälgimist pilvepõhises stiilis. Kaks populaarset tööriista selleks on Prometheus ja Grafana. Prometheus saab JMX eksportija abil koguda kõigi Java protsesside (Kafka, Zookeeper, Kafka Connect) mõõdikuid – kõige lihtsamal viisil. Kui lisate cAdvisori mõõdikud, saate paremini aru, kuidas Kubernetes ressursse kasutatakse.

Strimzil on Kafka jaoks väga mugav näide Grafana armatuurlauast. See visualiseerib põhimõõdikuid, näiteks alareplitseeritud või võrguühenduseta sektorite kohta. Seal on kõik väga selge. Neid mõõdikuid täiendavad ressursside kasutamise ja tulemuslikkuse teave ning stabiilsusnäitajad. Nii et saate tasuta Kafka klastri jälgimise!

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

Seda kõike oleks tore täiendada klientide jälgimisega (mõõdikud tarbijate ja tootjate kohta), samuti latentsuseirega (selleks on urg) ja otsast lõpuni jälgimine – selleks kasutamiseks Kafka monitor.

Logimine

Logimine on veel üks kriitiline ülesanne. Veenduge, et kõik teie Kafka installi konteinerid oleksid sisse logitud stdout и stderrja veenduge ka, et teie Kubernetese klaster koondab kõik logid kesksesse logimise infrastruktuuri, nt. Elasticsearch.

Tervisekontroll

Kubernetes kasutab elavuse ja valmisoleku sonde, et kontrollida, kas teie kaunad töötavad normaalselt. Kui elavuse kontroll ebaõnnestub, peatab Kubernetes selle konteineri ja taaskäivitab selle automaatselt, kui taaskäivituspoliitika on vastavalt seadistatud. Kui valmisoleku kontroll ebaõnnestub, isoleerib Kubernetes podi hooldustaotlustest. Seega pole sellistel juhtudel enam vaja käsitsi sekkumist, mis on suur pluss.

Värskenduste levitamine

StatefulSets toetavad automaatseid värskendusi: kui valite strateegia RollingUpdate, värskendatakse kõiki Kafka all olevaid uuendusi kordamööda. Sel moel saab seisakuid nulli viia.

Skaleerimine

Kafka klastri skaleerimine ei ole lihtne ülesanne. Kubernetes teeb aga väga lihtsaks kaustade skaleerimise teatud arvule koopiatele, mis tähendab, et saate deklaratiivselt määratleda nii palju Kafka maaklereid, kui soovite. Kõige keerulisem on sel juhul sektorite ümberjaotamine pärast suurendamist või enne skaleerimist. Jällegi aitab Kubernetes teid selle ülesandega toime tulla.

Haldamine

Kafka klastri haldamisega seotud ülesandeid, nagu teemade loomine ja sektorite ümbermääramine, saab teha olemasolevate shelliskriptide abil, avades oma kaustades käsurea liidese. See lahendus pole aga kuigi ilus. Strimzi toetab teemade haldamist erineva operaatori abil. Siin on arenguruumi.

Varundamine ja taastamine

Nüüd hakkab Kafka saadavus sõltuma ka Kubernetese saadavusest. Kui teie Kubernetese klaster ebaõnnestub, siis halvimal juhul ebaõnnestub ka teie Kafka klaster. Murphy seaduse järgi see kindlasti juhtub ja te kaotate andmeid. Seda tüüpi riskide vähendamiseks kasutage head varukontseptsiooni. Võite kasutada MirrorMakerit, teine ​​​​võimalus on kasutada selleks S3, nagu siin kirjeldatud siin postituses. Zalandost.

Järeldus

Väikeste ja keskmise suurusega Kafka klastritega töötades tasub kindlasti kasutada Kubernetes, kuna see annab täiendavat paindlikkust ja lihtsustab operaatori kogemust. Kui teil on väga olulised mittefunktsionaalse latentsusaja ja/või läbilaskevõime nõuded, võib olla parem kaaluda mõnda muud juurutamisvalikut.

Allikas: www.habr.com