Is Kafka op Kubernetes goed?

Groete, Habr!

Op 'n tyd was ons die eerste om die onderwerp aan die Russiese mark bekend te stel Kafka en gaan voort spoor vir die ontwikkeling daarvan. In die besonder het ons die onderwerp van interaksie tussen Kafka en Kubernetes. Waarneembaar (en redelik versigtig) статья hierdie onderwerp is in Oktober verlede jaar op die Confluent-blog gepubliseer onder die outeurskap van Gwen Shapira. Vandag wil ons u aandag vestig op 'n meer onlangse artikel uit April deur Johann Gyger, wat, hoewel nie sonder 'n vraagteken in die titel nie, die onderwerp op 'n meer inhoudelike wyse ondersoek en die teks met interessante skakels vergesel. Vergewe ons asseblief die gratis vertaling van "chaos aap" as jy kan!

Inleiding

Kubernetes is ontwerp om staatlose werkladings te hanteer. Tipies word sulke werkladings in die vorm van 'n mikrodiensargitektuur aangebied, hulle is liggewig, skaal goed horisontaal, volg die beginsels van 12-faktor toepassings en kan met stroombrekers en chaos-ape werk.

Kafka, aan die ander kant, tree in wese op as 'n verspreide databasis. As u dus werk, moet u die staat hanteer, en dit is baie swaarder as 'n mikrodiens. Kubernetes ondersteun statige vragte, maar soos Kelsey Hightower in twee tweets uitwys, moet dit versigtig hanteer word:

Sommige mense voel dat as jy Kubernetes in 'n statige werklading rol, dit 'n volledig bestuurde databasis word wat met RDS meeding. Dis verkeerd. Miskien, as jy hard genoeg werk, bykomende komponente byvoeg en 'n span SRE-ingenieurs lok, sal jy RDS bo-op Kubernetes kan bou.

Ek beveel altyd aan dat almal uiters versigtig moet wees wanneer statige werkladings op Kubernetes uitgevoer word. Die meeste mense wat vra "kan ek statige werkladings op Kubernetes uitvoer", het nie genoeg ondervinding met Kubernetes nie, en dikwels met die werklading waaroor hulle vra.

So, moet jy Kafka op Kubernetes bestuur? Teenvraag: sal Kafka beter werk sonder Kubernetes? Daarom wil ek in hierdie artikel uitlig hoe Kafka en Kubernetes mekaar aanvul, en watter slaggate kan kom met die kombinasie daarvan.

Tyd van voltooiing

Kom ons praat oor die basiese ding - die looptyd-omgewing self

proses

Kafka-makelaars is SVE-vriendelik. TLS kan 'n bietjie oorhoofse koste instel. Kafka-kliënte kan egter meer SVE-intensief wees as hulle enkripsie gebruik, maar dit raak nie makelaars nie.

geheue

Kafka-makelaars eet geheue op. Die JVM-hoopgrootte is gewoonlik beperk tot 4-5 GB, maar jy sal ook baie stelselgeheue benodig aangesien Kafka die bladsykas baie swaar gebruik. In Kubernetes, stel houerhulpbron en versoek limiete dienooreenkomstig.

Datastoor

Databerging in houers is kortstondig - data gaan verlore wanneer dit herbegin word. Vir Kafka-data kan jy 'n volume gebruik emptyDir, en die effek sal soortgelyk wees: jou makelaardata sal verlore gaan na voltooiing. Jou boodskappe kan steeds as replikas op ander makelaars gestoor word. Daarom, na 'n herbegin, moet die mislukte makelaar eers alle data herhaal, en hierdie proses kan baie tyd neem.

Dit is hoekom jy langtermyn-databerging moet gebruik. Laat dit nie-plaaslike langtermynberging wees met die XFS-lêerstelsel of, meer presies, ext4. Moenie NFS gebruik nie. Ek het jou gewaarsku. NFS weergawes v3 of v4 sal nie werk nie. Kortom, die Kafka-makelaar sal ineenstort as dit nie die datagids kan uitvee nie as gevolg van die "dom hernoem" probleem in NFS. As ek jou nog nie oortuig het nie, baie versigtig lees hierdie artikel. Die datastoor moet nie-plaaslik wees sodat Kubernetes meer buigsaam 'n nuwe nodus kan kies na 'n herbegin of hervestiging.

Netwerk

Soos met die meeste verspreide stelsels, is Kafka se werkverrigting baie afhanklik daarvan om netwerkvertraging tot 'n minimum en bandwydte tot die maksimum te hou. Moenie probeer om alle makelaars op dieselfde nodus te huisves nie, aangesien dit beskikbaarheid sal verminder. As 'n Kubernetes-nodus misluk, sal die hele Kafka-kluster misluk. Moet ook nie die Kafka-kluster oor hele datasentrums versprei nie. Dieselfde geld vir die Kubernetes-groepering. 'n Goeie kompromie in hierdie geval is om verskillende beskikbaarheidsones te kies.

opset

Gereelde manifeste

Die Kubernetes-webwerf het baie goeie gids oor hoe om ZooKeeper op te stel met behulp van manifeste. Aangesien ZooKeeper deel van Kafka is, is dit 'n goeie plek om te begin om vertroud te raak met watter Kubernetes-konsepte hier van toepassing is. Sodra jy dit verstaan, kan jy dieselfde konsepte met 'n Kafka-kluster gebruik.

• Onder: 'n Peul is die kleinste ontplooibare eenheid in Kubernetes. 'n Peul bevat jou werklading, en die peul self stem ooreen met 'n proses in jou groepering. 'n Peul bevat een of meer houers. Elke ZooKeeper-bediener in die ensemble en elke makelaar in die Kafka-groepering sal in 'n aparte pod loop.
• StatefulSet: 'n StatefulSet is 'n Kubernetes-objek wat veelvuldige stateful-werkladings hanteer, en sulke werkladings vereis koördinasie. StatefulSets bied waarborge met betrekking tot die volgorde van peule en hul uniekheid.
• Koplose dienste: Dienste laat jou toe om peule van kliënte los te maak met 'n logiese naam. Kubernetes is in hierdie geval verantwoordelik vir lasbalansering. Wanneer egter statige werkladings bedryf word, soos ZooKeeper en Kafka, moet kliënte met 'n spesifieke instansie kommunikeer. Dit is waar koplose dienste handig te pas kom: in hierdie geval sal die kliënt steeds 'n logiese naam hê, maar jy hoef nie die pod direk te kontak nie.
• Langtermyn bergingsvolume: Hierdie volumes is nodig om die nie-plaaslike blok aanhoudende berging hierbo genoem op te stel.

Op Yolean Verskaf 'n omvattende stel manifeste om jou te help om met Kafka op Kubernetes te begin.

Roerkaarte

Helm is 'n pakketbestuurder vir 'n Kubernetes wat vergelyk kan word met OS-pakketbestuurders soos yum, apt, Homebrew of Chocolatey. Dit maak dit maklik om vooraf gedefinieerde sagtewarepakkette te installeer wat in Helm-kaarte beskryf word. 'n Goed gekose Helm-kaart maak die moeilike taak om al die parameters behoorlik op te stel om Kafka op Kubernetes te gebruik, maklik. Daar is verskeie Kafka-diagramme: die amptelike een is geleë in broeikas toestand, daar is een van bymekaar kom, nog een - van Bitnami.

operateurs

Omdat Helm sekere tekortkominge het, wen 'n ander instrument aansienlike gewildheid: Kubernetes-operateurs. Die operateur verpak nie net sagteware vir Kubernetes nie, maar laat jou ook toe om sulke sagteware te ontplooi en dit te bestuur.

In die lys wonderlike operateurs Twee operateurs vir Kafka word genoem. Een van hulle - Strimzi. Met Strimzi is dit maklik om jou Kafka-kluster binne minute aan die gang te kry. Feitlik geen konfigurasie is nodig nie, boonop bied die operateur self 'n paar goeie funksies, byvoorbeeld punt-tot-punt TLS-enkripsie binne die groep. Confluent bied ook eie operateur.

produktiwiteit

Dit is belangrik om prestasie te toets deur jou Kafka-instansie te meet. Sulke toetse sal jou help om potensiële knelpunte te vind voordat probleme opduik. Gelukkig bied Kafka reeds twee werkverrigtingtoetsinstrumente: kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. Maak aktief gebruik daarvan. Vir verwysing kan u verwys na die resultate wat in beskryf word hierdie pos Jay Kreps, of fokus op hierdie resensie Amazon MSK deur Stéphane Maarek.

bedrywighede

Monitering

Deursigtigheid in die stelsel is baie belangrik – anders sal jy nie verstaan ​​wat daarin gebeur nie. Vandag is daar 'n soliede gereedskapstel wat metrieke-gebaseerde monitering in die wolk-inheemse styl bied. Twee gewilde gereedskap vir hierdie doel is Prometheus en Grafana. Prometheus kan metrieke van alle Java-prosesse (Kafka, Zookeeper, Kafka Connect) met behulp van 'n JMX-uitvoerder insamel - op die eenvoudigste manier. As jy cAdvisor-statistieke byvoeg, kan jy meer volledig verstaan ​​hoe hulpbronne in Kubernetes gebruik word.

Strimzi het 'n baie gerieflike voorbeeld van 'n Grafana-paneelbord vir Kafka. Dit visualiseer sleutelmaatstawwe, byvoorbeeld oor ondergerepliseerde sektore of dié wat vanlyn is. Alles is baie duidelik daar. Hierdie maatstawwe word aangevul deur hulpbronbenutting en prestasie-inligting, sowel as stabiliteitsaanwysers. So jy kry basiese Kafka-klustermonitering vir niks!

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

Dit sal lekker wees om dit alles aan te vul met kliëntmonitering (metrieke oor verbruikers en produsente), asook latensiemonitering (hiervoor is daar Burrow) en end-tot-end monitering - vir hierdie gebruik Kafka Monitor.

Tekening

Logging is nog 'n kritieke taak. Maak seker dat alle houers in jou Kafka-installasie aangemeld is stdout и stderr, en verseker ook dat jou Kubernetes-kluster alle logs saamvoeg in 'n sentrale loginfrastruktuur, bv. Elasticsearch.

Funksionele toetsing

Kubernetes gebruik lewendheid en gereedheidsondersoeke om te kyk of jou peule normaal loop. As die lewendheidkontrole misluk, sal Kubernetes daardie houer stop en dit dan outomaties herbegin as die herbeginbeleid dienooreenkomstig gestel is. As die gereedheidskontrole misluk, isoleer Kubernetes die peul van diensversoeke. In sulke gevalle is handmatige ingryping dus glad nie meer nodig nie, wat 'n groot pluspunt is.

Ontplooi opdaterings

StatefulSets ondersteun outomatiese opdaterings: as jy die RollingUpdate-strategie kies, sal elkeen onder Kafka om die beurt opgedateer word. Op hierdie manier kan stilstand tot nul verminder word.

Skaal

Om 'n Kafka-kluster te skaal is nie 'n maklike taak nie. Kubernetes maak dit egter baie maklik om peule na 'n sekere aantal replikas te skaal, wat beteken dat jy verklarend soveel Kafka-makelaars kan definieer as wat jy wil. Die moeilikste ding in hierdie geval is die hertoewysing van sektore na afskaling of voor afskaal. Weereens, Kubernetes sal jou help met hierdie taak.

administrasie

Take wat verband hou met die administrasie van jou Kafka-kluster, soos die skep van onderwerpe en die hertoewysing van sektore, kan gedoen word deur bestaande dopskrifte te gebruik deur die opdragreëlkoppelvlak in jou peule oop te maak. Hierdie oplossing is egter nie baie mooi nie. Strimzi ondersteun die bestuur van onderwerpe deur 'n ander operateur te gebruik. Hier is ruimte vir verbetering.

Friends en herstel

Nou sal die beskikbaarheid van Kafka ook afhang van die beskikbaarheid van Kubernetes. As jou Kubernetes-kluster misluk, dan sal jou Kafka-kluster in die ergste geval ook misluk. Volgens Murphy se wet sal dit beslis gebeur, en jy sal data verloor. Om hierdie tipe risiko te verminder, het 'n goeie rugsteunkonsep. Jy kan MirrorMaker gebruik, 'n ander opsie is om S3 hiervoor te gebruik, soos hierin beskryf Post van Zalando.

Gevolgtrekking

Wanneer daar met klein tot mediumgrootte Kafka-klusters gewerk word, is dit beslis die moeite werd om Kubernetes te gebruik, aangesien dit bykomende buigsaamheid bied en die operateurservaring vereenvoudig. As u baie beduidende nie-funksionele latensie- en/of deurvoervereistes het, is dit dalk beter om 'n ander ontplooiingsopsie te oorweeg.

Bron: will.com