Är Kafka på Kubernetes bra?

Hälsningar, Habr!

En gång var vi de första som introducerade ämnet på den ryska marknaden kafka och fortsätt Spår för dess utveckling. I synnerhet hittade vi ämnet interaktion mellan Kafka och Kubernetes. Observerbar (och ganska försiktig) artikel detta ämne publicerades på Confluent-bloggen i oktober förra året under författarskapet av Gwen Shapira. Idag vill vi uppmärksamma er på en nyare artikel från april av Johann Gyger, som, även om det inte saknas ett frågetecken i rubriken, undersöker ämnet på ett mer innehållsrikt sätt och åtföljer texten med intressanta länkar. Förlåt oss den fria översättningen av "kaos apa" om du kan!

Inledning

Kubernetes är utformad för att hantera tillståndslösa arbetsbelastningar. Vanligtvis presenteras sådana arbetsbelastningar i form av en mikrotjänstarkitektur, de är lätta, skalas väl horisontellt, följer principerna för 12-faktorapplikationer och kan fungera med strömbrytare och kaosapor.

Kafka, å andra sidan, fungerar i huvudsak som en distribuerad databas. När du arbetar måste du alltså ta itu med staten, och det är mycket tyngre än en mikrotjänst. Kubernetes stöder statistiska laddningar, men som Kelsey Hightower påpekar i två tweets bör de hanteras med försiktighet:

Vissa människor känner att om du rullar Kubernetes till en tillståndsfull arbetsbelastning, blir det en fullständigt hanterad databas som konkurrerar med RDS. Detta är fel. Kanske, om du arbetar tillräckligt hårt, lägger till ytterligare komponenter och attraherar ett team av SRE-ingenjörer, kommer du att kunna bygga RDS ovanpå Kubernetes.

Jag rekommenderar alltid att alla iakttar extrem försiktighet när de kör tillståndsfulla arbetsbelastningar på Kubernetes. De flesta som frågar "kan jag köra tillståndsfulla arbetsbelastningar på Kubernetes" har inte tillräckligt med erfarenhet av Kubernetes, och ofta med den arbetsbelastning de frågar om.

Så, ska du köra Kafka på Kubernetes? Motfråga: kommer Kafka att fungera bättre utan Kubernetes? Därför vill jag i den här artikeln lyfta fram hur Kafka och Kubernetes kompletterar varandra, och vilka fallgropar som kan komma med att kombinera dem.

Tidpunkt för färdigställande

Låt oss prata om det grundläggande - själva runtime-miljön

process

Kafka-mäklare är CPU-vänliga. TLS kan införa vissa overhead. Kafka-klienter kan dock vara mer CPU-intensiva om de använder kryptering, men detta påverkar inte mäklare.

Память

Kafka-mäklare äter upp minnet. JVM-högstorleken är vanligtvis begränsad till 4-5 GB, men du kommer också att behöva mycket systemminne eftersom Kafka använder sidcachen väldigt hårt. I Kubernetes ställer du in behållaresurs- och begärangränser i enlighet med detta.

Datalagring

Datalagring i behållare är tillfällig - data går förlorad när den startas om. För Kafka-data kan du använda en volym emptyDir, och effekten blir liknande: dina mäklardata kommer att gå förlorade efter slutförandet. Dina meddelanden kan fortfarande lagras på andra mäklare som repliker. Därför, efter en omstart, måste den misslyckade mäklaren först replikera all data, och denna process kan ta mycket tid.

Det är därför du bör använda långtidslagring av data. Låt det vara icke-lokal långtidslagring med XFS-filsystemet eller, mer exakt, ext4. Använd inte NFS. Jag varnade dig. NFS versioner v3 eller v4 kommer inte att fungera. Kort sagt, Kafka-mäklaren kommer att krascha om den inte kan radera datakatalogen på grund av problemet med "dumt byta namn" i NFS. Om jag inte har övertygat dig än, mycket noga läs den här artikeln. Datalagret bör vara icke-lokalt så att Kubernetes mer flexibelt kan välja en ny nod efter en omstart eller omlokalisering.

Сеть

Som med de flesta distribuerade system är Kafkas prestanda starkt beroende av att hålla nätverkslatens på ett minimum och bandbredd på maximalt. Försök inte att vara värd för alla mäklare på samma nod, eftersom detta kommer att minska tillgängligheten. Om en Kubernetes-nod misslyckas kommer hela Kafka-klustret att misslyckas. Sprid inte heller Kafka-klustret över hela datacenter. Detsamma gäller Kubernetes-klustret. En bra kompromiss i det här fallet är att välja olika tillgänglighetszoner.

konfiguration

Regelbundna manifest

Kubernetes webbplats har mycket bra guide om hur man konfigurerar ZooKeeper med hjälp av manifest. Eftersom ZooKeeper är en del av Kafka är det här ett bra ställe att börja för att bli bekant med vilka Kubernetes-koncept som gäller här. När du väl förstår detta kan du använda samma koncept med ett Kafka-kluster.

• nedanför: En pod är den minsta utplacerbara enheten i Kubernetes. En pod innehåller din arbetsbelastning, och själva podden motsvarar en process i ditt kluster. En pod innehåller en eller flera behållare. Varje ZooKeeper-server i ensemblen och varje mäklare i Kafka-klustret kommer att köras i en separat pod.
• StatefulSet: En StatefulSet är ett Kubernetes-objekt som hanterar flera statistiska arbetsbelastningar, och sådana arbetsbelastningar kräver samordning. StatefulSets ger garantier angående beställning av poddar och deras unika karaktär.
• Huvudlösa tjänster: Tjänster låter dig koppla bort pods från klienter med ett logiskt namn. Kubernetes ansvarar i detta fall för lastbalansering. Men när man använder statistiska arbetsbelastningar, som ZooKeeper och Kafka, måste klienter kommunicera med en specifik instans. Det är här huvudlösa tjänster kommer väl till pass: i det här fallet kommer klienten fortfarande att ha ett logiskt namn, men du behöver inte kontakta podden direkt.
• Långtidslagringsvolym: Dessa volymer behövs för att konfigurera den icke-lokala blockbeständiga lagringen som nämns ovan.

På Yolean Tillhandahåller en omfattande uppsättning manifest som hjälper dig att komma igång med Kafka på Kubernetes.

Hjälmdiagram

Helm är en pakethanterare för en Kubernetes som kan jämföras med OS-pakethanterare som yum, apt, Homebrew eller Chocolatey. Det gör det enkelt att installera fördefinierade programvarupaket som beskrivs i Helm-diagram. Ett väl valt styrdiagram gör den svåra uppgiften att korrekt konfigurera alla parametrar för att använda Kafka på Kubernetes lätt. Det finns flera Kafka-diagram: det officiella finns i inkubatorskick, det finns en från Konfluenta, en till - från Bitnami.

operatörer

Eftersom Helm har vissa brister, vinner ett annat verktyg avsevärd popularitet: Kubernetes-operatörer. Operatören paketerar inte bara programvara för Kubernetes, utan låter dig också distribuera sådan programvara och hantera den.

I listan fantastiska operatörer Två operatörer för Kafka nämns. En av dem - Strimzi. Med Strimzi är det enkelt att få igång ditt Kafka-kluster på några minuter. Praktiskt taget ingen konfiguration krävs, dessutom tillhandahåller operatören själv några trevliga funktioner, till exempel punkt-till-punkt TLS-kryptering inom klustret. Confluent ger också egen operatör.

Производительность

Det är viktigt att testa prestanda genom att benchmarka din Kafka-instans. Sådana tester hjälper dig att hitta potentiella flaskhalsar innan problemen börjar. Lyckligtvis tillhandahåller Kafka redan två prestandatestverktyg: kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. Använd dem aktivt. Som referens kan du hänvisa till resultaten som beskrivs i den här posten Jay Kreps, eller fokusera på denna recension Amazon MSK av Stéphane Maarek.

operationer

övervakning

Transparens i systemet är väldigt viktigt – annars förstår du inte vad som händer i det. Idag finns det en gedigen verktygslåda som ger mätvärdesbaserad övervakning i molnets stil. Två populära verktyg för detta ändamål är Prometheus och Grafana. Prometheus kan samla in mätvärden från alla Java-processer (Kafka, Zookeeper, Kafka Connect) med hjälp av en JMX-exportör – på det enklaste sättet. Om du lägger till cAdvisor-statistik kan du bättre förstå hur resurser används i Kubernetes.

Strimzi har ett mycket bekvämt exempel på en Grafana-instrumentbräda för Kafka. Den visualiserar nyckelmått, till exempel om underreplikerade sektorer eller de som är offline. Allt är väldigt tydligt där. Dessa mätvärden kompletteras med information om resursutnyttjande och prestanda, samt stabilitetsindikatorer. Så du får grundläggande Kafka-klusterövervakning för ingenting!

Källa: streamzi.io/docs/master/#kafka_dashboard

Det skulle vara trevligt att komplettera allt detta med kundövervakning (mått på konsumenter och producenter), samt latensövervakning (för detta finns Håla) och end-to-end-övervakning - för denna användning Kafka monitor.

Skogsavverkning

Loggning är en annan viktig uppgift. Se till att alla behållare i din Kafka-installation är inloggade stdout и stderr, och se även till att ditt Kubernetes-kluster samlar alla loggar till en central loggningsinfrastruktur, t.ex. Elasticsearch.

Funktionalitetskontroll

Kubernetes använder liveness- och beredskapssonder för att kontrollera om dina pods fungerar normalt. Om liveness-kontrollen misslyckas kommer Kubernetes att stoppa den behållaren och sedan automatiskt starta om den om omstartspolicyn är inställd i enlighet därmed. Om beredskapskontrollen misslyckas, isolerar Kubernetes poden från serviceförfrågningar. I sådana fall krävs alltså inte längre manuella ingrepp alls, vilket är ett stort plus.

Utrullar uppdateringar

StatefulSets stöder automatiska uppdateringar: om du väljer RollingUpdate-strategin kommer var och en under Kafka att uppdateras i tur och ordning. På så sätt kan stilleståndstiden reduceras till noll.

Skalning

Att skala ett Kafka-kluster är inte en lätt uppgift. Kubernetes gör det dock väldigt enkelt att skala pods till ett visst antal repliker, vilket innebär att du deklarativt kan definiera hur många Kafka-mäklare du vill. Det svåraste i det här fallet är att omtilldela sektorer efter uppskalning eller innan nedskalning. Återigen, Kubernetes hjälper dig med den här uppgiften.

administration

Uppgifter relaterade till att administrera ditt Kafka-kluster, som att skapa ämnen och omtilldela sektorer, kan utföras med befintliga skalskript genom att öppna kommandoradsgränssnittet i dina poddar. Denna lösning är dock inte särskilt vacker. Strimzi stöder hantering av ämnen med en annan operatör. Det finns en del utrymme för förbättringar här.

Säkerhetskopiering och återställning

Nu kommer tillgången på Kafka också att bero på tillgången på Kubernetes. Om ditt Kubernetes-kluster misslyckas, kommer i värsta fall även ditt Kafka-kluster att misslyckas. Enligt Murphys lag kommer detta definitivt att hända, och du kommer att förlora data. För att minska denna typ av risk, ha ett bra backup-koncept. Du kan använda MirrorMaker, ett annat alternativ är att använda S3 för detta, som beskrivs i detta posta från Zalando.

Slutsats

När du arbetar med små till medelstora Kafka-kluster är det definitivt värt att använda Kubernetes eftersom det ger ytterligare flexibilitet och förenklar operatörsupplevelsen. Om du har mycket betydande icke-funktionella latens- och/eller genomströmningskrav, kan det vara bättre att överväga något annat distributionsalternativ.

Källa: will.com