Üdvözlet, Habr!
Egy időben elsőként vezettük be a témát az orosz piacra
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
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
- 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
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ó
Ü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
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
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:
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
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.
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
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