Ass Kafka op Kubernetes gutt?

Gréiss, Habr!

Op enger Zäit ware mir déi éischt fir d'Thema op de russesche Maart aféieren Kafka a weider Streck fir seng Entwécklung. Besonnesch hu mir d'Thema vun der Interaktioun tëscht Kafka a Kubernetes. Observéierbar (a ganz virsiichteg) en Artikel dëst Thema gouf am Confluent Blog am Oktober d'lescht Joer ënner der Autoritéit vum Gwen Shapira publizéiert. Haut wëlle mir Iech op e méi rezenten Artikel vum Abrëll vum Johann Gyger opmierksam maachen, deen, obschonn net ouni Froezeechen am Titel, d'Thema méi substantiell ënnersicht, an den Text mat interessante Linken begleet. Verzeien eis w.e.g. déi gratis Iwwersetzung vum "Chaos Monkey" wann Dir kënnt!

Aféierung

Kubernetes ass entwéckelt fir stateless Aarbechtsbelaaschtungen ze handhaben. Typesch ginn esou Aarbechtslaascht a Form vun enger Mikroservicearchitektur presentéiert, si si liicht, horizontal skaléieren, befollegen d'Prinzipien vun 12-Faktor Uwendungen a kënne mat Circuit Breaker a Chaos Affen schaffen.

Kafka, op der anerer Säit, wierkt wesentlech als verdeelt Datebank. Also, wann Dir schafft, musst Dir mam Staat këmmeren, an et ass vill méi schwéier wéi e Mikroservice. Kubernetes ënnerstëtzt statesch Lasten, awer wéi de Kelsey Hightower an zwee Tweets weist, solle se virsiichteg behandelt ginn:

E puer Leit mengen datt wann Dir Kubernetes an eng statesch Aarbechtslaascht rullt, gëtt et eng voll geréiert Datebank déi RDS rivaliséiert. Dëst ass falsch. Vläicht, wann Dir haart genuch schafft, zousätzlech Komponenten bäidréit an en Team vun SRE Ingenieuren unzezéien, kënnt Dir RDS uewen op Kubernetes bauen.

Ech recommandéieren ëmmer datt jidderee extrem virsiichteg ass wann se statesch Aarbechtslaascht op Kubernetes leeft. Déi meescht Leit, déi froen "kann ech statesch Aarbechtslaascht op Kubernetes lafen" hunn net genuch Erfahrung mat Kubernetes, an dacks mat der Aarbechtsbelaaschtung iwwer déi se froen.

Also, sollt Dir Kafka op Kubernetes lafen? Géigefro: funktionnéiert de Kafka besser ouni Kubernetes? Dofir wëll ech an dësem Artikel ervirhiewen, wéi Kafka a Kubernetes sech ergänzen, a wéi eng Falen mat der Kombinatioun kommen.

Zäit vun Ofschloss

Loosst eis iwwer d'Basis Saach schwätzen - d'Runtime Ëmfeld selwer

Prozess

Kafka Broker sinn CPU frëndlech. TLS kann e puer Overhead aféieren. Wéi och ëmmer, Kafka Cliente kënne méi CPU-intensiv sinn wann se Verschlësselung benotzen, awer dëst beaflosst net Broker.

Erënnerung

Kafka Courtiere iessen Erënnerung. D'JVM Heap Gréisst ass normalerweis limitéiert op 4-5 GB, awer Dir wäert och vill Systemspeicher brauchen, well Kafka de Säitecache ganz schwéier benotzt. A Kubernetes, set Container Ressource an Ufro Limiten deementspriechend.

Datengeschäft

Datelagerung a Container ass ephemeral - Daten gi verluer wann se nei gestart ginn. Fir Kafka Daten kënnt Dir e Volume benotzen emptyDir, an den Effekt wäert ähnlech sinn: Är Brokerdaten ginn nom Ofschloss verluer. Är Messagen kënnen nach ëmmer op anere Broker als Repliken gespäichert ginn. Dofir, no engem Restart, muss de gescheitert Broker als éischt all Daten replizéieren, an dëse Prozess ka vill Zäit daueren.

Dofir sollt Dir laangfristeg Datelagerung benotzen. Loosst et net-lokal laangfristeg Späichere mat dem XFS Dateiesystem sinn oder, méi präzis, ext4. Benotzt net NFS. Ech hunn Iech gewarnt. NFS Versiounen v3 oder v4 wäerten net schaffen. Kuerz gesot, de Kafka Broker wäert ofbriechen wann et den Dateverzeichnis net läsche kann wéinst dem "domm ëmbenennen" Problem an NFS. Wann ech dech nach net iwwerzeegt hunn, ganz virsiichteg liesen dësen Artikel. Den Dategeschäft sollt net lokal sinn, sou datt Kubernetes méi flexibel en neie Node no engem Neistart oder Verlagerung ka wielen.

Netz

Wéi mat de meescht verdeelt Systemer, ass dem Kafka seng Leeschtung héich ofhängeg vun der Netzlatenz op e Minimum a Bandbreedung op de Maximum ze halen. Probéiert net all Broker um selwechten Node ze hosten, well dëst wäert d'Disponibilitéit reduzéieren. Wann e Kubernetes Node feelt, fällt de ganze Kafka-Cluster aus. Och verspreet de Kafka-Cluster net iwwer ganz Datenzenteren. Datselwecht gëlt fir de Kubernetes Stärekoup. E gudde Kompromiss an dësem Fall ass verschidde Disponibilitéitszonen ze wielen.

Configuratioun

Regelméisseg Manifestatiounen

D'Kubernetes Websäit huet ganz gutt Guide iwwer wéi ZooKeeper mat Manifestatiounen konfiguréieren. Zënter ZooKeeper en Deel vum Kafka ass, ass dëst eng gutt Plaz fir ze begéinen fir vertraut ze ginn mat wéi eng Kubernetes Konzepter hei gëllen. Wann Dir dëst versteet, kënnt Dir déiselwecht Konzepter mat engem Kafka-Cluster benotzen.

• By: E Pod ass déi klengst deployéierbar Eenheet a Kubernetes. E Pod enthält Är Aarbechtslaascht, an de Pod selwer entsprécht engem Prozess an Ärem Cluster. E Pod enthält een oder méi Container. All ZooKeeper Server am Ensembel an all Broker am Kafka Cluster lafen an engem separaten Pod.
• StatefulSet: E StatefulSet ass e Kubernetes-Objet dee verschidde statesch Aarbechtslaascht handhabt, an esou Aarbechtslaascht erfuerdert Koordinatioun. StatefulSets bidden Garantien iwwer d'Bestellung vu Pods an hir Eenzegaartegkeet.
• Headless Servicer: Servicer erlaben Iech Pods vu Clienten mat engem logesche Numm ofzeschléissen. Kubernetes ass an dësem Fall verantwortlech fir d'Laaschtbalancéierung. Wéi och ëmmer, wann se statesch Aarbechtslaascht bedreiwen, wéi ZooKeeper a Kafka, musse Cliente mat enger spezifescher Instanz kommunizéieren. Dëst ass wou headless Servicer praktesch kommen: an dësem Fall wäert de Client nach ëmmer e logesche Numm hunn, awer Dir musst de Pod net direkt kontaktéieren.
• Laangfristeg Stockage Volumen: Dës Bänn sinn néideg fir déi net-lokal Block-persistent Späichere ze konfiguréieren déi hei uewen erwähnt ass.

op Yolean Bitt eng ëmfaassend Set vu Manifestatiounen fir Iech ze hëllefen mat Kafka op Kubernetes unzefänken.

Helm Charts

Helm ass e Package Manager fir e Kubernetes dee mat OS Package Manager wéi Yum, apt, Homebrew oder Chocolatey verglach ka ginn. Et mécht et einfach virdefinéiert Software Packagen ze installéieren, déi an Helm Charts beschriwwe ginn. E gutt gewielte Helm Diagramm mécht déi schwiereg Aufgab wéi Dir all Parameteren richteg konfiguréiere fir Kafka op Kubernetes ze benotzen. Et gi verschidde Kafka Diagrammer: déi offiziell läit am Inkubator Zoustand, et gëtt eng vun Zesummelafend, eng méi - vun Bitnami.

Betreiber

Well Helm bestëmmte Mängel huet, gëtt en anert Tool eng bedeitend Popularitéit: Kubernetes Bedreiwer. De Bedreiwer packt net nëmmen Software fir Kubernetes, awer erlaabt Iech och esou Software z'installéieren an ze verwalten.

An der Lëscht erstaunlech Opérateuren Zwee Bedreiwer fir Kafka ginn ernimmt. Ee vun hinnen - Strimzi. Mat Strimzi ass et einfach Äre Kafka-Cluster an e puer Minutten opzemaachen. Praktesch keng Konfiguratioun ass erfuerderlech, zousätzlech bitt de Bedreiwer selwer e puer flott Features, zum Beispill Punkt-zu-Punkt TLS Verschlësselung am Cluster. Confluent bitt och eegene Bedreiwer.

Produktivitéit

Et ass wichteg d'Performance ze testen andeems Dir Är Kafka Instanz benchmarkéiert. Esou Tester hëllefen Iech potenziell Flaschenhals ze fannen ier Probleemer entstinn. Glécklecherweis liwwert de Kafka schonn zwee Performance Testinstrumenter: kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. Maacht se aktiv benotzt. Fir Referenz, kënnt Dir op d'Resultater bezéien, déi an dësem Post Jay Kreps, oder konzentréieren op dëser Iwwerpréiwung Amazon MSK vum Stéphane Maarek.

Operatiounen

Iwwerwaachung

Transparenz am System ass ganz wichteg - soss wäert Dir net verstoen wat an et geschitt. Haut gëtt et e zolitte Toolkit deen Metrik-baséiert Iwwerwaachung am Cloud-native Stil ubitt. Zwee populär Tools fir dësen Zweck sinn Prometheus a Grafana. Prometheus kann Metriken aus all Java Prozesser sammelen (Kafka, Zookeeper, Kafka Connect) mat engem JMX Exporter - op déi einfachst Manéier. Wann Dir cAdvisor Metriken derbäi kënnt, kënnt Dir méi komplett verstoen wéi Ressourcen a Kubernetes benotzt ginn.

Strimzi huet e ganz praktescht Beispill vun engem Grafana Dashboard fir Kafka. Et visualiséiert Schlëssel Metriken, zum Beispill, iwwer ënner-replizéiert Secteuren oder déi offline sinn. Do ass alles ganz kloer. Dës Metriken ginn ergänzt duerch Ressourceverbrauch a Performanceinformatioun, souwéi Stabilitéitsindikatoren. Also kritt Dir Basis Kafka Cluster Iwwerwachung fir näischt!

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

Et wier flott dëst alles mat Client Iwwerwachung ze ergänzen (Metriken op Konsumenten a Produzenten), souwéi latency Iwwerwaachung (fir dëst gëtt et begruewen) an Enn-zu-Enn Iwwerwaachung - fir dës Notzung Kafka Monitor.

Logged

Logging ass eng aner kritesch Aufgab. Vergewëssert Iech datt all Container an Ärer Kafka Installatioun ageloggt sinn stdout и stderr, an och sécherzestellen datt Äre Kubernetes Cluster all Logbicher an eng zentrale Logbicherinfrastruktur aggregéiert, z.B. Elastikerzuch.

Funktionell Kontroll

Kubernetes benotzt Liveness a Bereetschaftssonden fir ze kontrolléieren ob Är Pods normal lafen. Wann d'Liveness-Check feelt, stoppt Kubernetes dëse Container an dann automatesch nei starten wann d'Restart-Politik deementspriechend agestallt ass. Wann d'Bereetschaftskontroll feelt, isoléiert Kubernetes de Pod vu Serviceufroen. An esou Fäll ass manuell Interventioun guer net méi néideg, wat e grousse Plus ass.

Ausrollen Updates

StatefulSets ënnerstëtzen automatesch Updates: wann Dir d'RollingUpdate Strategie wielt, gëtt jidderee ënner Kafka am Tour aktualiséiert. Op dës Manéier kann d'Downtime op Null reduzéiert ginn.

Skaléieren

E Kafka Cluster ze skaléieren ass keng einfach Aufgab. Wéi och ëmmer, Kubernetes mécht et ganz einfach Pods op eng gewëssen Zuel vu Repliken ze skaléieren, dat heescht datt Dir deklarativ esou vill Kafka Broker definéiere kënnt wéi Dir wëllt. Déi schwieregst Saach an dësem Fall ass d'Secteuren ëmzesetzen no der Skala erop oder virum Ofbau. Erëm, Kubernetes hëlleft Iech mat dëser Aufgab.

Administratioun

Aufgaben am Zesummenhang mat der Administratioun vun Ärem Kafka-Cluster, sou wéi Themen erstellen an d'Sektoren ëmsetzen, kënne mat existente Shell-Skripte gemaach ginn andeems Dir de Kommandozeil-Interface an Äre Pods opmaacht. Allerdéngs ass dës Léisung net ganz schéin. Strimzi ënnerstëtzt d'Gestioun vun Themen mat engem anere Bedreiwer. Et gëtt e bësse Plaz fir Verbesserung hei.

Backupsatellit a restauréiert

Elo hänkt d'Disponibilitéit vu Kafka och vun der Disponibilitéit vu Kubernetes of. Wann Äre Kubernetes Cluster fällt, dann am schlëmmste Fall Szenario wäert Äre Kafka Cluster och feelen. No Murphy d'Gesetz, dëst wäert definitiv geschéien, an Dir wäert Daten verléieren. Fir dës Zort vu Risiko ze reduzéieren, hutt Dir e gudde Backupkonzept. Dir kënnt MirrorMaker benotzen, eng aner Optioun ass S3 fir dëst ze benotzen, wéi an dësem beschriwwen posten aus Zalando.

Konklusioun

Wann Dir mat klenge bis mëttelgrousse Kafka-Cluster schafft, ass et definitiv derwäert Kubernetes ze benotzen, well et zousätzlech Flexibilitéit ubitt an d'Bedreiwererfahrung vereinfacht. Wann Dir ganz bedeitend net-funktionell latency an / oder Duerchgangsfuerderunge hutt, da kann et besser sinn eng aner Deploymentoptioun ze berücksichtegen.

Source: will.com