Sopivan koon määrittäminen Kafka-klusterille Kubernetesissa

Huomautus. käännös: Tässä artikkelissa Banzai Cloud jakaa esimerkin siitä, kuinka sen mukautettuja apuohjelmia voidaan käyttää helpottamaan Kafkan käyttöä Kubernetesissa. Seuraavat ohjeet havainnollistavat, kuinka voit määrittää infrastruktuurisi optimaalisen koon ja määrittää Kafkan itse saavuttamaan vaaditun suorituskyvyn.

Apache Kafka on hajautettu suoratoistoalusta luotettavien, skaalautuvien ja tehokkaiden reaaliaikaisten suoratoistojärjestelmien luomiseen. Sen vaikuttavia ominaisuuksia voidaan laajentaa Kubernetesin avulla. Tätä varten olemme kehittäneet Avoimen lähdekoodin Kafka-operaattori ja työkalu nimeltä Supertubes. Niiden avulla voit ajaa Kafkaa Kubernetesissa ja käyttää sen erilaisia ​​ominaisuuksia, kuten välittäjän kokoonpanon hienosäätöä, metripohjaista skaalausta tasapainotuksella, telinetietoisuutta, "pehmeää" (siisti) päivitysten julkaiseminen jne.

Kokeile Supertubeja klusterissasi:

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

Tai ota yhteyttä dokumentointi. Voit myös lukea Kafkan ominaisuuksista, joiden kanssa työskentely on automatisoitu Supertubesilla ja Kafka-operaattorilla. Olemme jo kirjoittaneet niistä blogissa:

• Voi ei! Vielä yksi Kafka-operaattori Kubernetesille;
• Tarkkaile ja käytä Kafkaa Prometheus-mittareiden perusteella;
• Kafka-telinetietoisuus Kubernetesissa;
• Apache Kafkan juokseminen Istion yli - vertailukohta;
• Käyttäjän todentamat ja pääsyn valvomat klusterit Kafka-operaattorilla;
• Kafka-päivitys ja dynaaminen konfigurointi Kubernetesissa;
• Envoy-protokollasuodatin Kafkalle, meshed.

Kun päätät ottaa Kafka-klusterin käyttöön Kubernetesissa, joudut todennäköisesti kohtaamaan haasteen taustalla olevan infrastruktuurin optimaalisen koon määrittämisessä ja tarvetta hienosäätää Kafka-kokoonpanoasi vastaamaan suoritustehovaatimuksia. Kunkin välittäjän maksimiteho määräytyy taustalla olevien infrastruktuurikomponenttien, kuten muistin, prosessorin, levynopeuden, verkon kaistanleveyden jne., suorituskyvyn mukaan.

Ihannetapauksessa välittäjän konfiguraation tulisi olla sellainen, että kaikkia infrastruktuurielementtejä käytetään maksimaalisesti. Tosielämässä tämä järjestely on kuitenkin melko monimutkainen. On todennäköisempää, että käyttäjät määrittävät välittäjät maksimoimaan yhden tai kahden komponentin (levyn, muistin tai prosessorin) käytön. Yleisesti ottaen välittäjä näyttää maksimaalisen suorituskyvyn, kun sen konfiguraatio mahdollistaa hitaimman komponentin käytön täydessä laajuudessaan. Näin saamme karkean käsityksen yhden välittäjän kuormasta.

Teoreettisesti voimme myös arvioida tietyn kuorman käsittelyyn tarvittavien välittäjien lukumäärän. Käytännössä on kuitenkin niin paljon konfigurointivaihtoehtoja eri tasoilla, että on erittäin vaikeaa (ellei mahdotonta) arvioida tietyn kokoonpanon mahdollista suorituskykyä. Toisin sanoen on erittäin vaikeaa suunnitella kokoonpanoa tietyn suorituskyvyn perusteella.

Supertubes-käyttäjille otamme yleensä seuraavan lähestymistavan: aloitamme jollakin määrityksellä (infrastruktuuri + asetukset), sitten mittaamme sen suorituskyvyn, säädämme välittäjän asetuksia ja toistamme prosessin uudelleen. Tämä tapahtuu, kunnes infrastruktuurin hitain osa on täysin hyödynnetty.

Tällä tavalla saamme selkeämmän käsityksen siitä, kuinka monta välittäjää klusteri tarvitsee tietyn kuorman käsittelemiseksi (välittäjien määrä riippuu myös muista tekijöistä, kuten viestikopioiden vähimmäismäärästä joustavuuden varmistamiseksi, osion määrästä johtajat jne.). Lisäksi saamme käsityksen siitä, mitkä infrastruktuurikomponentit vaativat vertikaalista skaalausta.

Tässä artikkelissa kerrotaan vaiheista, joita teemme saadaksemme parhaan hyödyn alkukokoonpanojen hitaimmista komponenteista ja mitataksemme Kafka-klusterin suorituskykyä. Erittäin joustava kokoonpano vaatii vähintään kolme toimivaa välittäjää (min.insync.replicas=3), jaettu kolmelle eri esteettömyysvyöhykkeelle. Kubernetes-infrastruktuurin konfigurointiin, skaalaamiseen ja valvontaan käytämme omaa hybridipilvien kontinhallintaalustaa - Putki. Se tukee on-premise (paljas metalli, VMware) ja viittä tyyppistä pilvet (Alibaba, AWS, Azure, Google, Oracle) sekä mitä tahansa niiden yhdistelmiä.

Ajatuksia Kafka-klusterin infrastruktuurista ja kokoonpanosta

Alla oleviin esimerkkeihin valitsimme AWS:n pilvipalveluntarjoajaksi ja EKS:n Kubernetes-jakeluksi. Samanlainen konfiguraatio voidaan toteuttaa käyttämällä PKE - Kubernetes-jakelu Banzai Cloudista, CNCF:n sertifioima.

Диск

Amazon tarjoaa erilaisia EBS:n tilavuustyypit. Ytimessä gp2 и io1 On kuitenkin olemassa SSD-asemia korkean suorituskyvyn varmistamiseksi gp2 kuluttaa kertyneitä luottoja (I/O-pisteet), joten suosimme tyyppiä io1, joka tarjoaa tasaisen korkean suorituskyvyn.

Instanssityypit

Kafkan suorituskyky riippuu suuresti käyttöjärjestelmän sivuvälimuistista, joten tarvitsemme instansseja, joissa on tarpeeksi muistia välittäjille (JVM) ja sivuvälimuistille. Ilmentymä c5.2xlarge - hyvä alku, koska siinä on 16 Gt muistia ja optimoitu toimimaan EBS:n kanssa. Sen haittapuoli on, että se pystyy tarjoamaan maksimaalisen suorituskyvyn enintään 30 minuuttia 24 tunnin välein. Jos työkuormasi vaatii huippusuorituskykyä pidemmällä aikavälillä, sinun kannattaa harkita muita ilmentymätyyppejä. Juuri niin teimme, pysähtyen c5.4xlarge. Se tarjoaa maksimaalisen läpimenon 593,75 Mb/s. EBS-tilavuuden maksimikapasiteetti io1 korkeampi kuin esimerkki c5.4xlarge, joten infrastruktuurin hitain elementti on todennäköisesti tämän ilmentymän tyypin I/O-suorituskyky (mikä myös kuormitustestimme pitäisi vahvistaa).

Сеть

Verkon suorituskyvyn on oltava riittävän suuri verrattuna VM-instanssin ja levyn suorituskykyyn, muuten verkosta tulee pullonkaula. Meidän tapauksessamme verkkoliitäntä c5.4xlarge tukee jopa 10 Gb/s nopeuksia, mikä on huomattavasti suurempi kuin VM-ilmentymän I/O-suorituskyky.

Välittäjän käyttöönotto

Välittäjät tulisi ottaa käyttöön (aikataulutettu Kubernetesissa) omistettuihin solmuihin, jotta vältetään kilpaileminen muiden prosessien kanssa suorittimen, muistin, verkon ja levyresurssien suhteen.

Java-versio

Looginen valinta on Java 11, koska se on yhteensopiva Dockerin kanssa siinä mielessä, että JVM määrittää oikein kontin, jossa välittäjä toimii, käytettävissä olevat prosessorit ja muistit. Tietäen, että suorittimen rajoitukset ovat tärkeitä, JVM määrittää sisäisesti ja läpinäkyvästi GC-säikeiden ja JIT-säikeiden lukumäärän. Käytimme Kafka-kuvaa banzaicloud/kafka:2.13-2.4.0, joka sisältää Kafka-version 2.4.0 (Scala 2.13) Java 11:ssä.

Jos haluat oppia lisää Javasta/JVM:stä Kubernetesissa, tutustu seuraaviin viesteihimme:

• Miksi Java-sovellukseni on OOMKilled;
• Kuinka mitoittaa säilöt oikein Java 10 -sovelluksille.

Välittäjämuistin asetukset

Välittäjämuistin määrittämisessä on kaksi keskeistä näkökohtaa: JVM:n ja Kubernetes-podin asetukset. Podille asetetun muistirajan on oltava suurempi kuin maksimikeon koko, jotta JVM:ssä on tilaa Java-metatilalle, joka sijaitsee sen omassa muistissa, ja käyttöjärjestelmän sivuvälimuistille, jota Kafka aktiivisesti käyttää. Testeissämme lanseerasimme Kafka-välittäjät parametreilla -Xmx4G -Xms2G, ja podin muistiraja oli 10 Gi. Huomaa, että JVM:n muistiasetukset voidaan saada automaattisesti käyttämällä -XX:MaxRAMPercentage и -X:MinRAMPercentage, podin muistirajan perusteella.

Välittäjäprosessorin asetukset

Yleisesti ottaen voit parantaa suorituskykyä lisäämällä yhdensuuntaisuutta lisäämällä Kafkan käyttämien säikeiden määrää. Mitä enemmän prosessoreita Kafkalle on saatavilla, sitä parempi. Testissämme aloitimme 6 prosessorin rajalla ja nostimme niiden määrää vähitellen (iteraatioiden kautta) 15:een. Lisäksi asetimme num.network.threads=12 välittäjän asetuksissa lisätäksesi verkosta dataa vastaanottavien ja sitä lähettävien säikeiden määrää. He huomasivat heti, että seuraajavälittäjät eivät saaneet jäljennöksiä tarpeeksi nopeasti num.replica.fetchers 4:ään lisätäksesi nopeutta, jolla seuraajavälittäjät replikoivat johtajien viestejä.

Load Generation Tool

Sinun tulee varmistaa, että valitun kuormitusgeneraattorin kapasiteetti ei lopu ennen kuin Kafka-klusteri (jota verrataan) saavuttaa enimmäiskuormituksensa. Toisin sanoen on tarpeen suorittaa alustava arvio kuorman luontityökalun ominaisuuksista ja valita sille myös ilmentymätyypit, joissa on riittävä määrä prosessoreita ja muistia. Tässä tapauksessa työkalumme tuottaa enemmän kuormaa kuin Kafka-klusteri kestää. Monien kokeilujen jälkeen päädyimme kolmeen kopioon c5.4xlarge, joissa jokaisessa oli generaattori käynnissä.

Benchmarking

Suorituskyvyn mittaus on iteratiivinen prosessi, joka sisältää seuraavat vaiheet:

• infrastruktuurin perustaminen (EKS-klusteri, Kafka-klusteri, kuorman luontityökalu sekä Prometheus ja Grafana);
• generoidaan kuormitus tietyksi ajanjaksoksi satunnaisten poikkeamien suodattamiseksi kerätyissä suoritusindikaattoreissa;
• välittäjän infrastruktuurin ja konfiguraation säätäminen havaittujen suoritusindikaattoreiden perusteella;
• toistamalla prosessia, kunnes vaadittu Kafka-klusterin suoritusteho on saavutettu. Samanaikaisesti sen on oltava jatkuvasti toistettavissa ja sen on esitettävä mahdollisimman vähän vaihtelua suorituskyvyssä.

Seuraavassa osiossa kuvataan vaiheet, jotka suoritettiin testiklusterin benchmarking-prosessin aikana.

Työkalut

Seuraavia työkaluja käytettiin peruskokoonpanon nopeaan käyttöönottoon, kuormien luomiseen ja suorituskyvyn mittaamiseen:

• Banzai Cloud Pipeline EKS-klusterin järjestämisestä Amazonilta c Prometheus (keräämään Kafka- ja infrastruktuurimittauksia) ja grafana (näiden mittareiden visualisoimiseksi). Käytimme hyväksemme integroitu в Putki palvelut, jotka tarjoavat hajautetun valvonnan, keskitetyn lokien keräämisen, haavoittuvuustarkistuksen, katastrofipalautuksen, yritystason suojauksen ja paljon muuta.
• Sangrenel — työkalu Kafka-klusterin kuormitustestaukseen.
• Grafana-kojelaudat Kafkan mittareiden ja infrastruktuurin visualisointiin: Kubernetes Kafka, Solmun viejä.
• Supertubes CLI on helpoin tapa perustaa Kafka-klusteri Kubernetesille. Zookeeper, Kafka-operaattori, Envoy ja monet muut komponentit on asennettu ja konfiguroitu oikein tuotantovalmiin Kafka-klusterin pyörittämiseksi Kubernetesissa.
  • Asentaa supertubes CLI käytä annettuja ohjeita täällä.

EKS-klusteri

Valmistele EKS-klusteri omistetuilla työntekijäsolmuilla c5.4xlarge eri käytettävyysvyöhykkeillä podille Kafka-välittäjien kanssa sekä erilliset solmut kuormageneraattorille ja valvontainfrastruktuurille.

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

Kun EKS-klusteri on valmis, ota se käyttöön seurantapalvelu - hän sijoittaa Prometheuksen ja Grafanan klusteriin.

Kafka-järjestelmän komponentit

Asenna Kafka-järjestelmäkomponentit (Zookeeper, kafka-operator) EKS:ään supertubes CLI:n avulla:

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

Kafka-klusteri

Oletusarvoisesti EKS käyttää tyyppisiä EBS-taltioita gp2, joten sinun on luotava erillinen tallennusluokka volyymien perusteella io1 Kafka-klusterille:

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

Aseta parametri välittäjille min.insync.replicas=3 ja ota broker podeja käyttöön solmuissa kolmella eri saatavuusvyöhykkeellä:

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

Aiheet

Suoritimme kolme kuormitusgeneraattorin esiintymää rinnakkain. Jokainen heistä kirjoittaa omaan aiheeseensa, eli tarvitsemme yhteensä kolme aihetta:

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

Jokaisen aiheen replikointikerroin on 3 – pienin suositeltu arvo erittäin käytettäville tuotantojärjestelmille.

Load Generation Tool

Lanseerasimme kolme kopiota kuormitusgeneraattorista (jokainen kirjoitti erilliseen aiheeseen). Kuormageneraattoriryhmille sinun on asetettava solmuaffiniteetti niin, että ne ajoitetaan vain niille varatuille solmuille:

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

Muutama huomioitava seikka:

• Latausgeneraattori tuottaa 512 tavun pituisia viestejä ja julkaisee ne Kafkalle 500 viestin erissä.
• Käyttämällä argumenttia -required-acks=all Julkaisu katsotaan onnistuneeksi, kun Kafka-välittäjät ovat vastaanottaneet ja vahvistaneet kaikki viestin synkronoidut kopiot. Tämä tarkoittaa, että benchmarkissa mittasimme paitsi viestien vastaanottajien johtajien nopeuden, myös heidän seuraajiensa, jotka kopioivat viestejä. Tämän testin tarkoituksena ei ole arvioida kuluttajan lukunopeutta (kuluttajat) äskettäin vastaanotetut viestit, jotka ovat edelleen käyttöjärjestelmän sivuvälimuistissa, ja sen vertailu levylle tallennettujen viestien lukunopeuteen.
• Kuormageneraattori työntää rinnakkain 20 työntekijää (-workers=20). Jokainen työntekijä sisältää 5 tuottajaa, jotka jakavat työntekijän yhteyden Kafka-klusteriin. Tämän seurauksena jokaisella generaattorilla on 100 tuottajaa, jotka kaikki lähettävät viestejä Kafka-klusteriin.

Seurataan klusterin kuntoa

Kafka-klusterin kuormitustestauksen aikana tarkkailimme myös sen kuntoa varmistaaksemme, ettei pod-komentoja käynnistetty uudelleen, ei synkronoituja replikoita ja maksimaalinen suorituskyky minimaalisilla vaihteluilla:

• Kuormageneraattori kirjoittaa vakiotilastoja julkaistujen viestien määrästä ja virheprosentista. Virheprosentin pitäisi pysyä samana 0,00%.
• Vakionopeudensäädin, jonka on ottanut käyttöön kafka-operator, tarjoaa kojelaudan, jossa voimme myös seurata klusterin tilaa. Voit tarkastella tätä paneelia seuraavasti:

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

• ISR-taso ("synkronoitujen" replikoiden määrä) kutistuminen ja laajeneminen ovat yhtä suuria kuin 0.

Mittaustulokset

3 välittäjää, viestin koko - 512 tavua

Kun osiot jaettiin tasaisesti kolmen välittäjän kesken, pystyimme saavuttamaan suorituskykyä ~500 Mb/s (noin 990 tuhatta viestiä sekunnissa):

JVM-virtuaalikoneen muistin kulutus ei ylittänyt 2 Gt:

Levyn suorituskyky saavutti I/O-solmun enimmäisläpäisynopeuden kaikissa kolmessa esiintymässä, joissa välittäjät olivat käynnissä:

Solmujen muistinkäyttötiedoista seuraa, että järjestelmän puskurointi ja välimuisti veivät ~10-15 Gt:

3 välittäjää, viestin koko - 100 tavua

Viestin koon pienentyessä suorituskyky laskee noin 15-20 %: kunkin viestin käsittelyyn käytetty aika vaikuttaa siihen. Lisäksi prosessorikuormitus on lähes kaksinkertaistunut.

Koska välittäjäsolmuissa on edelleen käyttämättömiä ytimiä, suorituskykyä voidaan parantaa muuttamalla Kafka-kokoonpanoa. Tämä ei ole helppo tehtävä, joten suorituskyvyn lisäämiseksi on parempi käsitellä suurempia viestejä.

4 välittäjää, viestin koko - 512 tavua

Voit helposti lisätä Kafka-klusterin suorituskykyä lisäämällä uusia välittäjiä ja ylläpitämällä osioiden tasapainoa (tämä varmistaa, että kuorma jakautuu tasaisesti välittäjien kesken). Meidän tapauksessamme välittäjän lisäämisen jälkeen klusterin läpijuoksu kasvoi arvoon ~580 Mb/s (~1,1 miljoonaa viestiä sekunnissa). Kasvu osoittautui odotettua pienemmäksi: tämä selittyy pääasiassa osioiden epätasapainolla (kaikki välittäjät eivät työskentele kykyjensä huipulla).

JVM-koneen muistin kulutus jäi alle 2 Gt:

Asemien välittäjien työhön vaikutti osioiden epätasapaino:

Tulokset

Yllä esitettyä iteratiivista lähestymistapaa voidaan laajentaa kattamaan monimutkaisempia skenaarioita, joihin liittyy satoja kuluttajia, uudelleenosioiminen, rullaavat päivitykset, pod-uudelleenkäynnistykset jne. Kaiken tämän avulla voimme arvioida Kafka-klusterin kykyjen rajoja eri olosuhteissa, tunnistaa sen toiminnan pullonkauloja ja löytää tapoja torjua niitä.

Suunnittelimme Supertubesin ottamaan klusterin nopeasti ja helposti käyttöön, määrittämään sen, lisäämään/poistamaan välittäjiä ja aiheita, vastaamaan hälytyksiin ja varmistamaan, että Kafka toimii oikein Kubernetesissa. Tavoitteemme on auttaa sinua keskittymään päätehtävään ("luomaan" ja "kuluttamaan" Kafka-viestejä) ja jättää kaikki kova työ Supertubesille ja Kafka-operaattorille.

Jos olet kiinnostunut Banzai Cloud -tekniikoista ja avoimen lähdekoodin projekteista, tilaa yritys osoitteessa GitHub, LinkedIn tai Twitter.

PS kääntäjältä

Lue myös blogistamme:

• «Yksi tarina Redis-operaattorin kanssa K8s:ssa ja pieni katsaus apuohjelmiin tämän tietokannan tietojen analysoimiseksi";
• «RabbitMQ:n saumaton siirto Kubernetesiin";
• «zetcd CoreOS:stä: ZooKeeperin korvaaminen...etcd-tallennustilalla'.

Lähde: will.com