Hilsen, Habr!
På et tidspunkt var vi de første som introduserte emnet til det russiske markedet
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
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
- 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å
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
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
Производительность
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
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:
Det ville vært fint å supplere alt dette med klientovervåking (målinger på forbrukere og produsenter), samt latensovervåking (for dette er det
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.
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
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