Zdravím ťa, Habr!
Svojho času sme ako prví uviedli tému na ruský trh a pokračovať pre jeho rozvoj. Najmä sme našli tému interakcie medzi Kafkom a . Pozorovateľné (a dosť opatrné) táto téma bola publikovaná na blogu Confluent ešte v októbri minulého roka pod autorskou autorkou Gwen Shapira. Dnes by sme vás chceli upozorniť na novší článok z apríla od Johanna Gygera, ktorý, aj keď nie bez otáznika v názve, skúma tému vecnejšie, pričom text dopĺňa zaujímavými odkazmi. Ak môžete, odpustite nám voľný preklad „opice chaosu“!
Úvod
Kubernetes je navrhnutý tak, aby zvládal bezstavové pracovné zaťaženie. Typicky sú takéto pracovné záťaže prezentované vo forme mikroservisnej architektúry, sú ľahké, dobre sa škálujú horizontálne, dodržiavajú princípy 12-faktorových aplikácií a môžu pracovať s ističmi a chaosovými opicami.
Kafka na druhej strane v podstate funguje ako distribuovaná databáza. Pri práci sa teda musíte zaoberať stavom a je oveľa ťažší ako mikroservis. Kubernetes podporuje stavové zaťaženia, ale ako poukazuje Kelsey Hightower v dvoch tweetoch, malo by sa s nimi zaobchádzať opatrne:
Niektorí ľudia majú pocit, že ak Kubernetes uvediete do stavového pracovného zaťaženia, stane sa plne spravovanou databázou, ktorá konkuruje RDS. Toto je nesprávne. Možno, ak budete dostatočne tvrdo pracovať, pridáte ďalšie komponenty a prilákate tím inžinierov SRE, budete môcť vybudovať RDS na vrchole Kubernetes.
Vždy každému odporúčam, aby bol pri spúšťaní stavových úloh na Kubernetes mimoriadne opatrný. Väčšina ľudí, ktorí sa pýtajú „môžem spustiť stavové pracovné zaťaženie na Kubernetes“, nemá dostatok skúseností s Kubernetes a často s pracovným zaťažením, na ktoré sa pýtajú.
Mali by ste teda spustiť Kafku na Kubernetes? Protiotázka: bude Kafka fungovať lepšie bez Kubernetes? Preto chcem v tomto článku zdôrazniť, ako sa Kafka a Kubernetes dopĺňajú a aké úskalia môže priniesť ich kombinovanie.
Čas dokončenia
Poďme sa baviť o základnej veci – o samotnom runtime prostredí
Proces
Makléri Kafka sú priateľskí k procesoru. TLS môže predstavovať určitú réžiu. Klienti Kafka však môžu byť náročnejší na CPU, ak používajú šifrovanie, to však nemá vplyv na maklérov.
pamäť
Kafkovi makléri žerú pamäť. Veľkosť haldy JVM je zvyčajne obmedzená na 4-5 GB, ale budete potrebovať aj veľa systémovej pamäte, pretože Kafka veľmi intenzívne využíva vyrovnávaciu pamäť stránok. V Kubernetes podľa toho nastavte zdroje kontajnera a limity požiadaviek.
Uloženie údajov
Ukladanie dát v kontajneroch je efemérne – dáta sa stratia pri reštarte. Pre dáta Kafka môžete použiť zväzok emptyDira efekt bude podobný: údaje o vašom maklérovi sa po dokončení stratia. Vaše správy môžu byť stále uložené u iných maklérov ako repliky. Preto po reštarte musí neúspešný broker najprv replikovať všetky dáta a tento proces môže trvať veľa času.
Preto by ste mali používať dlhodobé ukladanie údajov. Nech je to nelokálne dlhodobé úložisko so súborovým systémom XFS alebo presnejšie ext4. Nepoužívajte NFS. Varoval som ťa. Verzie NFS v3 alebo v4 nebudú fungovať. Kafka broker skrátka spadne, ak nedokáže vymazať dátový adresár kvôli problému „hlúpeho premenovania“ v NFS. Ak som vás ešte nepresvedčil, tak veľmi opatrne . Úložisko údajov by malo byť nelokálne, aby si Kubernetes mohol flexibilnejšie vybrať nový uzol po reštarte alebo premiestnení.
Sieť
Rovnako ako u väčšiny distribuovaných systémov je výkon Kafky veľmi závislý od udržiavania latencie siete na minime a šírky pásma na maxime. Nesnažte sa hostiť všetkých brokerov na rovnakom uzle, pretože to zníži dostupnosť. Ak zlyhá uzol Kubernetes, zlyhá celý klaster Kafka. Taktiež nerozdeľujte klaster Kafka na celé dátové centrá. To isté platí pre klaster Kubernetes. Dobrým kompromisom je v tomto prípade výber rôznych zón dostupnosti.
konfigurácia
Pravidelné manifesty
Webová stránka Kubernetes má o tom, ako nakonfigurovať ZooKeeper pomocou manifestov. Keďže ZooKeeper je súčasťou Kafky, je to dobré miesto, kde sa môžete zoznámiť s tým, ktoré koncepty Kubernetes tu platia. Keď to pochopíte, môžete použiť rovnaké koncepty s Kafkovým klastrom.
- pod: Pod je najmenšia nasaditeľná jednotka v Kubernetes. Pod obsahuje vaše pracovné zaťaženie a samotný modul zodpovedá procesu vo vašom klastri. Pod obsahuje jednu alebo viac nádob. Každý server ZooKeeper v súbore a každý maklér v klastri Kafka bude fungovať v samostatnom pod.
- StatefulSet: StatefulSet je objekt Kubernetes, ktorý spracováva viacero stavových úloh a takéto úlohy vyžadujú koordináciu. StatefulSets poskytujú záruky týkajúce sa objednania podov a ich jedinečnosti.
- Bezhlavé služby: Služby vám umožňujú odpojiť moduly od klientov pomocou logického názvu. Kubernetes je v tomto prípade zodpovedný za vyrovnávanie záťaže. Pri prevádzke stavových úloh, ako sú ZooKeeper a Kafka, však klienti potrebujú komunikovať s konkrétnou inštanciou. Tu sú bezhlavé služby užitočné: v tomto prípade bude mať klient stále logické meno, ale nebudete musieť kontaktovať priamo modul.
- Objem dlhodobého skladovania: Tieto zväzky sú potrebné na konfiguráciu nemiestneho blokového trvalého úložiska uvedeného vyššie.
Na Poskytuje komplexnú sadu manifestov, ktoré vám pomôžu začať s Kafkou na Kubernetes.
Tabuľky kormidla
Helm je správca balíkov pre Kubernetes, ktorý sa dá porovnať so správcami balíkov OS, ako sú yum, apt, Homebrew alebo Chocolatey. Uľahčuje inštaláciu preddefinovaných softvérových balíkov popísaných v grafoch Helm. Dobre zvolený Helmov diagram uľahčuje náročnú úlohu, ako správne nakonfigurovať všetky parametre na používanie Kafka na Kubernetes. Existuje niekoľko Kafkových diagramov: oficiálny sa nachádza , je tam jeden z , ešte jeden - od .
prevádzkovatelia
Keďže Helm má určité nedostatky, značnú obľubu si získava ďalší nástroj: operátori Kubernetes. Operátor nielenže balí softvér pre Kubernetes, ale umožňuje aj nasadenie takéhoto softvéru a jeho správu.
V zozname Spomínajú sa dvaja operátori pre Kafku. Jeden z nich - . So Strimzi je ľahké uviesť váš klaster Kafka do prevádzky v priebehu niekoľkých minút. Nie je potrebná prakticky žiadna konfigurácia, navyše samotný operátor poskytuje niekoľko príjemných funkcií, napríklad point-to-point TLS šifrovanie v rámci klastra. Confluent tiež poskytuje .
produktivita
Je dôležité otestovať výkon porovnávaním vašej inštancie Kafka. Takéto testy vám pomôžu nájsť potenciálne úzke miesta skôr, ako nastanú problémy. Našťastie, Kafka už poskytuje dva nástroje na testovanie výkonu: kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. Využite ich aktívne. Ako referenciu si môžete pozrieť výsledky opísané v Jay Kreps, alebo sa zamerajte na Amazon MSK od Stéphana Maareka.
operácie
monitorovanie
Transparentnosť v systéme je veľmi dôležitá – inak nepochopíte, čo sa v ňom deje. Dnes existuje solídna súprava nástrojov, ktorá poskytuje monitorovanie založené na metrikách v natívnom cloudovom štýle. Dva obľúbené nástroje na tento účel sú Prometheus a Grafana. Prometheus dokáže zbierať metriky zo všetkých procesov Java (Kafka, Zookeeper, Kafka Connect) pomocou exportéra JMX – tým najjednoduchším spôsobom. Ak pridáte metriky cAdvisor, môžete lepšie pochopiť, ako sa zdroje používajú v Kubernetes.
Strimzi má pre Kafku veľmi pohodlný príklad prístrojovej dosky Grafana. Vizualizuje kľúčové metriky, napríklad nedostatočne replikované sektory alebo sektory, ktoré sú offline. Všetko je tam veľmi jasné. Tieto metriky sú doplnené o informácie o využití zdrojov a výkone, ako aj o indikátory stability. Základné monitorovanie klastra Kafka teda získate zadarmo!
Zdroj:
Bolo by pekné doplniť to všetko o monitorovanie klientov (metriky o spotrebiteľoch a výrobcoch), ako aj o sledovanie latencie (na to existuje ) a end-to-end monitoring – pre toto použitie .
Ťažba dreva
Logovanie je ďalšou kritickou úlohou. Uistite sa, že všetky kontajnery vo vašej inštalácii Kafka sú prihlásené stdout и stderra tiež zaistite, aby váš klaster Kubernetes agregoval všetky prihlásenia do centrálnej protokolovacej infraštruktúry, napr. .
Funkčná kontrola
Kubernetes používa sondy živosti a pripravenosti na kontrolu, či vaše moduly bežia normálne. Ak kontrola životnosti zlyhá, Kubernetes zastaví daný kontajner a potom ho automaticky reštartuje, ak je príslušne nastavená politika reštartu. Ak kontrola pripravenosti zlyhá, Kubernetes izoluje modul od požiadaviek na obsluhu. V takýchto prípadoch teda už vôbec nie je potrebný manuálny zásah, čo je veľké plus.
Zavádzanie aktualizácií
StatefulSets podporujú automatické aktualizácie: ak vyberiete stratégiu RollingUpdate, postupne sa aktualizuje každá pod Kafkou. Týmto spôsobom je možné znížiť prestoje na nulu.
Škálovanie
Škálovanie Kafkovho klastra nie je ľahká úloha. Kubernetes však veľmi uľahčuje škálovanie modulov na určitý počet replík, čo znamená, že môžete deklaratívne definovať toľko maklérov Kafka, koľko chcete. Najťažšou vecou v tomto prípade je opätovné priradenie sektorov po zväčšení alebo pred zmenšením. S touto úlohou vám opäť pomôže Kubernetes.
Administrácia
Úlohy súvisiace so správou vášho klastra Kafka, ako je vytváranie tém a preraďovanie sektorov, je možné vykonať pomocou existujúcich skriptov shell otvorením rozhrania príkazového riadka vo vašich moduloch. Toto riešenie však nie je príliš krásne. Strimzi podporuje správu tém pomocou iného operátora. Je tu priestor na zlepšenie.
Zálohovanie a obnovenie
Teraz bude dostupnosť Kafky závisieť aj od dostupnosti Kubernetes. Ak váš klaster Kubernetes zlyhá, v najhoršom prípade zlyhá aj váš klaster Kafka. Podľa Murphyho zákona sa to určite stane a prídete o dáta. Ak chcete znížiť tento typ rizika, majte dobrý koncept zálohovania. Môžete použiť MirrorMaker, ďalšou možnosťou je použiť na to S3, ako je popísané v tomto zo Zalanda.
Záver
Pri práci s malými až stredne veľkými klastrami Kafka sa určite oplatí používať Kubernetes, pretože poskytuje dodatočnú flexibilitu a zjednodušuje prácu operátora. Ak máte veľmi významné nefunkčné požiadavky na latenciu a/alebo priepustnosť, potom môže byť lepšie zvážiť inú možnosť nasadenia.
Zdroj: hab.com