Er Kafka på Kubernetes god?

Hilsen, Habr!

På et tidspunkt var vi de første til at introducere emnet til det russiske marked Kafka og fortsæt spore for dens udvikling. Især fandt vi emnet interaktion mellem Kafka og Kubernetes. Observerbar (og ret forsigtig) artiklen dette emne blev offentliggjort på Confluent-bloggen tilbage i oktober sidste år under forfatterskabet af Gwen Shapira. I dag vil vi gerne henlede din opmærksomhed på en nyere artikel fra april af Johann Gyger, som, skønt ikke uden et spørgsmålstegn i titlen, undersøger emnet på en mere indholdsrig måde og ledsager teksten med interessante links. Tilgiv os venligst den gratis oversættelse af "kaos abe", hvis du kan!

Indledning

Kubernetes er designet til at håndtere statsløse arbejdsbelastninger. Typisk præsenteres sådanne arbejdsbelastninger i form af en mikroservicearkitektur, de er lette, skalerer godt horisontalt, følger principperne for 12-faktor applikationer og kan arbejde med strømafbrydere og kaosaber.

Kafka, på den anden side, fungerer i det væsentlige som en distribueret database. Når du arbejder, skal du altså håndtere staten, og det er meget tungere end en mikroservice. Kubernetes understøtter stateful belastninger, men som Kelsey Hightower påpeger i to tweets, bør de håndteres med forsigtighed:

Nogle mennesker føler, at hvis du ruller Kubernetes ind i en tilstandsfuld arbejdsbyrde, bliver det en fuldt administreret database, der konkurrerer med RDS. Det er forkert. Måske, hvis du arbejder hårdt nok, tilføjer yderligere komponenter og tiltrækker et team af SRE-ingeniører, vil du være i stand til at bygge RDS oven på Kubernetes.

Jeg anbefaler altid, at alle udviser ekstrem forsigtighed, når de kører stateful workloads på Kubernetes. De fleste, der spørger "kan jeg køre stateful workloads på Kubernetes", har ikke nok erfaring med Kubernetes, og ofte med den workload, de spørger om.

Så skal du køre Kafka på Kubernetes? Modspørgsmål: vil Kafka fungere bedre uden Kubernetes? Derfor vil jeg i denne artikel fremhæve, hvordan Kafka og Kubernetes komplementerer hinanden, og hvilke faldgruber der kan komme ved at kombinere dem.

Tidspunkt for færdiggørelse

Lad os tale om det grundlæggende - selve runtime-miljøet

Процесс

Kafka-mæglere er CPU-venlige. TLS kan introducere nogle overhead. Kafka-klienter kan dog være mere CPU-intensive, hvis de bruger kryptering, men dette påvirker ikke mæglere.

Память

Kafka-mæglere æder hukommelsen op. JVM-heapstørrelsen er normalt begrænset til 4-5 GB, men du skal også bruge meget systemhukommelse, da Kafka bruger sidecachen meget kraftigt. I Kubernetes skal du indstille containerressource- og anmodningsgrænser i overensstemmelse hermed.

Datalager

Datalagring i containere er flygtig - data går tabt ved genstart. Til Kafka-data kan du bruge en volumen emptyDir, og effekten vil være den samme: dine mæglerdata vil gå tabt efter færdiggørelsen. Dine beskeder kan stadig gemmes på andre mæglere som replikaer. Derfor skal den mislykkede mægler efter en genstart først replikere alle data, og denne proces kan tage meget tid.

Det er derfor, du bør bruge langtidsdatalagring. Lad det være ikke-lokal langtidslagring med XFS-filsystemet eller mere præcist ext4. Brug ikke NFS. Jeg advarede dig. NFS versioner v3 eller v4 vil ikke fungere. Kort sagt vil Kafka-mægleren gå ned, hvis den ikke kan slette databiblioteket på grund af problemet med "dumt omdøb" i NFS. Hvis jeg ikke har overbevist dig endnu, meget omhyggeligt læs denne artikel. Datalageret bør være ikke-lokalt, så Kubernetes mere fleksibelt kan vælge en ny node efter en genstart eller flytning.

netværk

Som med de fleste distribuerede systemer er Kafkas ydeevne meget afhængig af at holde netværkets latency på et minimum og båndbredden på det maksimale. Forsøg ikke at hoste alle mæglere på den samme node, da dette vil reducere tilgængeligheden. Hvis en Kubernetes-node fejler, vil hele Kafka-klyngen fejle. Spred heller ikke Kafka-klyngen på tværs af hele datacentre. Det samme gælder for Kubernetes-klyngen. Et godt kompromis i dette tilfælde er at vælge forskellige tilgængelighedszoner.

Konfiguration

Regelmæssige manifester

Kubernetes hjemmeside har meget god guide om hvordan man konfigurerer ZooKeeper ved hjælp af manifester. Da ZooKeeper er en del af Kafka, er dette et godt sted at begynde for at blive fortrolig med, hvilke Kubernetes-koncepter, der gælder her. Når du forstår dette, kan du bruge de samme begreber med en Kafka-klynge.

• under: En pod er den mindste deployerbare enhed i Kubernetes. En pod indeholder din arbejdsbyrde, og selve poden svarer til en proces i din klynge. En pod indeholder en eller flere beholdere. Hver ZooKeeper-server i ensemblet og hver mægler i Kafka-klyngen kører i en separat pod.
• StatefulSet: Et StatefulSet er et Kubernetes-objekt, der håndterer flere stateful-arbejdsbelastninger, og sådanne arbejdsbelastninger kræver koordinering. StatefulSets giver garantier vedrørende bestilling af pods og deres unikke karakter.
• Hovedløse tjenester: Tjenester giver dig mulighed for at adskille pods fra klienter ved hjælp af et logisk navn. Kubernetes er i dette tilfælde ansvarlig for belastningsbalancering. Men når klienter betjener stateful workloads, såsom ZooKeeper og Kafka, skal klienter kommunikere med en specifik instans. Det er her, hovedløse tjenester kommer til nytte: i dette tilfælde vil klienten stadig have et logisk navn, men du behøver ikke kontakte poden direkte.
• Langtids opbevaringsvolumen: Disse volumener er nødvendige for at konfigurere den ikke-lokale blok vedvarende lagring nævnt ovenfor.

On Yolean Giver et omfattende sæt af manifester, der hjælper dig med at komme i gang med Kafka på Kubernetes.

Hjelm diagrammer

Helm er en pakkehåndtering til en Kubernetes, der kan sammenlignes med OS-pakkeadministratorer såsom yum, apt, Homebrew eller Chocolatey. Det gør det nemt at installere foruddefinerede softwarepakker beskrevet i Helm-diagrammer. Et velvalgt Helm-diagram gør den vanskelige opgave, hvordan man korrekt konfigurerer alle parametrene til at bruge Kafka på Kubernetes, let. Der er flere Kafka-diagrammer: den officielle er placeret i kuvøse tilstand, der er en fra krydset, en mere - fra BitNami.

operatører

Fordi Helm har visse mangler, vinder et andet værktøj betydelig popularitet: Kubernetes-operatører. Operatøren pakker ikke kun software til Kubernetes, men giver dig også mulighed for at implementere sådan software og administrere den.

På listen fantastiske operatører To operatører for Kafka er nævnt. En af dem - Strimzi. Med Strimzi er det nemt at få din Kafka-klynge op at køre på få minutter. Der kræves stort set ingen konfiguration, derudover giver operatøren selv nogle fine funktioner, for eksempel punkt-til-punkt TLS-kryptering i klyngen. Confluent giver også egen operatør.

Ydelse

Det er vigtigt at teste ydeevnen ved at benchmarke din Kafka-instans. Sådanne tests vil hjælpe dig med at finde potentielle flaskehalse, før der opstår problemer. Heldigvis leverer Kafka allerede to ydelsestestværktøjer: kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. Brug dem aktivt. Som reference kan du henvise til resultaterne beskrevet i dette indlæg Jay Kreps, eller fokus på denne anmeldelse Amazon MSK af Stéphane Maarek.

operationer

overvågning

Gennemsigtighed i systemet er meget vigtigt – ellers forstår du ikke, hvad der sker i det. I dag er der et solidt værktøjssæt, der giver metrik-baseret overvågning i cloud-native stil. To populære værktøjer til dette formål er Prometheus og Grafana. Prometheus kan indsamle metrics fra alle Java-processer (Kafka, Zookeeper, Kafka Connect) ved hjælp af en JMX-eksportør - på den enkleste måde. Hvis du tilføjer cAdvisor-metrics, kan du bedre forstå, hvordan ressourcer bruges i Kubernetes.

Strimzi har et meget praktisk eksempel på et Grafana-dashboard til Kafka. Den visualiserer nøglemålinger, for eksempel om underreplikerede sektorer eller dem, der er offline. Alt er meget tydeligt der. Disse målinger suppleres af ressourceudnyttelse og ydeevneoplysninger samt stabilitetsindikatorer. Så du får grundlæggende Kafka-klyngeovervågning for ingenting!

Kilde: streamzi.io/docs/master/#kafka_dashboard

Det ville være rart at supplere alt dette med klientovervågning (metrics på forbrugere og producenter), samt latensovervågning (til dette er der Burrow) og ende-til-ende overvågning - til denne brug Kafka skærm.

Logning

Logning er en anden kritisk opgave. Sørg for, at alle beholdere i din Kafka-installation er logget på stdout и stderr, og sørg også for, at din Kubernetes-klynge samler alle logfiler i en central logningsinfrastruktur, f.eks. Elasticsearch.

Sundhedstjek

Kubernetes bruger liveness- og parathedsprober til at kontrollere, om dine pods kører normalt. Hvis liveness-kontrollen mislykkes, stopper Kubernetes denne container og genstarter den derefter automatisk, hvis genstartspolitikken er indstillet i overensstemmelse hermed. Hvis beredskabskontrollen mislykkes, isolerer Kubernetes poden fra serviceanmodninger. I sådanne tilfælde er der således slet ikke længere behov for manuel indgriben, hvilket er et stort plus.

Udrulning af opdateringer

StatefulSets understøtter automatiske opdateringer: Hvis du vælger RollingUpdate-strategien, vil hver under Kafka blive opdateret efter tur. På denne måde kan nedetiden reduceres til nul.

Skalering

At skalere en Kafka-klynge er ikke en let opgave. Kubernetes gør det dog meget nemt at skalere pods til et vist antal replikaer, hvilket betyder, at du deklarativt kan definere så mange Kafka-mæglere, som du vil. Det sværeste i dette tilfælde er at omtildele sektorer efter opskalering eller før nedskalering. Igen vil Kubernetes hjælpe dig med denne opgave.

administration

Opgaver relateret til administration af din Kafka-klynge, såsom oprettelse af emner og omfordeling af sektorer, kan udføres ved at bruge eksisterende shell-scripts ved at åbne kommandolinjegrænsefladen i dine pods. Denne løsning er dog ikke særlig smuk. Strimzi understøtter håndtering af emner ved hjælp af en anden operatør. Der er plads til forbedring her.

Backup og genskab

Nu vil tilgængeligheden af ​​Kafka også afhænge af tilgængeligheden af ​​Kubernetes. Hvis din Kubernetes-klynge fejler, vil din Kafka-klynge i værste fald også fejle. Ifølge Murphys lov vil dette helt sikkert ske, og du vil miste data. For at reducere denne type risiko skal du have et godt backup-koncept. Du kan bruge MirrorMaker, en anden mulighed er at bruge S3 til dette, som beskrevet i dette stolpe fra Zalando.

Konklusion

Når du arbejder med små til mellemstore Kafka-klynger, er det bestemt værd at bruge Kubernetes, da det giver ekstra fleksibilitet og forenkler operatøroplevelsen. Hvis du har meget betydelige ikke-funktionelle latens- og/eller gennemløbskrav, kan det være bedre at overveje en anden implementeringsmulighed.

Kilde: www.habr.com