Is Kafka op Kubernetes goed?

Groetnis, Habr!

Op ien kear wiene wy ​​de earste dy't it ûnderwerp yntrodusearre oan 'e Russyske merk Kafka en trochgean spoar foar syn ûntwikkeling. Yn it bysûnder, wy fûnen it ûnderwerp fan ynteraksje tusken Kafka en Kubernetes. Observabel (en frij foarsichtich) artikel dit ûnderwerp waard publisearre op de Confluent blog werom yn oktober ferline jier ûnder it auteurskip fan Gwen Shapira. Hjoed wolle wy jo omtinken freegje foar in mear resint artikel út april fan Johann Gyger, dy't, hoewol net sûnder in fraachteken yn 'e titel, it ûnderwerp op in mear ynhâldlike wize ûndersiket, en de tekst begeliedt mei nijsgjirrige keppelings. Ferjou ús asjebleaft de fergese oersetting fan "chaos aap" as jo kinne!

Ynlieding

Kubernetes is ûntworpen om steatleaze workloads te behanneljen. Typysk wurde sokke workloads presintearre yn 'e foarm fan in mikroservice-arsjitektuer, se binne lichtgewicht, skaal goed horizontaal, folgje de prinsipes fan 12-faktorapplikaasjes, en kinne wurkje mei circuit breakers en chaos-apen.

Kafka, oan 'e oare kant, fungearret yn essinsje as in ferspraat databank. Sa, as jo wurkje, moatte jo omgean mei steat, en it is folle swierder as in mikroservice. Kubernetes stipet steatlike ladingen, mar lykas Kelsey Hightower yn twa tweets oanjout, moatte se mei soarch behannele wurde:

Guon minsken fiele dat as jo Kubernetes rôlje yn in steatlike wurkdruk, wurdt it in folslein behearde databank dy't konkurrearret mei RDS. Dit is ferkeard. Miskien, as jo hurd genôch wurkje, ekstra komponinten tafoegje en in team fan SRE-yngenieurs oanlûke, kinne jo RDS boppe op Kubernetes bouwe.

Ik advisearje elkenien altyd ekstreme foarsichtigens te oefenjen by it útfieren fan steatlike wurkdruk op Kubernetes. De measte minsken dy't freegje "kin ik stateful workloads op Kubernetes útfiere" hawwe net genôch ûnderfining mei Kubernetes, en faaks mei de workload wêr't se oer freegje.

Dus, moatte jo Kafka op Kubernetes útfiere? Tsjinfraach: sil Kafka better wurkje sûnder Kubernetes? Dêrom wol ik yn dit artikel markearje hoe't Kafka en Kubernetes inoar oanfolje, en hokker falkûlen kinne komme mei it kombinearjen.

Tiid fan foltôging

Lit ús prate oer it basis ding - de runtime omjouwing sels

proses

Kafka-makelaars binne CPU-freonlik. TLS kin wat overhead yntrodusearje. Kafka-kliïnten kinne lykwols CPU-yntinsiver wêze as se fersifering brûke, mar dit hat gjin ynfloed op makelders.

ûnthâld

Kafka-makelaars ite ûnthâld op. De JVM-heapgrutte is normaal beheind ta 4-5 GB, mar jo sille ek in soad systeemûnthâld nedich hawwe, om't Kafka de side-cache heul swier brûkt. Stel yn Kubernetes kontenerboarne yn en fersykje limiten neffens.

Data winkel

Gegevens opslach yn konteners is ephemeral - gegevens binne ferlern by opnij starte. Foar Kafka-gegevens kinne jo in folume brûke emptyDir, en it effekt sil fergelykber wêze: jo brokergegevens sille nei foltôging ferlern gean. Jo berjochten kinne noch wurde opslein op oare makelders as replika's. Dêrom, nei in trochstart, moat de mislearre broker earst alle gegevens replikearje, en dit proses kin in protte tiid nimme.

Dit is wêrom jo gegevens opslach op lange termyn moatte brûke. Lit it net-lokale opslach op lange termyn wêze mei it XFS-bestânsysteem of, krekter, ext4. Brûk NFS net. Ik haw dy warskôge. NFS ferzjes v3 of v4 sil net wurkje. Koartsein, de Kafka-broker sil crashe as it de gegevensmap net wiskje kin troch it probleem "dom omneame" yn NFS. As ik dy noch net oertsjûge haw, tige foarsichtich lês dit artikel. De gegevenswinkel moat net-lokaal wêze, sadat Kubernetes fleksibeler in nije knooppunt kieze kin nei in trochstart of ferhuzing.

Netwurk

Lykas by de measte ferdielde systemen, is Kafka's prestaasjes heul ôfhinklik fan it hâlden fan netwurklatinsje op in minimum en bânbreedte om maksimale te meitsjen. Besykje net alle makelders op deselde knoop te hostjen, om't dit de beskikberens sil ferminderje. As in Kubernetes-knooppunt mislearret, sil it hiele Kafka-kluster mislearje. Ferspried it Kafka-kluster ek net oer hiele datasintra. Itselde jildt foar it Kubernetes-kluster. In goed kompromis yn dit gefal is te kiezen ferskillende beskikberens sônes.

Konfiguraasje

Reguliere manifesten

De webside fan Kubernetes hat hiel goede gids oer hoe't jo ZooKeeper konfigurearje mei manifesten. Sûnt ZooKeeper diel útmakket fan Kafka, is dit in goed plak om te begjinnen om bekend te wurden mei hokker Kubernetes-begripen hjir jilde. Sadree't jo dit begripe, kinne jo deselde begripen brûke mei in Kafka-kluster.

• By: In pod is de lytste ynsetbere ienheid yn Kubernetes. In pod befettet jo wurkdruk, en de pod sels komt oerien mei in proses yn jo kluster. In pod befettet ien of mear konteners. Elke ZooKeeper-tsjinner yn it ensemble en elke broker yn 'e Kafka-kluster sil yn in aparte pod rinne.
• StatefulSet: In StatefulSet is in Kubernetes-objekt dat meardere stateful workloads behannelet, en sokke workloads fereaskje koördinaasje. StatefulSets jouwe garânsjes oangeande it bestellen fan pods en harren eigenheid.
• Headless tsjinsten: Tsjinsten kinne jo pods losmeitsje fan kliïnten mei in logyske namme. Kubernetes yn dit gefal is ferantwurdlik foar load balancing. By it operearjen fan stateful workloads, lykas ZooKeeper en Kafka, moatte kliïnten lykwols kommunisearje mei in spesifyk eksimplaar. Dit is wêr't kopleaze tsjinsten nuttich binne: yn dit gefal sil de kliïnt noch in logyske namme hawwe, mar jo hoege net direkt kontakt te meitsjen mei de pod.
• Lange-termyn opslach folume: Dizze folumes binne nedich om de hjirboppe neamde net-lokale persistente opslach te konfigurearjen.

op Yolean Biedt in wiidweidige set manifesten om jo te helpen te begjinnen mei Kafka op Kubernetes.

Helm charts

Helm is in pakketbehearder foar in Kubernetes dy't kin wurde fergelike mei OS-pakketbehearders lykas yum, apt, Homebrew of Chocolatey. It makket it maklik om foarôf definieare softwarepakketten te ynstallearjen beskreaun yn Helm-diagrammen. In goed keazen Helm-diagram makket de drege taak om alle parameters goed te konfigurearjen om Kafka op Kubernetes te brûken maklik. D'r binne ferskate Kafka-diagrammen: de offisjele is te finen yn incubator steat, der is ien fan Konfluint, noch ien - fan Bitnami.

Operators

Om't Helm bepaalde tekoarten hat, wint in oar ark in soad populariteit: Kubernetes-operators. De operator pakket net allinich software foar Kubernetes, mar lit jo ek sokke software ynsette en beheare.

Yn 'e list amazing operators Twa operators foar Kafka wurde neamd. Ien fan harren - Strimzi. Mei Strimzi is it maklik om jo Kafka-kluster yn minuten op en rinne te krijen. Der is praktysk gjin konfiguraasje nedich, boppedat leveret de operator sels in pear moaie funksjes, bygelyks punt-tot-punt TLS-fersifering binnen it kluster. Confluent biedt ek eigen operator.

Produktiviteit

It is wichtich om prestaasjes te testen troch jo Kafka-eksimplaar te benchmarken. Sokke tests sille jo helpe potinsjele knelpunten te finen foardat problemen ûntsteane. Gelokkich leveret Kafka al twa ark foar prestaasjestesten: kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. Meitsje aktyf gebrûk fan harren. Foar referinsje kinne jo ferwize nei de resultaten beskreaun yn dizze post Jay Kreps, of fokusje op dizze resinsje Amazon MSK by Stéphane Maarek.

Operaasjes

Monitoring

Transparânsje yn it systeem is heul wichtich - oars sille jo net begripe wat der yn bart. Tsjintwurdich is d'r in solide toolkit dy't metriken-basearre tafersjoch leveret yn 'e wolk native styl. Twa populêre ark foar dit doel binne Prometheus en Grafana. Prometheus kin metriken sammelje fan alle Java-prosessen (Kafka, Zookeeper, Kafka Connect) mei in JMX-eksporteur - op 'e ienfâldichste manier. As jo ​​cAdvisor-metriken tafoegje, kinne jo folsleiner begripe hoe't boarnen wurde brûkt yn Kubernetes.

Strimzi hat in heul handich foarbyld fan in Grafana-dashboard foar Kafka. It fisualisearret wichtige metriken, bygelyks oer ûnder-replikearre sektoaren as dyjingen dy't offline binne. Alles is dêr hiel dúdlik. Dizze metriken wurde oanfolle troch boarne-gebrûk en prestaasjesynformaasje, lykas stabiliteitsindikatoaren. Dat jo krije basis Kafka-klustermonitoring foar neat!

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

It soe moai wêze om dit alles oan te foljen mei klantmonitoring (metriken oer konsuminten en produsinten), lykas latencymonitoring (dêrfoar is d'r hoale) en end-to-end monitoring - foar dit gebrûk Kafka Monitor.

Logging

Logging is in oare krityske taak. Soargje derfoar dat alle konteners yn jo Kafka-ynstallaasje oanmeld binne stdout и stderr, en soargje der ek foar dat jo Kubernetes-kluster alle logs aggregearret yn in sintrale logging-ynfrastruktuer, bgl. Elastyskesearch.

Funksjonele kontrôle

Kubernetes brûkt liveness- en reewilligensprobes om te kontrolearjen oft jo pods normaal rinne. As de livenesskontrôle mislearret, sil Kubernetes dy kontener stopje en it dan automatysk opnij starte as it werstartbelied dêrop ynsteld is. As de reewilligenskontrôle mislearret, isolearret Kubernetes de pod fan tsjinstoanfragen. Sa is yn sokke gefallen gjin hânmjittich yntervinsje mear nedich, wat in grutte plus is.

Fernijings útrolje

StatefulSets stypje automatyske updates: as jo de RollingUpdate-strategy selektearje, sil elk ûnder Kafka op syn beurt wurde bywurke. Op dizze manier kin downtime wurde fermindere nei nul.

Skaalfergrutting

Skaalfergrutting fan in Kafka-kluster is gjin maklike taak. Kubernetes makket it lykwols heul maklik om pods te skaaljen nei in bepaald oantal replika's, wat betsjut dat jo deklaratyf safolle Kafka-makelaars kinne definiearje as jo wolle. It dreechste ding yn dit gefal is it opnij tawize fan sektoaren nei opskaling of foar skaalfergrutting. Nochris, Kubernetes sil jo helpe mei dizze taak.

Bestjoer

Taken relatearre oan it administrearjen fan jo Kafka-kluster, lykas it meitsjen fan ûnderwerpen en it werjaan fan sektoaren, kinne dien wurde mei besteande shell-skripts troch de kommandorigelynterface yn jo pods te iepenjen. Dizze oplossing is lykwols net heul moai. Strimzi stipet it behearen fan ûnderwerpen mei in oare operator. Hjir is wat romte foar ferbettering.

Backup en weromsette

No sil de beskikberens fan Kafka ek ôfhingje fan de beskikberens fan Kubernetes. As jo ​​Kubernetes-kluster mislearret, dan sil jo Kafka-kluster yn it slimste gefal ek mislearje. Neffens Murphy syn wet, dit sil grif barre, en do silst ferlieze gegevens. Om dit soarte risiko te ferminderjen, hawwe in goed backupkonsept. Jo kinne MirrorMaker brûke, in oare opsje is om S3 hjirfoar te brûken, lykas hjiryn beskreaun peal út Zalando.

konklúzje

By it wurkjen mei lytse oant middelgrutte Kafka-klusters, is it perfoarst wurdich Kubernetes te brûken, om't it ekstra fleksibiliteit leveret en de operatorûnderfining simplifies. As jo ​​​​heul wichtige net-funksjonele latency en / of trochfiereasken hawwe, dan kin it better wêze om in oare ynsetopsje te beskôgjen.

Boarne: www.habr.com