Jó a Kafka a Kubernetesen?

Üdvözlet, Habr!

Egy időben elsőként vezettük be a témát az orosz piacra Kafka és folytasd vágány fejlesztéséhez. Különösen a Kafka és az interakció témáját találtuk meg Kubernetes. Megfigyelhető (és elég óvatos) cikk ez a téma még tavaly októberben jelent meg a Confluent blogon Gwen Shapira szerzője alatt. A mai napon Johann Gyger egy újabb áprilisi cikkére hívjuk fel a figyelmet, aki bár a címben nem kérdőjel nélkül, de érdemben vizsgálja a témát, érdekes linkekkel kísérve a szöveget. Kérlek, bocsásd meg nekünk a „káoszmajom” ingyenes fordítását, ha teheted!

Bevezetés

A Kubernetes állapot nélküli munkaterhelések kezelésére készült. Az ilyen terhelések jellemzően mikroszolgáltatási architektúra formájában jelennek meg, könnyűek, vízszintesen jól skálázhatók, a 12 faktoros alkalmazások elveit követik, megszakítókkal és káoszmajmokkal működnek.

A Kafka ezzel szemben lényegében elosztott adatbázisként működik. Így munka közben állapottal kell számolni, és az sokkal nehezebb, mint egy mikroszolgáltatás. A Kubernetes támogatja az állapotalapú betöltéseket, de ahogy Kelsey Hightower két tweetben is rámutat, óvatosan kell bánni velük:

Vannak, akik úgy érzik, hogy ha a Kubernetes állapotalapú munkaterhelésbe kerül, teljesen felügyelt adatbázissá válik, amely az RDS-szel vetekszik. Ez rossz. Talán ha elég keményen dolgozik, további alkatrészeket ad hozzá, és bevonz egy csapat SRE mérnököt, akkor képes lesz RDS-t építeni a Kubernetesre.

Mindig azt javaslom, hogy mindenki legyen rendkívül óvatos, amikor állapotalapú munkaterheléseket futtat a Kubernetesen. A legtöbb ember, aki azt kérdezi, hogy „futhatok-e állapotalapú terheléseket a Kubernetesen”, nincs elegendő tapasztalata a Kubernetes-szel, és gyakran a kérdezett munkaterheléssel kapcsolatban sem.

Tehát futtasd a Kafkát a Kubernetesen? Ellenkérdés: jobban fog működni Kafka Kubernetes nélkül? Éppen ezért ebben a cikkben szeretném kiemelni, hogy Kafka és Kubernetes hogyan egészíti ki egymást, és milyen buktatókat rejthet a kombinálásuk.

Elkészítés ideje

Beszéljünk az alapvető dologról – magáról a futási környezetről

folyamat

A Kafka brókerek CPU-barátak. A TLS némi többletköltséget jelenthet. A Kafka kliensek azonban nagyobb processzorigényűek lehetnek, ha titkosítást használnak, de ez nem érinti a brókereket.

Память

A Kafka-brókerek felemésztik a memóriát. A JVM kupac mérete általában 4-5 GB-ra korlátozódik, de sok rendszermemóriára is szüksége lesz, mivel a Kafka nagyon erősen használja az oldal gyorsítótárát. A Kubernetesben ennek megfelelően állítsa be a tárolóerőforrásokat és a kérések korlátait.

Adattár

Az adatok tárolása a tárolókban átmeneti – újraindításkor az adatok elvesznek. Kafka adatokhoz használhat kötetet emptyDir, és a hatás hasonló lesz: a bróker adatai a befejezést követően elvesznek. Üzeneteit más közvetítők továbbra is replikákként tárolhatják. Ezért az újraindítás után a meghibásodott közvetítőnek először replikálnia kell az összes adatot, és ez a folyamat sok időt vehet igénybe.

Ezért érdemes hosszú távú adattárolást használni. Legyen szó nem helyi hosszú távú tárolásról XFS fájlrendszerrel vagy pontosabban ext4-gyel. Ne használj NFS-t. Figyelmeztettem. Az NFS v3 vagy v4 nem fog működni. Röviden: a Kafka bróker összeomlik, ha nem tudja törölni az adatkönyvtárat az NFS "hülye átnevezés" problémája miatt. Ha még nem győztelek meg, akkor nagyon óvatosan olvassa el ezt a cikket. Az adattárnak nem helyinek kell lennie, hogy a Kubernetes rugalmasabban tudjon új csomópontot választani újraindítás vagy áthelyezés után.

Hálózat

A legtöbb elosztott rendszerhez hasonlóan a Kafka teljesítménye is nagymértékben függ attól, hogy a hálózati késleltetést a minimumon, a sávszélességet pedig a maximumon tartja-e. Ne próbálja meg az összes brókert ugyanazon a csomóponton tárolni, mert ez csökkenti a rendelkezésre állást. Ha egy Kubernetes-csomópont meghibásodik, a teljes Kafka-fürt meghibásodik. Ezenkívül ne terjessze szét a Kafka-fürtöt teljes adatközpontokban. Ugyanez vonatkozik a Kubernetes klaszterre is. Ebben az esetben jó kompromisszum a különböző rendelkezésre állási zónák kiválasztása.

Configuration

Rendszeres kiáltványok

A Kubernetes webhelyen van nagyon jó útmutató arról, hogyan konfigurálhatja a ZooKeepert jegyzékek használatával. Mivel a ZooKeeper a Kafka része, ez egy jó kiindulópont ahhoz, hogy megismerkedjen a Kubernetes-koncepciókkal. Ha ezt megértette, ugyanazokat a fogalmakat használhatja egy Kafka-fürtnél.

• Alatt: A pod a Kubernetes legkisebb telepíthető egysége. Egy sorba rendezés tartalmazza az Ön munkaterhelését, és maga a pod egy folyamatnak felel meg a fürtben. Egy hüvely egy vagy több tartályt tartalmaz. Az együttes minden ZooKeeper-kiszolgálója és a Kafka-fürt minden közvetítője külön podban fog futni.
• StatefulSet: A StatefulSet egy Kubernetes-objektum, amely több állapotalapú munkaterhelést kezel, és az ilyen munkaterhelések koordinációt igényelnek. A StatefulSets garanciát nyújt a hüvelyek sorrendjére és egyediségére vonatkozóan.
• Fej nélküli szolgáltatások: A szolgáltatások lehetővé teszik a pod-ok leválasztását az ügyfelekről egy logikai név használatával. A Kubernetes ebben az esetben felelős a terheléselosztásért. Az állapotalapú munkaterhelések, például a ZooKeeper és a Kafka működtetésekor azonban az ügyfeleknek egy adott példányhoz kell kommunikálniuk. Itt jönnek jól a fej nélküli szolgáltatások: ebben az esetben a kliensnek továbbra is lesz logikus neve, de nem kell közvetlenül a podhoz fordulnia.
• Hosszú távú tárolási mennyiség: Ezek a kötetek a fent említett nem helyi blokktartós tároló konfigurálásához szükségesek.

tovább Yolean Átfogó jegyzékkészletet kínál, amely segít a Kafka használatának megkezdésében a Kubernetesen.

Helm diagramok

A Helm egy Kubernetes csomagkezelő, amely összehasonlítható az olyan operációs rendszer csomagkezelőivel, mint a yum, apt, Homebrew vagy Chocolatey. Ez megkönnyíti a Helm diagramokban leírt, előre meghatározott szoftvercsomagok telepítését. A jól megválasztott Helm diagram megkönnyíti a Kafka Kubernetesen való használatához szükséges összes paraméter megfelelő konfigurálásának nehéz feladatát. Számos Kafka-diagram létezik: a hivatalos található inkubátor állapotban, van egy a Összefolyó, még egy - től BitNami.

Üzemeltetők

Mivel a Helmnek vannak bizonyos hiányosságai, egy másik eszköz is egyre nagyobb népszerűségnek örvend: a Kubernetes operátorok. Az üzemeltető nemcsak szoftvereket csomagol a Kubernetes számára, hanem lehetővé teszi az ilyen szoftverek telepítését és kezelését is.

A listában csodálatos operátorok A Kafka két operátorát említik. Egyikük - Strimzi. A Strimzi segítségével egyszerűen percek alatt üzembe helyezheti a Kafka-fürtöt. Gyakorlatilag nincs szükség konfigurációra, ráadásul maga az operátor is biztosít néhány szép funkciót, például pont-pont TLS titkosítást a fürtön belül. Confluent is biztosítja saját kezelő.

termelékenység

Fontos a teljesítmény tesztelése a Kafka-példány összehasonlításával. Az ilyen tesztek segítenek megtalálni a lehetséges szűk keresztmetszeteket, mielőtt problémák jelentkeznének. Szerencsére a Kafka már két teljesítménytesztelő eszközt kínál: kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. Aktívan használja őket. Referenciaként tekintse meg a pontban leírt eredményeket ez a poszt Jay Kreps, vagy összpontosítson ezt a felülvizsgálatot Amazon MSK, Stéphane Maarek.

művelet

megfigyelés

A rendszer átláthatósága nagyon fontos - különben nem fogja megérteni, mi történik benne. Ma már létezik egy szilárd eszköztár, amely metrika alapú megfigyelést biztosít felhő natív stílusban. Két népszerű eszköz erre a célra a Prometheus és a Grafana. A Prometheus minden Java-folyamatból (Kafka, Zookeeper, Kafka Connect) képes mérőszámokat gyűjteni egy JMX exportőr segítségével – a legegyszerűbb módon. Ha hozzáadja a cAdvisor-metrikákat, akkor jobban megértheti, hogyan használják fel az erőforrásokat a Kubernetesben.

A Strimzinek van egy nagyon kényelmes példája a Grafana műszerfalra Kafka számára. Megjeleníti a kulcsfontosságú mutatókat, például az alulreplikált vagy offline szektorokat. Ott minden nagyon világos. Ezeket a mutatókat erőforrás-felhasználási és teljesítményinformációk, valamint stabilitási mutatók egészítik ki. Tehát az alap Kafka-fürtfigyelést a semmiért kapja!

Forrás: streamzi.io/docs/master/#kafka_dashboard

Jó lenne mindezt kiegészíteni ügyfélfigyeléssel (fogyasztókra és termelőkre vonatkozó mérőszámok), valamint látenciafigyeléssel (ehhez van Ás) és a végpontok közötti felügyelet – erre a célra Kafka monitor.

Fakitermelés

A naplózás egy másik kritikus feladat. Győződjön meg arról, hogy a Kafka-telepítésben lévő összes tároló bejelentkezve van stdout и stderr, és gondoskodjon arról is, hogy a Kubernetes-fürt minden naplót egy központi naplózási infrastruktúrába összesítsen, pl. Elasticsearch.

Működési ellenőrzés

A Kubernetes életerő- és készenléti szondákat használ annak ellenőrzésére, hogy a pod-ok megfelelően működnek-e. Ha az életerő-ellenőrzés sikertelen, a Kubernetes leállítja a tárolót, majd automatikusan újraindítja, ha az újraindítási házirend megfelelően be van állítva. Ha a készenléti ellenőrzés sikertelen, a Kubernetes elkülöníti a pod-ot a szervizkérésektől. Így ilyen esetekben már egyáltalán nincs szükség manuális beavatkozásra, ami nagy plusz.

Frissítések bevezetése

A StatefulSets támogatja az automatikus frissítéseket: ha a RollingUpdate stratégiát választja, a Kafka alatti mindegyik felváltva frissül. Ily módon az állásidő nullára csökkenthető.

Méretezés

A Kafka-fürt méretezése nem könnyű feladat. A Kubernetes azonban nagyon egyszerűvé teszi a pod-ok méretezését egy bizonyos számú replikára, ami azt jelenti, hogy deklaratívan tetszőleges számú Kafka-brókert határozhat meg. A legnehezebb ebben az esetben a szektorok újrakiosztása a felnagyítás után vagy a kicsinyítés előtt. Ismét a Kubernetes segít ebben a feladatban.

Adminisztráció

A Kafka-fürt adminisztrálásával kapcsolatos feladatok, például témakörök létrehozása és szektorok átrendelése, a meglévő shell-szkriptek használatával is elvégezhetők a parancssori felület megnyitásával a podokban. Ez a megoldás azonban nem túl szép. A Strimzi támogatja a témakörök kezelését egy másik operátor használatával. Itt van még mit javítani.

Mentés és visszaállítás

A Kafka elérhetősége mostantól a Kubernetes elérhetőségétől is függ. Ha a Kubernetes-fürt meghibásodik, akkor a legrosszabb esetben a Kafka-fürt is meghibásodik. Murphy törvénye szerint ez minden bizonnyal megtörténik, és adatvesztés lesz. Az ilyen típusú kockázatok csökkentése érdekében rendelkezzen egy jó biztonsági mentési koncepcióval. Használhatod a MirrorMaker-t, másik lehetőség az S3 használata erre az itt leírtak szerint post Zalandótól.

Következtetés

Ha kis és közepes méretű Kafka klaszterekkel dolgozunk, mindenképpen érdemes a Kuberneteset használni, mivel ez további rugalmasságot biztosít és leegyszerűsíti a kezelői élményt. Ha nagyon jelentős nem funkcionális késleltetési és/vagy átviteli követelményei vannak, akkor érdemesebb megfontolni valamilyen más telepítési lehetőséget.

Forrás: will.com