Zdravím tě, Habr!
Svého času jsme jako první uvedli téma na ruský trh a pokračovat pro jeho rozvoj. Zejména jsme našli téma interakce mezi Kafkou a . Pozorovatelné (a docela opatrné) toto téma bylo publikováno na blogu Confluent již v říjnu minulého roku pod autorstvím Gwen Shapira. Dnes bychom vás rádi upozornili na novější článek z dubna od Johanna Gygera, který, i když není bez otazníku v názvu, zkoumá téma věcněji a doprovází text zajímavými odkazy. Odpusťte nám prosím volný překlad „opice chaosu“, pokud můžete!
úvod
Kubernetes je navržen tak, aby zvládal bezstavovou zátěž. Obvykle jsou takové pracovní zátěže prezentovány ve formě mikroservisní architektury, jsou lehké, dobře horizontálně škálovatelné, dodržují principy 12faktorových aplikací a mohou pracovat s jističi a chaosovými opicemi.
Kafka naproti tomu v podstatě funguje jako distribuovaná databáze. Při práci se tedy musíte vypořádat se stavem a je mnohem těžší než mikroservis. Kubernetes podporuje stavová zatížení, ale jak Kelsey Hightower zdůrazňuje ve dvou tweetech, mělo by se s nimi zacházet opatrně:
Někteří lidé mají pocit, že pokud Kubernetes převedete do stavové zátěže, stane se plně spravovanou databází, která konkuruje RDS. To je špatně. Možná, pokud budete dostatečně tvrdě pracovat, přidáte další komponenty a přilákáte tým inženýrů SRE, budete moci postavit RDS na Kubernetes.
Vždy doporučuji, aby všichni byli extrémně opatrní při spouštění stavových úloh na Kubernetes. Většina lidí, kteří se ptají „mohu spustit stavové úlohy na Kubernetes“, nemá dostatek zkušeností s Kubernetes a často s pracovní zátěží, na kterou se ptají.
Měli byste tedy spustit Kafku na Kubernetes? Protiotázka: bude Kafka fungovat lépe bez Kubernetes? Proto chci v tomto článku upozornit na to, jak se Kafka a Kubernetes doplňují a jaká úskalí může přinést jejich kombinace.
Čas dokončení
Pojďme se bavit o tom základním – samotném runtime prostředí
Proces
Makléři Kafka jsou přátelští k CPU. TLS může představovat určitou režii. Klienti Kafka však mohou být náročnější na CPU, pokud používají šifrování, to však nemá vliv na brokery.
Vzpomínka
Makléři Kafka žerou paměť. Velikost haldy JVM je obvykle omezena na 4–5 GB, ale budete potřebovat také hodně systémové paměti, protože Kafka velmi intenzivně využívá mezipaměť stránek. V Kubernetes odpovídajícím způsobem nastavte limity prostředků kontejneru a požadavků.
Úložiště dat
Ukládání dat v kontejnerech je pomíjivé – data se při restartu ztratí. Pro data Kafka můžete použít svazek emptyDira efekt bude podobný: po dokončení budou vaše data brokera ztracena. Vaše zprávy mohou být stále uloženy u jiných brokerů jako repliky. Po restartu tedy musí neúspěšný broker nejprve replikovat všechna data a tento proces může zabrat spoustu času.
To je důvod, proč byste měli používat dlouhodobé ukládání dat. Ať je to nelokální dlouhodobé úložiště se souborovým systémem XFS nebo přesněji ext4. Nepoužívejte NFS. Varoval jsem tě. Verze NFS v3 nebo v4 nebudou fungovat. Zkrátka broker Kafka spadne, pokud nedokáže smazat datový adresář kvůli problému s "hloupým přejmenováním" v NFS. Pokud jsem vás ještě nepřesvědčil, velmi opatrně . Datové úložiště by mělo být nelokální, aby si Kubernetes mohl po restartu nebo přemístění flexibilněji vybrat nový uzel.
Síť
Stejně jako u většiny distribuovaných systémů je výkon Kafky vysoce závislý na udržení síťové latence na minimu a šířky pásma na maximu. Nesnažte se hostovat všechny brokery na stejném uzlu, protože to sníží dostupnost. Pokud selže uzel Kubernetes, selže celý cluster Kafka. Také nerozšiřujte cluster Kafka do celých datových center. Totéž platí pro cluster Kubernetes. Dobrým kompromisem je v tomto případě volba různých zón dostupnosti.
Konfigurace
Pravidelné manifesty
Web Kubernetes má o tom, jak nakonfigurovat ZooKeeper pomocí manifestů. Vzhledem k tomu, že ZooKeeper je součástí Kafky, je to dobré místo, kde se můžete seznámit s tím, které koncepty Kubernetes zde platí. Jakmile to pochopíte, můžete použít stejné koncepty s Kafkovým clusterem.
- Pod: Pod je nejmenší nasaditelná jednotka v Kubernetes. Pod obsahuje vaši pracovní zátěž a samotný modul odpovídá procesu ve vašem clusteru. Pod obsahuje jednu nebo více nádob. Každý server ZooKeeper v souboru a každý broker v clusteru Kafka poběží v samostatném modulu.
- StatefulSet: StatefulSet je objekt Kubernetes, který zpracovává více stavových úloh a takové úlohy vyžadují koordinaci. StatefulSets poskytují záruky ohledně objednání podů a jejich jedinečnosti.
- Bezhlavé služby: Služby vám umožňují odpojit moduly od klientů pomocí logického názvu. Kubernetes je v tomto případě zodpovědný za vyrovnávání zátěže. Při provozu stavových úloh, jako jsou ZooKeeper a Kafka, však klienti potřebují komunikovat s konkrétní instancí. Zde se hodí bezhlavé služby: v tomto případě bude mít klient stále logické jméno, ale nebudete muset přímo kontaktovat modul.
- Objem dlouhodobého skladování: Tyto svazky jsou potřebné ke konfiguraci nelokálního blokového trvalého úložiště uvedeného výše.
Na Poskytuje komplexní sadu manifestů, které vám pomohou začít s Kafkou na Kubernetes.
Tabulky kormidla
Helm je správce balíčků pro Kubernetes, který lze přirovnat ke správcům balíčků OS, jako je yum, apt, Homebrew nebo Chocolatey. Usnadňuje instalaci předdefinovaných softwarových balíků popsaných v grafech Helm. Dobře zvolený Helmův diagram usnadňuje obtížný úkol, jak správně nakonfigurovat všechny parametry pro použití Kafka na Kubernetes. Existuje několik Kafkových diagramů: oficiální je umístěn , existuje jeden z , ještě jeden - od .
Operátoři
Protože Helm má určité nedostatky, získává značnou oblibu další nástroj: operátoři Kubernetes. Operátor software pro Kubernetes nejen zabalí, ale také vám umožní takový software nasadit a spravovat.
Tento seznam Jsou zmíněni dva operátoři pro Kafku. Jeden z nich - . Se Strimzi je snadné uvést váš cluster Kafka do provozu během několika minut. Není potřeba prakticky žádná konfigurace, navíc samotný operátor poskytuje některé příjemné funkce, například point-to-point TLS šifrování v rámci clusteru. Confluent také poskytuje .
Производительность
Je důležité otestovat výkon pomocí benchmarkingu vaší instance Kafka. Takové testy vám pomohou najít potenciální úzká místa dříve, než nastanou problémy. Naštěstí Kafka již poskytuje dva nástroje pro testování výkonu: kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. Aktivně je využívejte. Pro referenci se můžete podívat na výsledky popsané v Jay Kreps, nebo se soustřeďte Amazon MSK od Stéphana Maareka.
Operace
Sledování
Transparentnost v systému je velmi důležitá – jinak nepochopíte, co se v něm děje. Dnes existuje solidní sada nástrojů, která poskytuje monitorování na základě metrik v cloudovém nativním stylu. Dva oblíbené nástroje pro tento účel jsou Prometheus a Grafana. Prometheus dokáže shromažďovat metriky ze všech procesů Java (Kafka, Zookeeper, Kafka Connect) pomocí JMX exportéru – tím nejjednodušším způsobem. Pokud přidáte metriky cAdvisor, můžete lépe porozumět tomu, jak se v Kubernetes používají prostředky.
Strimzi má pro Kafku velmi vhodný příklad dashboardu Grafana. Vizualizuje klíčové metriky, například o málo replikovaných sektorech nebo těch, které jsou offline. Všechno je tam velmi jasné. Tyto metriky jsou doplněny informacemi o využití zdrojů a výkonu a také ukazateli stability. Základní monitorování clusteru Kafka tedy získáte za nic!
Zdroj:
Bylo by hezké toto vše doplnit o sledování klientů (metriky týkající se spotřebitelů a výrobců) a také sledování latence (k tomu existuje ) a end-to-end monitoring – pro toto použití .
Protokolování
Dalším důležitým úkolem je protokolování. Ujistěte se, že všechny kontejnery ve vaší instalaci Kafka jsou přihlášeny stdout и stderra také zajistěte, aby váš cluster Kubernetes agregoval všechny protokoly do centrální infrastruktury protokolování, např. .
Funkční testování
Kubernetes používá sondy živosti a připravenosti ke kontrole, zda vaše moduly běží normálně. Pokud kontrola životnosti selže, Kubernetes tento kontejner zastaví a poté jej automaticky restartuje, pokud jsou odpovídajícím způsobem nastaveny zásady restartování. Pokud kontrola připravenosti selže, Kubernetes izoluje pod od požadavků na obsluhu. V takových případech tedy odpadá ruční zásah vůbec, což je velké plus.
Zavádění aktualizací
StatefulSets podporují automatické aktualizace: pokud zvolíte strategii RollingUpdate, každá pod Kafkou se bude postupně aktualizovat. Tímto způsobem lze snížit prostoje na nulu.
Měřítko
Škálování Kafkova clusteru není snadný úkol. Kubernetes však velmi usnadňuje škálování podů na určitý počet replik, což znamená, že můžete deklarativně definovat libovolný počet Kafka brokerů, kolik chcete. Nejobtížnější věcí v tomto případě je opětovné přiřazení sektorů po zvětšení nebo před zmenšením. S tímto úkolem vám opět pomůže Kubernetes.
podávání
Úkoly související se správou vašeho clusteru Kafka, jako je vytváření témat a opětovné přiřazení sektorů, lze provádět pomocí existujících skriptů shellu otevřením rozhraní příkazového řádku ve vašich modulech. Toto řešení však není příliš krásné. Strimzi podporuje správu témat pomocí jiného operátora. Zde je určitý prostor pro zlepšení.
Zálohování a obnova
Nyní bude dostupnost Kafky záviset i na dostupnosti Kubernetes. Pokud váš cluster Kubernetes selže, pak v nejhorším případě selže i váš cluster Kafka. Podle Murphyho zákona se to určitě stane a přijdete o data. Chcete-li snížit tento typ rizika, mějte dobrý koncept zálohování. Můžete použít MirrorMaker, další možností je k tomu použít S3, jak je popsáno v tomto ze Zalanda.
Závěr
Při práci s malými až středně velkými clustery Kafka se rozhodně vyplatí používat Kubernetes, protože poskytuje další flexibilitu a zjednodušuje práci operátora. Pokud máte velmi významné nefunkční požadavky na latenci a/nebo propustnost, pak může být lepší zvážit nějakou jinou možnost nasazení.
Zdroj: www.habr.com