Hälsningar, Habr!
En gång var vi de första som introducerade ämnet på den ryska marknaden
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
Сеть
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
- 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å
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
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
Производительность
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
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:
Det skulle vara trevligt att komplettera allt detta med kundövervakning (mått på konsumenter och producenter), samt latensövervakning (för detta finns
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.
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
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