Tervitused, Habr!
Omal ajal olime esimesed, kes teemat Venemaa turule tutvustasid
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
Сеть
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
- 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
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
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
Производительность
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
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:
Seda kõike oleks tore täiendada klientide jälgimisega (mõõdikud tarbijate ja tootjate kohta), samuti latentsuseirega (selleks on
Logimine
Logimine on veel üks kriitiline ülesanne. Veenduge, et kõik teie Kafka installi konteinerid oleksid sisse logitud stdout
и stderr
ja veenduge ka, et teie Kubernetese klaster koondab kõik logid kesksesse logimise infrastruktuuri, nt.
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
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