Kafka klastri sobiva suuruse määramine Kubernetesis

Märge. tõlge: Selles artiklis jagab Banzai Cloud näidet selle kohta, kuidas selle kohandatud tööriistu saab kasutada Kafka kasutamise hõlbustamiseks Kubernetesis. Järgmised juhised illustreerivad, kuidas saate määrata oma infrastruktuuri optimaalse suuruse ja konfigureerida Kafka ennast vajaliku läbilaskevõime saavutamiseks.

Apache Kafka on hajutatud voogedastusplatvorm usaldusväärsete, skaleeritavate ja suure jõudlusega reaalajas voogedastussüsteemide loomiseks. Selle muljetavaldavaid võimalusi saab Kubernetese abil laiendada. Selleks oleme välja töötanud Avatud lähtekoodiga Kafka operaator ja tööriist nimega Supertuubid. Need võimaldavad teil kasutada Kafkat Kubernetesis ja kasutada selle erinevaid funktsioone, nagu maakleri konfiguratsiooni peenhäälestus, mõõdikupõhine skaleerimine koos tasakaalustamisega, riiuliteadlikkus, "pehme" (graatsiline) värskenduste levitamine jne.

Proovige oma klastris Supertubesid:

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

Või võtke ühendust dokumentatsioon. Samuti saab lugeda mõningatest Kafka võimalustest, millega töö automatiseeritakse Supertubesi ja Kafka operaatori abil. Oleme neist blogis juba kirjutanud:

• Oh ei! Veel üks Kafka operaator Kubernetesele;
• Jälgige ja kasutage Kafkat Prometheuse mõõdikute põhjal;
• Kafka riiuliteadlikkus Kubernetesis;
• Apache Kafka jooksmine Istio üle – etalon;
• Kasutaja autentitud ja juurdepääsu kontrollitud klastrid Kafka operaatoriga;
• Kafka jooksev uuendus ja dünaamiline konfiguratsioon Kubernetesis;
• Envoy protokolli filter Kafka jaoks, võrgusilmaga.

Kui otsustate Kubernetesis Kafka klastri juurutada, seisate tõenäoliselt silmitsi väljakutsega määrata kindlaks aluseks oleva infrastruktuuri optimaalne suurus ja vajadus täpsustada oma Kafka konfiguratsiooni, et see vastaks läbilaskevõime nõuetele. Iga maakleri maksimaalse jõudluse määrab aluseks olevate infrastruktuuri komponentide, nagu mälu, protsessor, ketta kiirus, võrgu ribalaius jne, jõudlus.

Ideaalis peaks maakleri konfiguratsioon olema selline, et kõiki infrastruktuuri elemente kasutatakse maksimaalselt ära. Päriselus on see seadistus aga üsna keeruline. On tõenäolisem, et kasutajad konfigureerivad maaklereid, et maksimeerida ühe või kahe komponendi (ketas, mälu või protsessor) kasutamist. Üldiselt näitab maakler maksimaalset jõudlust siis, kui tema konfiguratsioon võimaldab kõige aeglasemat komponenti täies mahus kasutada. Nii saame ligikaudse ettekujutuse, millise koormusega üks maakler hakkama saab.

Teoreetiliselt saame hinnata ka antud koormuse käsitlemiseks vajalike maaklerite arvu. Praktikas on aga erinevatel tasanditel nii palju konfiguratsioonivõimalusi, et konkreetse konfiguratsiooni võimalikku jõudlust on väga raske (kui mitte võimatu) hinnata. Teisisõnu on teatud jõudluse põhjal konfiguratsiooni kavandamine väga keeruline.

Supertubesi kasutajate puhul kasutame tavaliselt järgmist lähenemist: alustame mõne konfiguratsiooniga (infrastruktuur + seaded), seejärel mõõdame selle jõudlust, kohandame maakleri sätteid ja kordame protsessi uuesti. See juhtub seni, kuni taristu kõige aeglasem komponent on täielikult ära kasutatud.

Nii saame selgema ettekujutuse sellest, kui palju maaklereid klaster vajab teatud koormusega toimetulemiseks (maaklerite arv sõltub ka muudest teguritest, nagu näiteks sõnumikoopiate minimaalne arv vastupidavuse tagamiseks, partitsioonide arv juhid jne). Lisaks saame ülevaate sellest, millised infrastruktuuri komponendid vajavad vertikaalset skaleerimist.

See artikkel räägib sammudest, mida teeme, et saada algkonfiguratsioonides kõige aeglasematest komponentidest maksimumi ja mõõta Kafka klastri läbilaskevõimet. Väga vastupidav konfiguratsioon nõuab vähemalt kolme töötavat maaklerit (min.insync.replicas=3), jaotatud kolme erineva juurdepääsetavuse tsooni vahel. Kubernetese infrastruktuuri konfigureerimiseks, skaleerimiseks ja jälgimiseks kasutame hübriidpilvede jaoks oma konteinerihaldusplatvormi - Torujuhe. See toetab kohapealset (paljas metall, VMware) ja viit tüüpi pilvi (Alibaba, AWS, Azure, Google, Oracle), aga ka nende mis tahes kombinatsioone.

Mõtteid Kafka klastri infrastruktuuri ja konfiguratsiooni kohta

Allolevate näidete jaoks valisime pilveteenuse pakkujaks AWS-i ja Kubernetese distributsiooniks EKS-i. Sarnast konfiguratsiooni saab rakendada kasutades PKE - Kubernetese levitamine Banzai Cloudist, sertifitseeritud CNCF-i poolt.

ketas

Amazon pakub erinevaid EBS-i helitugevuse tüübid. Keskmiselt gp2 и io1 Suure läbilaskevõime tagamiseks on siiski olemas SSD-draivid gp2 kulutab kogunenud krediiti (I/O krediiti), seega eelistasime tüüpi io1, mis pakub püsivat suurt läbilaskevõimet.

Eksemplari tüübid

Kafka jõudlus sõltub suuresti operatsioonisüsteemi lehe vahemälust, seega vajame maaklerite (JVM) ja lehe vahemälu jaoks piisavalt mäluga juhtumeid. Näide c5.2xsuur - hea algus, kuna sellel on 16 GB mälu ja optimeeritud töötama EBS-iga. Selle puuduseks on see, et see suudab pakkuda maksimaalset jõudlust mitte rohkem kui 30 minutit iga 24 tunni järel. Kui teie töökoormus nõuab tippjõudlust pikema aja jooksul, võiksite kaaluda muid eksemplaritüüpe. Täpselt nii me tegimegi, peatudes c5.4xsuur. See tagab maksimaalse läbilaskevõime 593,75 Mb/s. EBS-i mahu maksimaalne läbilaskevõime io1 eksemplarist kõrgem c5.4xsuur, seega on taristu kõige aeglasem element tõenäoliselt selle eksemplari tüüpi I/O läbilaskevõime (mida peaksid kinnitama ka meie koormustestid).

Сеть

Võrgu läbilaskevõime peab olema VM-i eksemplari ja ketta jõudlusega võrreldes piisavalt suur, vastasel juhul muutub võrk kitsaskohaks. Meie puhul võrguliides c5.4xsuur toetab kiirust kuni 10 Gb/s, mis on oluliselt suurem kui VM-i eksemplari I/O läbilaskevõime.

Maakleri juurutamine

Maaklerid tuleks juurutada (Kubernetesis ajastatud) spetsiaalsetesse sõlmedesse, et vältida konkureerimist teiste protsessidega protsessori, mälu, võrgu ja kettaressursside pärast.

Java versioon

Loogiline valik on Java 11, kuna see ühildub Dockeriga selles mõttes, et JVM määrab õigesti konteineri jaoks saadaolevad protsessorid ja mälu, milles maakler töötab. Teades, et protsessori piirangud on olulised, määrab JVM sisemiselt ja läbipaistvalt GC-lõimede ja JIT-lõimede arvu. Kasutasime Kafka pilti banzaicloud/kafka:2.13-2.4.0, mis sisaldab Java 2.4.0-l Kafka versiooni 2.13 (Scala 11).

Kui soovite Kubernetes Java/JVM-i kohta lisateavet saada, vaadake meie järgmisi postitusi:

• Miks on minu Java-rakendus OOMKilled?;
• Kuidas Java 10 rakenduste jaoks konteinereid õigesti mõõta.

Maakleri mälu seaded

Maakleri mälu konfigureerimisel on kaks peamist aspekti: JVM-i ja Kubernetese podi sätted. Podi jaoks seatud mälupiirang peab olema suurem kui maksimaalne kuhja suurus, et JVM-is oleks ruumi Java metaruumi jaoks, mis asub tema enda mälus, ja operatsioonisüsteemi lehe vahemälu jaoks, mida Kafka aktiivselt kasutab. Testides käivitasime parameetritega Kafka maaklerid -Xmx4G -Xms2G, ja podi mälupiirang oli 10 Gi. Pange tähele, et JVM-i mäluseadeid saab automaatselt hankida kasutades -XX:MaxRAMPercentage и -X:MinRAMPercentage, mis põhineb podi mälupiirangul.

Maakleri protsessori seaded

Üldiselt saate jõudlust parandada, suurendades paralleelsust, suurendades Kafka kasutatavate lõimede arvu. Mida rohkem protsessoreid on Kafka jaoks saadaval, seda parem. Meie testis alustasime 6 protsessori limiidiga ja tõstsime järk-järgult (iteratsioonide kaudu) nende arvu 15-ni. Lisaks seadsime num.network.threads=12 maakleri seadetes, et suurendada võrgust andmeid vastuvõtvate ja neid saatvate lõimede arvu. Avastades kohe, et jälgijamaaklerid ei saa piisavalt kiiresti koopiaid kätte, tõstatasid nad num.replica.fetchers 4-le, et suurendada kiirust, millega jälgijamaaklerid juhtide sõnumeid kordasid.

Laadimise genereerimise tööriist

Peaksite tagama, et valitud koormusgeneraatori võimsus ei saaks tühjaks enne, kui Kafka klaster (mida võrreldakse) saavutab maksimaalse koormuse. Teisisõnu on vaja läbi viia koormuse genereerimise tööriista võimaluste esialgne hindamine ning valida selle jaoks ka piisava arvu protsessorite ja mäluga eksemplaritüübid. Sel juhul toodab meie tööriist rohkem koormust, kui Kafka klaster suudab taluda. Pärast paljusid katseid otsustasime kolme eksemplari kasuks c5.4xsuur, millest igaühel töötas generaator.

Võrdlusuuringud

Toimivuse mõõtmine on iteratiivne protsess, mis hõlmab järgmisi etappe.

• infrastruktuuri loomine (EKS-klaster, Kafka klaster, koormuse genereerimise tööriist, samuti Prometheus ja Grafana);
• koormuse genereerimine teatud perioodiks, et filtreerida kogutud tulemusnäitajate juhuslikud kõrvalekalded;
• maakleri infrastruktuuri ja konfiguratsiooni kohandamine vaadeldud tulemusnäitajate põhjal;
• korrates protsessi, kuni saavutatakse Kafka klastri läbilaskevõime nõutav tase. Samal ajal peab see olema järjepidevalt reprodutseeritav ja näitama läbilaskevõime minimaalseid erinevusi.

Järgmises jaotises kirjeldatakse testklastri võrdlusuuringu käigus tehtud toiminguid.

Töövahendid

Põhikonfiguratsiooni kiireks juurutamiseks, koormuste genereerimiseks ja jõudluse mõõtmiseks kasutati järgmisi tööriistu.

• Banzai pilvetoru EKS klastri korraldamise eest Amazonist c Prometheus (Kafka ja infrastruktuuri mõõdikute kogumiseks) ja grafana (nende mõõdikute visualiseerimiseks). Kasutasime ära integreeritud в Torujuhe teenused, mis pakuvad liitjälgimist, tsentraliseeritud logide kogumist, haavatavuse skannimist, avariitaastet, ettevõtte tasemel turvalisust ja palju muud.
• Sangrenel — tööriist Kafka klastri koormustestimiseks.
• Grafana armatuurlauad Kafka mõõdikute ja infrastruktuuri visualiseerimiseks: Kubernetes Kafka, Sõlme eksportija.
• Supertubes CLI lihtsaim viis Kafka klastri seadistamiseks Kubernetesis. Loomaaiapidaja, Kafka operaator, Envoy ja paljud teised komponendid on installitud ja õigesti konfigureeritud, et käitada Kubernetes tootmisvalmis Kafka klastrit.
  • Installimiseks supertubes CLI kasutage kaasasolevaid juhiseid siin.

EKS klaster

Valmistage ette EKS-klaster spetsiaalsete töötajate sõlmedega c5.4xsuur Kafka vahendajatega kaunade erinevates saadavustsoonides, samuti spetsiaalsetes sõlmedes koormusgeneraatori ja seireinfrastruktuuri jaoks.

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

Kui EKS-klaster on valmis ja töötab, lubage selle integreerimine seireteenus — ta paigutab Prometheuse ja Grafana klastrisse.

Kafka süsteemi komponendid

Installige Kafka süsteemi komponendid (Zookeeper, kafka-operator) EKS-i kasutades supertubes CLI:

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

Kafka klaster

Vaikimisi kasutab EKS EBS tüüpi köiteid gp2, seega peate looma mahtude alusel eraldi salvestusklassi io1 Kafka klastri jaoks:

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

Määrake maaklerite parameeter min.insync.replicas=3 ja juurutage maaklerikomplektid kolme erineva saadavustsooni sõlmedesse:

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

Teemad

Käitasime paralleelselt kolme koormusgeneraatori eksemplari. Igaüks neist kirjutab oma teemale, see tähendab, et vajame kokku kolme teemat:

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

Iga teema puhul on replikatsioonitegur 3 – minimaalne soovitatav väärtus väga kättesaadavate tootmissüsteemide jaoks.

Laadimise genereerimise tööriist

Käivitasime kolm koormusgeneraatori eksemplari (igaüks neist kirjutas eraldi teemas). Koormusgeneraatorite jaoks peate määrama sõlmede afiinsuse nii, et need oleksid ajastatud ainult neile eraldatud sõlmedele:

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

Mõned tähelepanekud:

• Koormusgeneraator genereerib 512 baidi pikkuseid sõnumeid ja avaldab need Kafkale 500 sõnumist koosnevate partiidena.
• Argumendi kasutamine -required-acks=all Avaldamine loetakse õnnestunuks, kui Kafka maaklerid on vastu võtnud ja kinnitanud kõik sõnumi sünkroonitud koopiad. See tähendab, et võrdlusaluses ei mõõtnud me mitte ainult juhtide sõnumite vastuvõtmise kiirust, vaid ka nende järgijate sõnumeid kopeerivaid kiirusi. Selle testi eesmärk ei ole hinnata tarbija lugemiskiirust (tarbijad) hiljuti saadud sõnumid, mis on endiselt OS-i lehe vahemällu jäänud, ja selle võrdlus kettale salvestatud sõnumite lugemiskiirusega.
• Koormusgeneraator töötab paralleelselt 20 töötajat (-workers=20). Iga töötaja sisaldab 5 tootjat, kes jagavad töötaja sidet Kafka klastriga. Selle tulemusena on igal generaatoril 100 tootjat ja nad kõik saadavad sõnumeid Kafka klastrisse.

Klastri tervise jälgimine

Kafka klastri koormustestimise ajal jälgisime ka selle seisukorda tagamaks, et poleks podi taaskäivitamist, sünkroonimata koopiaid ja maksimaalset läbilaskevõimet minimaalsete kõikumistega.

• Koormusgeneraator kirjutab standardstatistikat avaldatud teadete arvu ja veamäära kohta. Veamäär peaks jääma samaks 0,00%.
• Püsikiirusehoidja, mille juurutab kafka-operator, pakub armatuurlauda, ​​kus saame jälgida ka klastri olekut. Selle paneeli vaatamiseks tehke järgmist.

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

• ISR tase ("sünkroonitud" koopiate arv) kokkutõmbumine ja paisumine on 0.

Mõõtmistulemused

3 maaklerit, sõnumi suurus - 512 baiti

Kolme maakleri vahel ühtlaselt jaotatud vaheseinad suutsime jõudlust saavutada ~500 Mb/s (umbes 990 tuhat sõnumit sekundis):

JVM-i virtuaalmasina mälutarbimine ei ületanud 2 GB:

Ketta läbilaskevõime saavutas maksimaalse I/O-sõlme läbilaskevõime kõigil kolmel eksemplaril, millel maaklerid töötasid:

Sõlmede mälukasutuse andmetest järeldub, et süsteemi puhverdamiseks ja vahemällu salvestamiseks kulus ~10-15 GB:

3 maaklerit, sõnumi suurus - 100 baiti

Kui sõnumi suurus väheneb, väheneb läbilaskevõime ligikaudu 15-20%: iga sõnumi töötlemisele kuluv aeg mõjutab seda. Lisaks on protsessori koormus peaaegu kahekordistunud.

Kuna maaklerisõlmedel on endiselt kasutamata südamikke, saab jõudlust parandada, muutes Kafka konfiguratsiooni. See pole lihtne ülesanne, seega on läbilaskevõime suurendamiseks parem töötada suuremate sõnumitega.

4 maaklerit, sõnumi suurus - 512 baiti

Kafka klastri jõudlust saate hõlpsalt suurendada, lisades lihtsalt uusi maaklereid ja säilitades vaheseinte tasakaalu (see tagab koormuse ühtlase jaotumise maaklerite vahel). Meie puhul suurenes klastri läbilaskevõime pärast maakleri lisamist ~580 Mb/s (~1,1 miljonit sõnumit sekundis). Kasv osutus oodatust väiksemaks: see on peamiselt seletatav vaheseinte tasakaalustamatusega (kõik maaklerid ei tööta oma võimete tipul).

JVM-masina mälutarbimine jäi alla 2 GB:

Draividega maaklerite tööd mõjutas vaheseinte tasakaalustamatus:

Järeldused

Eespool kirjeldatud iteratiivset lähenemist saab laiendada, et see hõlmaks keerukamaid stsenaariume, mis hõlmavad sadu tarbijaid, ümberjaotamist, jooksvaid värskendusi, moodulite taaskäivitamist jne. Kõik see võimaldab hinnata Kafka klastri võimekuse piire erinevates tingimustes, tuvastada kitsaskohti selle toimimises ja leida võimalusi nende vastu võitlemiseks.

Kujundasime Supertubesid klastri kiireks ja hõlpsaks juurutamiseks, selle konfigureerimiseks, maaklerite ja teemade lisamiseks/eemaldamiseks, hoiatustele reageerimiseks ja üldiselt Kafka nõuetekohaseks Kuberneteses töötamiseks. Meie eesmärk on aidata teil keskenduda põhiülesandele ("genereerida" ja "tarbida" Kafka sõnumeid) ning jätta kogu raske töö Supertubesi ja Kafka operaatori kanda.

Kui olete huvitatud Banzai pilvetehnoloogiatest ja avatud lähtekoodiga projektidest, tellige ettevõte aadressil GitHub, LinkedIn või puperdama.

PS tõlkijalt

Loe ka meie blogist:

• «Üks lugu Redise operaatoriga K8sis ja miniülevaade utiliitidest selle andmebaasi andmete analüüsimiseks";
• «RabbitMQ sujuv migreerimine Kubernetesesse";
• «zetcd CoreOS-ist: ZooKeeperi asendamine... jne salvestusruumiga'.

Allikas: www.habr.com