Odredite odgovarajuću veličinu za Kafka klaster u Kubernetesu

Bilješka. prev.: U ovom članku Banzai Cloud dijeli primjer kako se njegovi prilagođeni alati mogu upotrijebiti za lakšu upotrebu Kafke unutar Kubernetesa. Sljedeće upute ilustriraju kako možete odrediti optimalnu veličinu vaše infrastrukture i konfigurirati samu Kafku da postigne potrebnu propusnost.

Apache Kafka je distribuirana streaming platforma za stvaranje pouzdanih, skalabilnih i visokoučinkovitih streaming sustava u stvarnom vremenu. Njegove impresivne mogućnosti mogu se proširiti pomoću Kubernetesa. Za to smo razvili Open Source Kafka operator i alat tzv Supercijevi. Omogućuju vam pokretanje Kafke na Kubernetesu i korištenje njegovih različitih značajki, kao što je fino podešavanje konfiguracije brokera, skaliranje temeljeno na metrici s rebalansom, rack awareness, "soft" (graciozan) izvođenje ažuriranja itd.

Isprobajte Supertubes u svom klasteru:

curl https://getsupertubes.sh | sh и supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>

Ili kontakt dokumentacija. Također možete pročitati o nekim od mogućnosti Kafke, rad s kojim je automatiziran pomoću Supertubesa i Kafka operatora. O njima smo već pisali na blogu:

• O ne! Još jedan Kafka operator za Kubernetes;
• Pratite i upravljajte Kafkom na temelju Prometejeve metrike;
• Podizanje svijesti o Kafki na Kubernetesu;
• Provođenje Apache Kafke preko Istia - mjerilo;
• Klasteri s korisničkom provjerom autentičnosti i kontrolom pristupa s Kafka operatorom;
• Kafka rolling nadogradnja i dinamička konfiguracija na Kubernetesu;
• Filter Envoy protokola za Kafku, mrežasti.

Kada odlučite implementirati Kafka klaster na Kubernetes, vjerojatno ćete se suočiti s izazovom određivanja optimalne veličine temeljne infrastrukture i potrebom za finim podešavanjem vaše Kafka konfiguracije da zadovolji zahtjeve propusnosti. Maksimalna izvedba svakog brokera određena je izvedbom osnovnih infrastrukturnih komponenti, kao što su memorija, procesor, brzina diska, propusnost mreže itd.

U idealnom slučaju, konfiguracija brokera trebala bi biti takva da se svi infrastrukturni elementi koriste do maksimuma. Međutim, u stvarnom životu ova je postavka prilično složena. Vjerojatnije je da će korisnici konfigurirati brokere kako bi maksimalno iskoristili jednu ili dvije komponente (disk, memorija ili procesor). Općenito govoreći, broker pokazuje maksimalnu izvedbu kada njegova konfiguracija dopušta da se najsporija komponenta koristi u najvećoj mjeri. Na taj način možemo dobiti okvirnu sliku opterećenja koje jedan broker može podnijeti.

Teoretski, također možemo procijeniti broj brokera potrebnih za rukovanje određenim opterećenjem. Međutim, u praksi postoji toliko mnogo opcija konfiguracije na različitim razinama da je vrlo teško (ako ne i nemoguće) procijeniti potencijalnu izvedbu određene konfiguracije. Drugim riječima, vrlo je teško planirati konfiguraciju na temelju neke dane izvedbe.

Za korisnike Supertubesa obično koristimo sljedeći pristup: počinjemo s nekom konfiguracijom (infrastruktura + postavke), zatim mjerimo njezinu izvedbu, prilagođavamo postavke brokera i ponovno ponavljamo postupak. To se događa dok se najsporija komponenta infrastrukture u potpunosti ne iskoristi.

Na taj način dobivamo jasniju predodžbu o tome koliko brokera treba klasteru da podnese određeno opterećenje (broj brokera također ovisi o drugim čimbenicima, kao što je minimalni broj replika poruka kako bi se osigurala otpornost, broj particija voditelji itd.). Osim toga, dobivamo uvid u to koje komponente infrastrukture zahtijevaju vertikalno skaliranje.

Ovaj će članak govoriti o koracima koje poduzimamo kako bismo maksimalno iskoristili najsporije komponente u početnim konfiguracijama i izmjerili propusnost Kafka klastera. Vrlo otporna konfiguracija zahtijeva najmanje tri brokera koji rade (min.insync.replicas=3), raspoređenih u tri različite zone pristupačnosti. Za konfiguriranje, skaliranje i nadzor Kubernetes infrastrukture koristimo vlastitu platformu za upravljanje kontejnerima za hibridne oblake - Cjevovod. Podržava on-premise (bare metal, VMware) i pet vrsta oblaka (Alibaba, AWS, Azure, Google, Oracle), kao i bilo koju njihovu kombinaciju.

Razmišljanja o infrastrukturi i konfiguraciji Kafka klastera

Za primjere u nastavku odabrali smo AWS kao pružatelja usluga oblaka i EKS kao Kubernetes distribuciju. Slična konfiguracija može se implementirati pomoću P.K.E. - Kubernetes distribucija iz Banzai Clouda, certificirana od strane CNCF-a.

disk

Amazon nudi razne EBS vrste volumena. U srži gp2 и io1 međutim, postoje SSD diskovi koji osiguravaju visoku propusnost gp2 troši akumulirane kredite (I/O krediti), pa smo preferirali tu vrstu io1, koji nudi dosljednu visoku propusnost.

Vrste instanci

Izvedba Kafke uvelike ovisi o predmemoriji stranica operativnog sustava, tako da su nam potrebne instance s dovoljno memorije za brokere (JVM) i predmemoriju stranica. Primjer c5.2xveliki - dobar početak, budući da ima 16 GB memorije i optimiziran za rad s EBS-om. Nedostatak mu je što može pružiti maksimalnu učinkovitost ne više od 30 minuta svaka 24 sata. Ako vaše radno opterećenje zahtijeva vršnu izvedbu tijekom duljeg vremenskog razdoblja, možda biste trebali razmotriti druge vrste instanci. To je upravo ono što smo učinili, zaustavivši se c5.4xveliki. Omogućuje maksimalnu propusnost 593,75 Mbps. Maksimalna propusnost EBS volumena io1 viši od instance c5.4xveliki, tako da će najsporiji element infrastrukture vjerojatno biti I/O propusnost ove vrste instance (što bi naši testovi opterećenja također trebali potvrditi).

Mreža

Mrežna propusnost mora biti dovoljno velika u usporedbi s performansama VM instance i diska, inače mreža postaje usko grlo. U našem slučaju mrežno sučelje c5.4xveliki podržava brzine do 10 Gb/s, što je znatno više od I/O propusnosti VM instance.

Implementacija posrednika

Brokeri bi trebali biti raspoređeni (planirani u Kubernetesu) na namjenske čvorove kako bi se izbjeglo natjecanje s drugim procesima za CPU, memoriju, mrežu i diskovne resurse.

Java verzija

Logičan izbor je Java 11 jer je kompatibilna s Dockerom u smislu da JVM ispravno određuje procesore i memoriju dostupnu spremniku u kojem se broker izvodi. Znajući da su CPU ograničenja važna, JVM interno i transparentno postavlja broj GC niti i JIT niti. Koristili smo Kafkinu sliku banzaicloud/kafka:2.13-2.4.0, koji uključuje Kafka verziju 2.4.0 (Scala 2.13) na Javi 11.

Ako želite saznati više o Javi/JVM na Kubernetesu, pogledajte naše sljedeće objave:

• Zašto je moja Java aplikacija OOMkilled;
• Kako ispravno odrediti veličinu spremnika za Java 10 aplikacije.

Postavke memorije posrednika

Dva su ključna aspekta konfiguriranja brokerske memorije: postavke za JVM i za Kubernetes pod. Ograničenje memorije postavljeno za pod mora biti veće od maksimalne veličine hrpe tako da JVM ima mjesta za Java metaprostor koji se nalazi u njegovoj vlastitoj memoriji i za predmemoriju stranice operativnog sustava koju Kafka aktivno koristi. U našim smo testovima pokrenuli Kafka brokere s parametrima -Xmx4G -Xms2G, a ograničenje memorije za mahunu bilo je 10 Gi. Imajte na umu da se postavke memorije za JVM mogu automatski dobiti korištenjem -XX:MaxRAMPercentage и -X:MinRAMPercentage, na temelju ograničenja memorije za pod.

Postavke procesora posrednika

Općenito govoreći, performanse možete poboljšati povećanjem paralelizma povećanjem broja niti koje koristi Kafka. Što je više procesora dostupno za Kafku, to bolje. U našem testu započeli smo s ograničenjem od 6 procesora i postupno (kroz iteracije) podigli njihov broj na 15. Osim toga, postavili smo num.network.threads=12 u postavkama brokera za povećanje broja niti koje primaju podatke s mreže i šalju ih. Odmah su otkrili da brokeri sljedbenici ne mogu dovoljno brzo primiti replike, podigli su num.replica.fetchers na 4 kako bi se povećala brzina kojom brokeri sljedbenika repliciraju poruke vođa.

Alat za generiranje opterećenja

Trebali biste osigurati da odabrani generator opterećenja ne ostane bez kapaciteta prije nego što Kafka klaster (koji se uspoređuje) dosegne svoje maksimalno opterećenje. Drugim riječima, potrebno je provesti preliminarnu procjenu mogućnosti alata za generiranje opterećenja, a također odabrati vrste instanci za njega s dovoljnim brojem procesora i memorije. U ovom slučaju, naš će alat proizvesti više opterećenja nego što Kafka klaster može podnijeti. Nakon mnogih eksperimenata, odlučili smo se za tri primjerka c5.4xveliki, od kojih je svaki imao uključen generator.

Benchmarking

Mjerenje učinka je iterativni proces koji uključuje sljedeće faze:

• postavljanje infrastrukture (EKS klaster, Kafka klaster, alat za generiranje opterećenja, kao i Prometheus i Grafana);
• generiranje opterećenja za određeno razdoblje za filtriranje slučajnih odstupanja u prikupljenim pokazateljima učinka;
• prilagođavanje infrastrukture i konfiguracije brokera na temelju promatranih pokazatelja uspješnosti;
• ponavljajući proces dok se ne postigne potrebna razina propusnosti Kafka klastera. U isto vrijeme, mora biti dosljedno ponovljiv i pokazati minimalne varijacije u propusnosti.

Sljedeći odjeljak opisuje korake koji su izvedeni tijekom procesa usporedne analize testnih klastera.

Alat

Sljedeći alati korišteni su za brzu implementaciju osnovne konfiguracije, generiranje opterećenja i mjerenje performansi:

• Banzai Cloud Pipeline za organiziranje EKS klastera iz Amazona c Prometej (za prikupljanje Kafkinih i infrastrukturnih metrika) i grafana (za vizualizaciju ovih metrika). Iskoristili smo prednost integriran в Cjevovod usluge koje pružaju federalni nadzor, centralizirano prikupljanje dnevnika, skeniranje ranjivosti, oporavak od katastrofe, sigurnost na razini poduzeća i još mnogo toga.
• Sangrenel — alat za testiranje opterećenja Kafka klastera.
• Grafana nadzorne ploče za vizualizaciju Kafkine metrike i infrastrukture: Kubernetes Kafka, Izvoznik čvorova.
• Supertubes CLI za najlakši način postavljanja Kafka klastera na Kubernetes. Zookeeper, Kafka operator, Envoy i mnoge druge komponente instalirane su i ispravno konfigurirane za pokretanje Kafka klastera spremnog za proizvodnju na Kubernetesu.
  • Za ugradnju supercijevi CLI koristite priložene upute здесь.

EKS klaster

Pripremite EKS klaster s namjenskim radničkim čvorovima c5.4xveliki u različitim zonama dostupnosti za podove s Kafka brokerima, kao i namjenski čvorovi za generator opterećenja i infrastrukturu za praćenje.

banzai cluster create -f https://raw.githubusercontent.com/banzaicloud/kafka-operator/master/docs/benchmarks/infrastructure/cluster_eks_202001.json

Nakon što se EKS klaster pokrene, omogućite njegovu integraciju usluga praćenja — rasporedit će Prometeja i Grafana u klaster.

Komponente Kafkinog sustava

Instalirajte komponente sustava Kafka (Zookeeper, kafka-operator) u EKS koristeći supertubes CLI:

supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>

Kafkin klaster

Prema zadanim postavkama, EKS koristi EBS volumene tipa gp2, tako da morate stvoriti zasebnu klasu pohrane na temelju volumena io1 za Kafkin klaster:

kubectl create -f - <<EOF
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: kubernetes.io/aws-ebs
parameters:
  type: io1
  iopsPerGB: "50"
  fsType: ext4
volumeBindingMode: WaitForFirstConsumer
EOF

Postavite parametar za brokere min.insync.replicas=3 i implementirajte brokerske blokove na čvorovima u tri različite zone dostupnosti:

supertubes cluster create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f https://raw.githubusercontent.com/banzaicloud/kafka-operator/master/docs/benchmarks/infrastructure/kafka_202001_3brokers.yaml --wait --timeout 600

Teme

Pokrenuli smo tri instance generatora opterećenja paralelno. Svaki od njih piše u svoju temu, odnosno trebamo ukupno tri teme:

supertubes cluster topic create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f -<<EOF
apiVersion: kafka.banzaicloud.io/v1alpha1
kind: KafkaTopic
metadata:
  name: perftest1
spec:
  name: perftest1
  partitions: 12
  replicationFactor: 3
  retention.ms: '28800000'
  cleanup.policy: delete
EOF

supertubes cluster topic create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f -<<EOF
apiVersion: kafka.banzaicloud.io/v1alpha1
kind: KafkaTopic
metadata:
    name: perftest2
spec:
  name: perftest2
  partitions: 12
  replicationFactor: 3
  retention.ms: '28800000'
  cleanup.policy: delete
EOF

supertubes cluster topic create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f -<<EOF
apiVersion: kafka.banzaicloud.io/v1alpha1
kind: KafkaTopic
metadata:
  name: perftest3
spec:
  name: perftest3
  partitions: 12
  replicationFactor: 3
  retention.ms: '28800000'
  cleanup.policy: delete
EOF

Za svaku temu faktor replikacije je 3—minimalna preporučena vrijednost za vrlo dostupne proizvodne sustave.

Alat za generiranje opterećenja

Pokrenuli smo tri kopije generatora opterećenja (svaka je pisala u zasebnoj temi). Za blokove generatora opterećenja trebate postaviti afinitet čvorova tako da budu raspoređeni samo na čvorovima koji su im dodijeljeni:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  labels:
    app: loadtest
  name: perf-load1
  namespace: kafka
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: loadtest
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: loadtest
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: nodepool.banzaicloud.io/name
                operator: In
                values:
                - loadgen
      containers:
      - args:
        - -brokers=kafka-0:29092,kafka-1:29092,kafka-2:29092,kafka-3:29092
        - -topic=perftest1
        - -required-acks=all
        - -message-size=512
        - -workers=20
        image: banzaicloud/perfload:0.1.0-blog
        imagePullPolicy: Always
        name: sangrenel
        resources:
          limits:
            cpu: 2
            memory: 1Gi
          requests:
            cpu: 2
            memory: 1Gi
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30

Imajte na umu nekoliko točaka:

• Generator učitavanja generira poruke duljine 512 bajtova i objavljuje ih Kafki u skupinama od 500 poruka.
• Korištenje argumenta -required-acks=all Objava se smatra uspješnom kada su sve sinkronizirane replike poruke primljene i potvrđene od strane Kafka brokera. To znači da smo u benchmarku mjerili ne samo brzinu voditelja koji primaju poruke, već i njihove sljedbenike koji repliciraju poruke. Svrha ovog testa nije procijeniti brzinu čitanja potrošača (potrošači) nedavno primljene poruke koje još uvijek ostaju u predmemoriji stranice OS-a i njezina usporedba s brzinom čitanja poruka pohranjenih na disku.
• Generator opterećenja pokreće 20 radnika paralelno (-workers=20). Svaki radnik sadrži 5 proizvođača koji dijele vezu radnika s Kafka klasterom. Kao rezultat toga, svaki generator ima 100 proizvođača i svi šalju poruke Kafka klasteru.

Praćenje zdravlja klastera

Tijekom testiranja opterećenja Kafka klastera također smo pratili njegovo zdravlje kako bismo osigurali da nema ponovnih pokretanja modula, da nema nesinkroniziranih replika i maksimalnu propusnost s minimalnim fluktuacijama:

• Generator opterećenja piše standardnu ​​statistiku o broju objavljenih poruka i stopi pogreške. Stopa pogreške trebala bi ostati ista 0,00%.
• Tempomat, implementiran od strane kafka-operatora, pruža nadzornu ploču na kojoj također možemo pratiti stanje klastera. Za pregled ove ploče učinite sljedeće:

  supertubes cluster cruisecontrol show -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file>

• ISR razina (broj "sinkroniziranih" replika) skupljanje i širenje jednaki su 0.

Rezultati mjerenja

3 brokera, veličina poruke - 512 bajtova

S particijama ravnomjerno raspoređenim na tri brokera, uspjeli smo postići izvedbu ~500 Mb/s (otprilike 990 tisuća poruka u sekundi):

Potrošnja memorije JVM virtualnog stroja nije premašila 2 GB:

Propusnost diska dosegla je maksimalnu propusnost I/O čvora na sve tri instance na kojima su posrednici radili:

Iz podataka o korištenju memorije po čvorovima proizlazi da je bufferiranje i keširanje sustava zauzelo ~10-15 GB:

3 brokera, veličina poruke - 100 bajtova

Kako se veličina poruke smanjuje, propusnost pada za otprilike 15-20%: vrijeme potrošeno na obradu svake poruke utječe na to. Osim toga, opterećenje procesora se gotovo udvostručilo.

Budući da posrednički čvorovi još uvijek imaju neiskorištene jezgre, performanse se mogu poboljšati promjenom Kafka konfiguracije. Ovo nije lak zadatak, pa je za povećanje propusnosti bolje raditi s većim porukama.

4 brokera, veličina poruke - 512 bajtova

Možete jednostavno povećati performanse Kafka klastera jednostavnim dodavanjem novih brokera i održavanjem ravnoteže particija (ovo osigurava da je opterećenje ravnomjerno raspoređeno između brokera). U našem slučaju, nakon dodavanja brokera, propusnost klastera se povećala na ~580 Mb/s (~1,1 milijuna poruka u sekundi). Pokazalo se da je rast manji od očekivanog: to se uglavnom objašnjava neravnotežom particija (ne rade svi brokeri na vrhuncu svojih mogućnosti).

Potrošnja memorije JVM stroja ostala je ispod 2 GB:

Na rad brokera s pogonima utjecala je neravnoteža particija:

Zaključci

Gore predstavljeni iterativni pristup može se proširiti kako bi pokrio složenije scenarije koji uključuju stotine potrošača, reparticioniranje, tekuća ažuriranja, ponovno pokretanje grupa itd. Sve to nam omogućuje da procijenimo granice mogućnosti Kafka klastera u različitim uvjetima, identificiramo uska grla u njegovom radu i pronađemo načine za borbu protiv njih.

Dizajnirali smo Supertubes da brzo i jednostavno implementiramo klaster, konfiguriramo ga, dodamo/uklonimo brokere i teme, odgovorimo na upozorenja i osiguramo da Kafka općenito ispravno radi na Kubernetesu. Naš cilj je pomoći vam da se koncentrirate na glavni zadatak (“generirati” i “konzumirati” Kafka poruke), a sav težak posao prepustiti Supertubesu i Kafka operateru.

Ako ste zainteresirani za Banzai Cloud tehnologije i Open Source projekte, pretplatite se na tvrtku na GitHub, LinkedIn ili X / Twitter.

PS od prevoditelja

Pročitajte i na našem blogu:

• «Jedna priča s Redis operatorom u K8s i mini pregled uslužnih programa za analizu podataka iz ove baze podataka»;
• «Besprijekorna migracija RabbitMQ na Kubernetes»;
• «zetcd iz CoreOS-a: Zamjena ZooKeepera s...etcd pohranom".

Izvor: www.habr.com