Üdvözöljük, Habr!
Idővel mi voltunk az elsők, akik bevezették a témát az orosz piacon és folytatjuk a fejlesztését. Különösen érdekesnek találtuk a Kafka és együttműködésének témáját. Egy átfogó (és eléggé óvatos) cikk jelent meg erről a Confluent vállalat blogján még tavaly októberben Gwen Shapiro szerződésével. Ma pedig szeretnénk felhívni a figyelmét egy frissebb, áprilisi cikkre Johann Gyger tollából, aki, bár nem úszta meg kérdőjellel a címében, sokkal megalapozottabb szempontból vizsgálja a témát, érdekes linkek kíséretében. Kérjük, bocsássanak meg nekünk a szabad fordításért, legyenek szívesek!
Bevezetés
A Kubernetes arra lett tervezve, hogy állapotot nem megőrző terhelésekkel dolgozzon. Általában ezek a munka terhelések mikroszolgáltatás-architektúra formájában jelennek meg, könnyűek, jól skálázhatók vízszintesen, követik a 12-faktoros alkalmazások elveit, lehetővé teszik az automatikus megszakítók (circuit breaker) és a káoszmajmok (chaos monkeys) használatát.
A Kafka, amely a másik oldalon található, lényegében elosztott adatbázisként működik. Így a munka során állapottal kell foglalkoznia, ami sokkal nehezebb, mint egy mikroszolgáltatás. A Kubernetes támogatja az állapotot megőrző terheléseket, de ahogy Kelsey Hightower két tweetjében is megjegyzi, ezekkel óvatosan kell bánni:
Néhányan úgy vélik, hogy ha Kubernetes-t alkalmaznak egy állapotot megőrző terhelésre, akkor az teljesen kezelhető adatbázissá alakul, amely versenyezni tud az RDS-sel. Ez nem igaz. Lehet, hogy ha elég keményen dolgozunk, további komponenseket csatlakoztatunk, és SRE mérnök csapatot vonunk be, akkor sikerülhet az RDS-t Kubernetes fölé telepíteni.
Mindig azt javaslom mindenkinek, hogy rendkívül óvatosan járjon el, amikor állapotot megőrző terheléseket indít a Kubernetes-en. A legtöbb, aki azt kérdezi, "el tudom-e indítani az állapotot megőrző terheléseket a Kubernetes-en", nincs elegendő tapasztalata a Kubernetes használatában, és gyakran még a terheléssel kapcsolatban is, amiről kérdeznek.
Tehát kell-e a Kafkát Kubernetes-en futtatni? A viszontkérdés: jobban fog működni a Kafka Kubernetes nélkül? Éppen ezért szeretném hangsúlyozni ebben a cikkben, hogy a Kafka és a Kubernetes hogyan egészítik ki egymást, és milyen csapdákba lehet belefutni a kombinációjuk során.
Kibővített futási idő
Beszéljünk az alapvető dologról — a futási környezetről mint olyanról
Folyamat
A Kafka brókerek jól teljesítenek CPU terhelésnél. A TLS némi költséget is bevihet. Ugyanakkor a Kafka kliensek jobban megterhelhetik a CPU-t, ha titkosítást használnak, de ez nem befolyásolja a brókereket.
Memória
A Kafka brókerek memóriaigényesek. A JVM halomméretét általában 4–5 GB-ra szokás korlátozni, de sok rendszer memória is szükséges, mivel a Kafka aktívan használja az oldalkészletet. Kubernetes alatt megfelelően állítsa be a konténerre a forráshatárokat és a kéréseket.
Adat tárolás
Az adat tárolás a konténerekben efemer — az adatok elvesznek a újraindítás során. A Kafka adataihoz kötetet használhatunk, emptyDir, és a hatás hasonló lesz: a bróker adatai elvesznek a leállítás során. Az üzeneteid azonban más brókereken replikációként megmaradhatnak. Ezért a leállt brókernek először replikálnia kell az összes adatot, ami időbe telhet.
Ezért kell tartós adat tárolást használni. Legyen ez egy nem helyi tartós tárolás XFS fájlrendszerrel vagy, pontosabban, ext4-el. Ne használjon NFS-t. Figyelmeztettem. Az NFS v3 vagy v4 verziók nem fognak működni. Röviden: a Kafka bróker leáll, ha nem tudja törölni az adatokat a 'butaságok átnevezése' problémája miatt, ami az NFS-re vonatkozik. Ha eddig még nem győztelek meg, olvasd el nagyon figyelmesen . Az adat tárolásnak nem helyinek kell lennie, hogy a Kubernetes rugalmasabban választhassa ki az új csomópontot újraindítás vagy relokáció után.
Hálózat
Mint a legtöbb elosztott rendszerhez hasonlóan, a Kafka teljesítménye is erősen függ attól, hogy a hálózati késleltetések minimálisak, míg a sávszélesség maximális. Ne próbálja meg az összes brókert ugyanarra a csomópontjára helyezni, mivel ezzel csökken a rendelkezésre állás. Ha egy Kubernetes-csomópont leáll, akkor az egész Kafka klaszter is leáll. Emellett ne terjessze a Kafka klasztert külön adatközpontokra sem. Ugyanez vonatkozik a Kubernetes klaszterre is. Jó kompromisszum lehet, ha különböző elérhetőségi zónákat választ.
Konfiguráció
Szokásos manifestek
A Kubernetes weboldalán található arról, hogyan lehet a ZooKeeper-t manifestek segítségével beállítani. Mivel a ZooKeeper a Kafka részét képezi, ezzel kényelmes elkezdeni megismerkedni azokkal a Kubernetes koncepciókkal, amelyek itt alkalmazhatók. Miután megértette ezt, azonos koncepciókat alkalmazhat a Kafka klaszterhez is.
- A: a pod a Kubernetes legkisebb telepíthető egysége. A pod tartalmazza a munkaterhelését, és a pod megfelel a klaszterében lévő folyamatnak. A podban egy vagy több konténer található. Minden ZooKeeper szerver az egyesületben és minden broker a Kafka klaszterben különálló podban működik.
- StatefulSet: A StatefulSet egy Kubernetes-objektum, amely többszörös állapotmegőrző munkaterhelésekkel dolgozik, és az ilyen munkaterhelések koordinációt igényelnek. A StatefulSet garantálja a podok sorrendjét és egyediségét.
- Headless-szolgáltatások: A szolgáltatások lehetővé teszik a podok elválasztását az ügyfelektől logikai név használatával. A Kubernetes ebben az esetben felel a terheléskiegyenlítésért. Azonban állapotot megőrző munkaterhelések esetén, mint a ZooKeeper és Kafka, az ügyfeleknek információt kell cserélniük egy adott példánnyal. Itt hasznosak a headless-szolgáltatások: ebben az esetben az ügyfélnek továbbra is lesz logikai neve, de közvetlenül a podhoz nem szükséges fordulni.
- Tartós tároló: ilyen tárolók szükségesek a fent említett nem helyi blokkos hosszú távú tárolási konfigurációhoz.
Ezen teljes körű manifest csomagot biztosít, amellyel kényelmesen elkezdheti a Kafka használatát a Kubernetes-en.
Helm-diagramok
A Helm a Kubernetes csomagkezelője, amelyet az operációs rendszerekhez készült csomagkezelőkhöz, például yum, apt, Homebrew vagy Chocolatey hasonlíthatunk. Segítségével kényelmesen telepíthetjük a Helm-diagramokban leírt előre definiált szoftvercsomagokat. Egy jól megírt Helm-diagram megkönnyíti a bonyolult feladatot: hogyan konfiguráljuk helyesen az összes paramétert a Kafka Kubernetes-en való használatához. Több Kafka-diagram is létezik: az egyik hivatalos, amely a , van egy a , egy másik pedig a .
Operátorok
Mivel a Helm-nek bizonyos hátrányai vannak, egyre népszerűbbé válik egy másik eszköz: a Kubernetes operátorok. Az operátor nemcsak a szoftver csomagolásáért felelős a Kubernetes-hez, hanem lehetővé teszi a szoftver telepítését és kezelését is.
A listájában említést nyer két operátor a Kafka számára. Az egyikük a . A Strimzi segítségével pár perc alatt felállítható a Kafka klaszter. Szinte semmilyen konfigurációra nincs szükség, ráadásul maga az operátor néhány kellemes funkciót is nyújt, például a TLS titkosítást a klaszteren belül. A Confluent szintén biztosít .
Teljesítmény
Nagyon fontos az teljesítmény tesztelése, ha van telepített Kafka példányod, hogy ellenőrző pontokkal biztosítsd a működést. Az ilyen tesztek segítenek felfedezni a potenciális szűk keresztmetszeteket, még mielőtt problémák merülnének fel. Szerencsére a Kafka két eszközt is biztosít a teljesítmény tesztelésére: kafka-producer-perf-test.sh és kafka-consumer-perf-test.sh. Használjatok őket aktívan. Referenciaként ellenőrizhetitek a Jay Kreps által írt erre a felmérésre A működés
Átláthatóság a rendszerben nagyon fontos – különben nem fogod tudni, mi történik benne. Ma már van egy szilárd eszközkészlet, amely a cloud-native stílusú metrikákra épülő monitorozást biztosít. Két népszerű eszköz erre a célra a Prometheus és a Grafana. A Prometheus képes összegyűjteni a metrikákat az összes Java (Kafka, Zookeeper, Kafka Connect) folyamatból JMX exportáló segítségével – a legegyszerűbb módon. Ha hozzáadjuk a cAdvisor metrikáit, teljesebb képet kaphatunk arról, hogyan használják a Kubernetesben a forrásokat.
Monitorozás
Átláthatóság a rendszerben nagyon fontos – különben nem fogod tudni, mi történik benne. Ma már van egy szilárd eszközkészlet, amely a cloud-native stílusú metrikákra épülő monitorozást biztosít. Két népszerű eszköz erre a célra a Prometheus és a Grafana. A Prometheus képes összegyűjteni a metrikákat az összes Java (Kafka, Zookeeper, Kafka Connect) folyamatból JMX exportáló segítségével – a legegyszerűbb módon. Ha hozzáadjuk a cAdvisor metrikáit, teljesebb képet kaphatunk arról, hogyan használják a Kubernetesben a forrásokat.
A Strimzi nagyon kényelmes Grafana irányítópult példát kínál a Kafka számára. Ez vizualizálja a kulcsfontosságú metrikákat, például a nem replikált szektorokról vagy az offline szektorokról. Minden nagyon világos. Ezeket a metrikákat kiegészítik a források felhasználásának és a teljesítménynek az adatai, valamint a stabilitási mutatók. Így egy alap Kafka klaszter monitort kap ingyen!
Forrás:
Mindehhez jól jönne a kliensek nyomon követése (metrikák a fogyasztókról és a termelőkről), valamint a késleltetési monitoring (ehhez van ) és az átfogó monitorozás – ehhez használja a .
Naplózás
A naplózás egy másik nagyon fontos feladat. Győződjön meg róla, hogy minden konténer a Kafka telepítésében naplózva van stdout és stderr, és gondoskodjon róla, hogy a Kubernetes klasztere összesítse az összes naplót egy központi naplózási infrastruktúrába, például .
Szervizellenőrzés
A Kubernetes élő (liveness) és készenléti (readiness) ellenőrző pontokat használ, hogy eldöntse, normálisan működnek-e a podjai. Ha az élő ellenőrzés nem sikerül, a Kubernetes leállítja ezt a konténert, majd automatikusan újraindítja, ha a visszaállítási szabályzat megfelelően van beállítva. Ha a készenléti ellenőrzés nem sikerül, akkor a Kubernetes elkülöníti ezt a podot a kérdések kiszolgálásától. Így ezekben az esetekben már nincs szükség manuális beavatkozásra, ami nagy előny.
Frissítések kiadása
A StatefulSet-ek támogatják az automatikus frissítéseket: a RollingUpdate stratégia kiválasztásakor minden Kafka pod egyesével frissül. Így minimalizálhatja a leállások időtartamát.
Skálázhatóság
A Kafka klaszter skálázása nem egyszerű feladat. Azonban a Kubernetes nagyon egyszerűvé teszi a podok skálázását egy meghatározott számú replikára, ami azt jelenti, hogy deklaratívan meghatározhat annyi Kafka brókert, amennyit csak kíván. A legnehezebb ebben az esetben a szektorok újbóli hozzárendelése a felfelé történő skálázás után vagy lefelé történő skálázás előtt. Ismét, a Kubernetes segít ebben a feladatban.
Adminisztráció
A feladatok, amelyek a Kafka klaszterének adminisztrálásával kapcsolatosak, különösen a témák létrehozása és a szektorok átvitele, elvégezhetők a rendelkezésre álló shell scriptjeink segítségével, a parancssori interfész megnyitásával a podjainkban. Azonban ez a megoldás nem túl szép. A Strimzi egy másik operátor segítségével támogatja a témák kezelését. Itt van mit még tökéletesíteni.
Biztonsági mentés és helyreállítás
Ezért a Kafka rendelkezésre állása most már a Kubernetes rendelkezésre állásától is függ. Ha a Kubernetes klasztered leáll, a legrosszabb esetben a Kafka klasztered is le fog állni. Murphy törvénye szerint ez biztosan meg fog történni, és adatokat veszítesz. Az ilyen típusú kockázat csökkentése érdekében alaposan dolgozd ki a biztonsági mentési koncepciót. Használhatod a MirrorMakert, egy másik lehetőség S3 használata, ahogyan ezt a Zalando-tól.
Zárás
Kis vagy közepes méretű Kafka klasztereknél mindenképpen érdemes Kubernetes-t használni, mivel ez további rugalmasságot biztosít és megkönnyíti a működtetők munkáját. Ha nagyon komoly nem funkcionális követelmények vannak a késleltetésre és/vagy a sávszélességre vonatkozóan, lehet, hogy érdemes egy másik telepítési lehetőséget fontolóra venni.
Forrás: habr.com
