Er Kafka på Kubernetes bra?

Hilsen, Habr!

På et tidspunkt var vi de første som introduserte emnet til det russiske markedet Kafka og fortsett spor for sin utvikling. Spesielt fant vi temaet interaksjon mellom Kafka og Kubernetes. Observerbar (og ganske forsiktig) artikkel dette emnet ble publisert på Confluent-bloggen i oktober i fjor under forfatterskapet til Gwen Shapira. I dag vil vi gjøre deg oppmerksom på en nyere artikkel fra april av Johann Gyger, som, selv om han ikke har et spørsmålstegn i tittelen, undersøker emnet på en mer innholdsrik måte, og ledsager teksten med interessante lenker. Vennligst tilgi oss den gratis oversettelsen av "kaos ape" hvis du kan!

Innledning

Kubernetes er designet for å håndtere statsløse arbeidsbelastninger. Vanligvis presenteres slike arbeidsbelastninger i form av en mikrotjenestearkitektur, de er lette, skalerer godt horisontalt, følger prinsippene for 12-faktorapplikasjoner og kan fungere med strømbrytere og kaosaper.

Kafka, på den annen side, fungerer i hovedsak som en distribuert database. Derfor, når du jobber, må du forholde deg til staten, og det er mye tyngre enn en mikrotjeneste. Kubernetes støtter tilstandsfulle belastninger, men som Kelsey Hightower påpeker i to tweets, bør de håndteres med forsiktighet:

Noen mennesker føler at hvis du ruller Kubernetes inn i en stateful arbeidsmengde, blir det en fullstendig administrert database som konkurrerer med RDS. Dette er feil. Kanskje, hvis du jobber hardt nok, legger til flere komponenter og tiltrekker deg et team med SRE-ingeniører, vil du kunne bygge RDS på toppen av Kubernetes.

Jeg anbefaler alltid at alle utviser ekstrem forsiktighet når de kjører tilstandsfulle arbeidsbelastninger på Kubernetes. De fleste som spør «kan jeg kjøre stateful workloads på Kubernetes» har ikke nok erfaring med Kubernetes, og ofte med arbeidsbelastningen de spør om.

Så, bør du kjøre Kafka på Kubernetes? Motspørsmål: vil Kafka fungere bedre uten Kubernetes? Derfor vil jeg i denne artikkelen fremheve hvordan Kafka og Kubernetes utfyller hverandre, og hvilke fallgruver som kan komme med å kombinere dem.

Tidspunkt for ferdigstillelse

La oss snakke om det grunnleggende - selve kjøretidsmiljøet

prosessen

Kafka-meglere er CPU-vennlige. TLS kan introdusere noen overhead. Kafka-klienter kan imidlertid være mer CPU-intensive hvis de bruker kryptering, men dette påvirker ikke meglere.

Память

Kafka-meglere spiser opp hukommelsen. JVM-haugstørrelsen er vanligvis begrenset til 4-5 GB, men du vil også trenge mye systemminne siden Kafka bruker sidebufferen veldig mye. I Kubernetes, sett beholderressurs- og forespørselsgrenser tilsvarende.

Datalager

Datalagring i containere er flyktig - data går tapt ved omstart. For Kafka-data kan du bruke et volum emptyDir, og effekten vil være lik: meglerdataene dine vil gå tapt etter fullføring. Meldingene dine kan fortsatt lagres på andre meglere som replikaer. Derfor, etter en omstart, må den mislykkede megleren først replikere alle data, og denne prosessen kan ta mye tid.

Dette er grunnen til at du bør bruke langsiktig datalagring. La det være ikke-lokal langtidslagring med XFS-filsystemet eller, mer presist, ext4. Ikke bruk NFS. Jeg advarte deg. NFS versjoner v3 eller v4 vil ikke fungere. Kort sagt, Kafka-megleren vil krasje hvis den ikke kan slette datakatalogen på grunn av problemet med "dumt endre navn" i NFS. Hvis jeg ikke har overbevist deg ennå, veldig nøye les denne artikkelen. Datalageret bør være ikke-lokalt slik at Kubernetes mer fleksibelt kan velge en ny node etter omstart eller flytting.

nettverk

Som med de fleste distribuerte systemer, er Kafkas ytelse svært avhengig av å holde nettverksforsinkelsen på et minimum og båndbredden på det maksimale. Ikke prøv å være vert for alle meglere på samme node, da dette vil redusere tilgjengeligheten. Hvis en Kubernetes-node mislykkes, vil hele Kafka-klyngen mislykkes. Ikke spre Kafka-klyngen over hele datasentre. Det samme gjelder Kubernetes-klyngen. Et godt kompromiss i dette tilfellet er å velge forskjellige tilgjengelighetssoner.

Konfigurasjon

Vanlige manifester

Kubernetes-nettstedet har veldig god guide om hvordan du konfigurerer ZooKeeper ved hjelp av manifester. Siden ZooKeeper er en del av Kafka, er dette et godt sted å begynne for å bli kjent med hvilke Kubernetes-konsepter som gjelder her. Når du forstår dette, kan du bruke de samme konseptene med en Kafka-klynge.

• under: En pod er den minste deployerbare enheten i Kubernetes. En pod inneholder arbeidsmengden din, og selve poden tilsvarer en prosess i klyngen din. En pod inneholder en eller flere beholdere. Hver ZooKeeper-server i ensemblet og hver megler i Kafka-klyngen vil kjøre i en separat pod.
• StatefulSet: Et StatefulSet er et Kubernetes-objekt som håndterer flere stateful-arbeidsbelastninger, og slike arbeidsbelastninger krever koordinering. StatefulSets gir garantier angående bestilling av pods og deres unikhet.
• Hodeløse tjenester: Tjenester lar deg koble pods fra klienter ved å bruke et logisk navn. Kubernetes er i dette tilfellet ansvarlig for lastbalansering. Men når de opererer tilstandsfulle arbeidsbelastninger, som ZooKeeper og Kafka, må klienter kommunisere med en spesifikk instans. Det er her hodeløse tjenester kommer godt med: i dette tilfellet vil klienten fortsatt ha et logisk navn, men du trenger ikke kontakte poden direkte.
• Langsiktig lagringsvolum: Disse volumene er nødvendige for å konfigurere den ikke-lokale permanente blokklagringen nevnt ovenfor.

På Yolean Gir et omfattende sett med manifester for å hjelpe deg med å komme i gang med Kafka på Kubernetes.

Hjelmdiagrammer

Helm er en pakkebehandler for en Kubernetes som kan sammenlignes med OS-pakkebehandlere som yum, apt, Homebrew eller Chocolatey. Det gjør det enkelt å installere forhåndsdefinerte programvarepakker beskrevet i Helm-diagrammer. Et velvalgt Helm-diagram gjør den vanskelige oppgaven med å konfigurere alle parameterne riktig for å bruke Kafka på Kubernetes enkelt. Det er flere Kafka-diagrammer: den offisielle er lokalisert i inkubatortilstand, det er en fra kryss, en til - fra Bitnami.

Operatører

Fordi Helm har visse mangler, får et annet verktøy betydelig popularitet: Kubernetes-operatører. Operatøren pakker ikke bare programvare for Kubernetes, men lar deg også distribuere slik programvare og administrere den.

I listen fantastiske operatører To operatører for Kafka er nevnt. En av dem - Strimzi. Med Strimzi er det enkelt å få Kafka-klyngen i gang på få minutter. Det kreves praktisk talt ingen konfigurasjon, i tillegg gir operatøren selv noen fine funksjoner, for eksempel punkt-til-punkt TLS-kryptering i klyngen. Confluent gir også egen operatør.

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

Det er viktig å teste ytelsen ved å benchmarke Kafka-forekomsten din. Slike tester vil hjelpe deg med å finne potensielle flaskehalser før problemer oppstår. Heldigvis har Kafka allerede to ytelsestestverktøy: kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. Bruk dem aktivt. For referanse kan du referere til resultatene beskrevet i denne posten Jay Kreps, eller fokusere på denne anmeldelsen Amazon MSK av Stéphane Maarek.

Operasjoner

overvåking

Åpenhet i systemet er veldig viktig – ellers forstår du ikke hva som skjer i det. I dag er det et solid verktøysett som gir metrikkbasert overvåking i skybasert stil. To populære verktøy for dette formålet er Prometheus og Grafana. Prometheus kan samle inn beregninger fra alle Java-prosesser (Kafka, Zookeeper, Kafka Connect) ved hjelp av en JMX-eksportør – på den enkleste måten. Hvis du legger til cAdvisor-beregninger, kan du bedre forstå hvordan ressurser brukes i Kubernetes.

Strimzi har et veldig praktisk eksempel på et Grafana-dashbord for Kafka. Den visualiserer nøkkeltall, for eksempel om underreplikerte sektorer eller de som er offline. Alt er veldig tydelig der. Disse beregningene er supplert med informasjon om ressursutnyttelse og ytelse, samt stabilitetsindikatorer. Så du får grunnleggende Kafka-klyngeovervåking for ingenting!

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

Det ville vært fint å supplere alt dette med klientovervåking (målinger på forbrukere og produsenter), samt latensovervåking (for dette er det Burrow) og ende-til-ende overvåking - for denne bruken Kafka Monitor.

Hogst

Logging er en annen kritisk oppgave. Sørg for at alle beholdere i Kafka-installasjonen er logget på stdout и stderr, og sørg også for at Kubernetes-klyngen din samler alle logger til en sentral loggingsinfrastruktur, f.eks. Elasticsearch.

Funksjonell testing

Kubernetes bruker liveness- og beredskapsprober for å sjekke om podene dine kjører normalt. Hvis liveness-kontrollen mislykkes, stopper Kubernetes den beholderen og starter den deretter automatisk på nytt hvis omstartspolicyen er angitt tilsvarende. Hvis beredskapskontrollen mislykkes, isolerer Kubernetes poden fra serviceforespørsler. I slike tilfeller er det ikke lenger nødvendig med manuell inngripen i det hele tatt, noe som er et stort pluss.

Utruller oppdateringer

StatefulSets støtter automatiske oppdateringer: hvis du velger RollingUpdate-strategien, vil hver under Kafka oppdateres etter tur. På denne måten kan nedetiden reduseres til null.

skalering

Å skalere en Kafka-klynge er ikke en lett oppgave. Kubernetes gjør det imidlertid veldig enkelt å skalere pods til et visst antall replikaer, noe som betyr at du deklarativt kan definere så mange Kafka-meglere du vil. Det vanskeligste i dette tilfellet er å tildele sektorer på nytt etter oppskalering eller før nedskalering. Igjen, Kubernetes vil hjelpe deg med denne oppgaven.

administrasjon

Oppgaver relatert til å administrere Kafka-klyngen din, for eksempel å lage emner og tildele sektorer på nytt, kan gjøres ved å bruke eksisterende shell-skript ved å åpne kommandolinjegrensesnittet i podene dine. Denne løsningen er imidlertid ikke veldig vakker. Strimzi støtter håndtering av emner ved hjelp av en annen operatør. Det er noe rom for forbedring her.

Sikkerhetskopiering og gjenoppretting

Nå vil tilgjengeligheten til Kafka også avhenge av tilgjengeligheten til Kubernetes. Hvis Kubernetes-klyngen din mislykkes, vil Kafka-klyngen også i verste fall mislykkes. I følge Murphys lov vil dette definitivt skje, og du vil miste data. For å redusere denne typen risiko, ha et godt sikkerhetskopikonsept. Du kan bruke MirrorMaker, et annet alternativ er å bruke S3 til dette, som beskrevet i denne post fra Zalando.

Konklusjon

Når du arbeider med små til mellomstore Kafka-klynger, er det definitivt verdt å bruke Kubernetes, da det gir ekstra fleksibilitet og forenkler operatøropplevelsen. Hvis du har svært betydelige ikke-funksjonelle ventetider og/eller gjennomstrømningskrav, kan det være bedre å vurdere et annet distribusjonsalternativ.

Kilde: www.habr.com