Let wel. vertaal.: In hierdie artikel deel Banzai Cloud 'n voorbeeld van hoe sy pasgemaakte gereedskap gebruik kan word om Kafka makliker te maak om binne Kubernetes te gebruik. Die volgende instruksies illustreer hoe jy die optimale grootte van jou infrastruktuur kan bepaal en Kafka self kan instel om die vereiste deurset te bereik.
Apache Kafka is 'n verspreide stroomplatform vir die skep van betroubare, skaalbare en hoëprestasie-intydse stroomstelsels. Die indrukwekkende vermoëns daarvan kan met Kubernetes uitgebrei word. Hiervoor het ons ontwikkel en 'n instrument genoem . Hulle laat jou toe om Kafka op Kubernetes te laat loop en die verskillende kenmerke daarvan te gebruik, soos die fyninstelling van die makelaarkonfigurasie, metrieke-gebaseerde skaal met herbalansering, rekbewustheid, "sag" (grasieus) die uitrol van opdaterings, ens.
Probeer Supertubes in jou groep:
curl https://getsupertubes.sh | sh и supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>Of kontak . Jy kan ook lees oor sommige van die vermoëns van Kafka, die werk waarmee geoutomatiseer word met behulp van Supertubes en Kafka-operateur. Ons het reeds oor hulle op die blog geskryf:
- ;
- ;
- ;
- ;
- ;
- ;
- .
Wanneer jy besluit om 'n Kafka-kluster op Kubernetes te ontplooi, sal jy waarskynlik voor die uitdaging te staan kom om die optimale grootte van die onderliggende infrastruktuur te bepaal en die behoefte om jou Kafka-konfigurasie te verfyn om te voldoen aan deurvloeivereistes. Die maksimum prestasie van elke makelaar word bepaal deur die werkverrigting van die onderliggende infrastruktuurkomponente, soos geheue, verwerker, skyfspoed, netwerkbandwydte, ens.
Ideaal gesproke moet die makelaarkonfigurasie so wees dat alle infrastruktuurelemente tot hul maksimum vermoëns gebruik word. In die werklike lewe is hierdie opstelling egter redelik kompleks. Dit is meer waarskynlik dat gebruikers makelaars sal konfigureer om die gebruik van een of twee komponente (skyf, geheue of verwerker) te maksimeer. Oor die algemeen toon 'n makelaar maksimum werkverrigting wanneer sy konfigurasie toelaat dat die stadigste komponent tot sy volle omvang gebruik word. Op hierdie manier kan ons 'n rowwe idee kry van die las wat een makelaar kan hanteer.
Teoreties kan ons ook die aantal makelaars skat wat nodig is om 'n gegewe vrag te hanteer. In die praktyk is daar egter soveel konfigurasie-opsies op verskillende vlakke dat dit baie moeilik (indien nie onmoontlik nie) is om die potensiële werkverrigting van 'n spesifieke konfigurasie te evalueer. Met ander woorde, dit is baie moeilik om 'n konfigurasie te beplan op grond van een of ander gegewe prestasie.
Vir Supertubes-gebruikers volg ons gewoonlik die volgende benadering: ons begin met een of ander konfigurasie (infrastruktuur + instellings), meet dan die prestasie daarvan, pas die makelaarinstellings aan en herhaal die proses weer. Dit gebeur totdat die stadigste komponent van die infrastruktuur ten volle benut is.
Op hierdie manier kry ons 'n duideliker idee van hoeveel makelaars 'n groep nodig het om 'n sekere vrag te hanteer (die aantal makelaars hang ook af van ander faktore, soos die minimum aantal boodskapreplikas om veerkragtigheid te verseker, die aantal partisies leiers, ens.). Daarbenewens kry ons insig in watter infrastruktuurkomponente vertikale skaal vereis.
Hierdie artikel sal praat oor die stappe wat ons neem om die meeste uit die stadigste komponente in aanvanklike konfigurasies te kry en die deurset van 'n Kafka-groepering te meet. 'n Hoogs veerkragtige konfigurasie vereis ten minste drie lopende makelaars (min.insync.replicas=3), versprei oor drie verskillende toeganklikheidsones. Om die Kubernetes-infrastruktuur op te stel, te skaal en te monitor, gebruik ons ons eie houerbestuurplatform vir hibriede wolke - . Dit ondersteun op die perseel (kaalmetaal, VMware) en vyf soorte wolke (Alibaba, AWS, Azure, Google, Oracle), sowel as enige kombinasie daarvan.
Gedagtes oor Kafka-klusterinfrastruktuur en -konfigurasie
Vir die voorbeelde hieronder het ons AWS as die wolkverskaffer gekies en EKS as die Kubernetes-verspreiding. 'n Soortgelyke konfigurasie kan geïmplementeer word met behulp van - Kubernetes-verspreiding vanaf Banzai Cloud, gesertifiseer deur CNCF.
skyf
Amazon bied verskeie . By die kern gp2 и io1 daar is egter SSD-aandrywers om hoë deurset te verseker gp2 verbruik opgehoopte krediete (I/O-krediete), so ons het die tipe verkies io1, wat konsekwent hoë deurset bied.
Instance tipes
Kafka se werkverrigting is hoogs afhanklik van die bedryfstelsel se bladsykas, so ons benodig gevalle met genoeg geheue vir die makelaars (JVM) en bladsykas. Geval c5.2xgroot - 'n goeie begin, aangesien dit 16 GB geheue en . Die nadeel daarvan is dat dit net in staat is om maksimum werkverrigting vir nie meer as 30 minute elke 24 uur te lewer nie. As jou werklading piekprestasie oor 'n langer tydperk vereis, sal jy dalk ander instansietipes wil oorweeg. Dit is presies wat ons gedoen het, gestop by c5.4xgroot. Dit bied maksimum deurvoer in 593,75 Mb/s. Maksimum deurset van 'n EBS-volume io1 hoër as die instansie c5.4xgroot, so die stadigste element van die infrastruktuur is waarskynlik die I/O-deurset van hierdie instansietipe (wat ons lastoetse ook moet bevestig).
Netwerk
Die netwerk deurset moet groot genoeg wees in vergelyking met die werkverrigting van die VM instansie en skyf, anders word die netwerk 'n bottelnek. In ons geval, die netwerk koppelvlak c5.4xgroot ondersteun snelhede van tot 10 Gb/s, wat aansienlik hoër is as die I/O-deurset van 'n VM-instansie.
Makelaar Ontplooiing
Makelaars moet ontplooi word (geskeduleer in Kubernetes) na toegewyde nodusse om te vermy om met ander prosesse vir SVE-, geheue-, netwerk- en skyfhulpbronne mee te ding.
Java weergawe
Die logiese keuse is Java 11 omdat dit versoenbaar is met Docker in die sin dat die JVM die verwerkers en geheue wat beskikbaar is vir die houer waarin die makelaar loop, korrek bepaal. Met die wete dat SVE-limiete belangrik is, stel die JVM intern en deursigtig die aantal GC-drade en JIT-drade. Ons het die Kafka-beeld gebruik banzaicloud/kafka:2.13-2.4.0, wat Kafka weergawe 2.4.0 (Scala 2.13) op Java 11 insluit.
As jy meer wil leer oor Java/JVM op Kubernetes, kyk na ons volgende plasings:
- ;
- .
Makelaar geheue instellings
Daar is twee sleutelaspekte vir die opstel van makelaargeheue: instellings vir die JVM en vir die Kubernetes-peul. Die geheuelimiet wat vir 'n peul gestel is, moet groter wees as die maksimum hoopgrootte sodat die JVM ruimte het vir die Java-metaruimte wat in sy eie geheue is en vir die bedryfstelselbladsykas wat Kafka aktief gebruik. In ons toetse het ons Kafka-makelaars met parameters bekendgestel -Xmx4G -Xms2G, en die geheuelimiet vir die peul was 10 Gi. Neem asseblief kennis dat geheue-instellings vir die JVM outomaties verkry kan word deur -XX:MaxRAMPercentage и -X:MinRAMPercentage, gebaseer op die geheuelimiet vir die peul.
Makelaar verwerker instellings
Oor die algemeen kan u werkverrigting verbeter deur parallelisme te verhoog deur die aantal drade wat deur Kafka gebruik word, te verhoog. Hoe meer verwerkers vir Kafka beskikbaar is, hoe beter. In ons toets het ons begin met 'n limiet van 6 verwerkers en geleidelik (deur herhalings) hul getal tot 15 verhoog. Daarbenewens het ons gestel num.network.threads=12 in die makelaarinstellings om die aantal drade wat data van die netwerk ontvang en stuur dit te verhoog. Toe hulle dadelik ontdek het dat die volgelinge makelaars nie vinnig genoeg replikas kon ontvang nie, het hulle gelig num.replica.fetchers tot 4 om die spoed waarteen volgelinge makelaars boodskappe van leiers herhaal te verhoog.
Laai Generasie Gereedskap
Jy moet seker maak dat die gekose lasgenerator nie sy kapasiteit opraak voordat die Kafka-kluster (wat genormeer word) sy maksimum las bereik nie. Met ander woorde, dit is nodig om 'n voorlopige beoordeling van die vermoëns van die lasgenereringsinstrument uit te voer, en ook instansietipes daarvoor te kies met 'n voldoende aantal verwerkers en geheue. In hierdie geval sal ons instrument meer vrag produseer as wat die Kafka-kluster kan hanteer. Na baie eksperimente het ons op drie kopieë besluit c5.4xgroot, wat elkeen 'n kragopwekker aan die gang gehad het.
Benchmarking
Prestasiemeting is 'n iteratiewe proses wat die volgende fases insluit:
- die opstel van infrastruktuur (EKS-kluster, Kafka-kluster, laaigenereringsinstrument, asook Prometheus en Grafana);
- die opwekking van 'n las vir 'n sekere tydperk om ewekansige afwykings in die versamelde prestasie-aanwysers te filter;
- aanpassing van die makelaar se infrastruktuur en konfigurasie gebaseer op waargenome prestasie-aanwysers;
- herhaal die proses totdat die vereiste vlak van Kafka-kluster-deurset bereik is. Terselfdertyd moet dit konsekwent reproduceerbaar wees en minimale variasies in deurset toon.
Die volgende afdeling beskryf die stappe wat tydens die toetskluster-benchmarking-proses uitgevoer is.
Tools
Die volgende gereedskap is gebruik om vinnig 'n basislynkonfigurasie te ontplooi, vragte te genereer en werkverrigting te meet:
- vir die organisering van 'n EKS-kluster vanaf Amazon c (om Kafka en infrastruktuur statistieke in te samel) en (om hierdie maatstawwe te visualiseer). Ons het voordeel getrek geïntegreer в dienste wat gefedereerde monitering, gesentraliseerde loginsameling, kwesbaarheidskandering, rampherstel, ondernemingsgraadsekuriteit en nog baie meer verskaf.
- - 'n instrument om 'n Kafka-kluster te toets.
- Grafana-kontroleskerms vir die visualisering van Kafka-statistieke en infrastruktuur: , .
- Supertubes CLI vir die maklikste manier om 'n Kafka-kluster op Kubernetes op te stel. Zookeeper, Kafka-operateur, Gesant en baie ander komponente is geïnstalleer en behoorlik gekonfigureer om 'n produksiegereed Kafka-kluster op Kubernetes te laat loop.
- Vir installasie superbuise CLI gebruik die instruksies wat verskaf word .
EKS-groepering
Berei 'n EKS-kluster met toegewyde werkernodusse voor c5.4xgroot in verskillende beskikbaarheidsones vir peule met Kafka-makelaars, sowel as toegewyde nodusse vir die lasgenerator en monitering-infrastruktuur.
banzai cluster create -f https://raw.githubusercontent.com/banzaicloud/kafka-operator/master/docs/benchmarks/infrastructure/cluster_eks_202001.jsonSodra die EKS-kluster aan die gang is, aktiveer dit geïntegreer - sy sal Prometheus en Grafana in 'n groep ontplooi.
Kafka stelsel komponente
Installeer Kafka-stelselkomponente (Zookeeper, kafka-operateur) in EKS met behulp van supertubes CLI:
supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>Kafka-kluster
By verstek gebruik EKS EBS-volumes van tipe gp2, so jy moet 'n aparte bergingsklas op grond van volumes skep io1 vir Kafka-groepering:
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
Stel die parameter vir makelaars min.insync.replicas=3 en ontplooi makelaarpeule op nodusse in drie verskillende beskikbaarheidsones:
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 600Onderwerpe
Ons het drie lasgenerator-instansies parallel uitgevoer. Elkeen van hulle skryf oor hul eie onderwerp, dit wil sê, ons benodig in totaal drie onderwerpe:
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
EOFVir elke onderwerp is die replikasiefaktor 3—die minimum aanbevole waarde vir hoogs beskikbare produksiestelsels.
Laai Generasie Gereedskap
Ons het drie kopieë van die lasgenerator bekendgestel (elkeen het in 'n aparte onderwerp geskryf). Vir lasgeneratorpeule moet u nodusaffiniteit instel sodat hulle slegs geskeduleer is op die nodusse wat daarvoor toegewys is:
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'n Paar punte om op te let:
- Die lasgenerator genereer boodskappe van 512 grepe lank en publiseer dit aan Kafka in groepe van 500 boodskappe.
- Gebruik 'n argument
-required-acks=allDie publikasie word as suksesvol beskou wanneer alle gesinchroniseerde replikas van die boodskap deur Kafka-makelaars ontvang en bevestig word. Dit beteken dat ons in die maatstaf nie net die spoed gemeet het van leiers wat boodskappe ontvang nie, maar ook hul volgelinge wat boodskappe repliseer. Die doel van hierdie toets is nie om verbruikersleesspoed te evalueer nie (verbruikers) onlangs boodskappe ontvang wat steeds in die OS-bladsykas bly, en die vergelyking daarvan met die leesspoed van boodskappe wat op skyf gestoor is. - Die lasgenerator laat 20 werkers parallel loop (
-workers=20). Elke werker bevat 5 produsente wat die werker se verbintenis met die Kafka-kluster deel. Gevolglik het elke kragopwekker 100 vervaardigers, en hulle stuur almal boodskappe na die Kafka-groepering.
Monitering van die gesondheid van die groep
Tydens lastoetsing van die Kafka-groepering het ons ook sy gesondheid gemonitor om te verseker dat daar geen peul-herbegin, geen buite-gesinkroniseerde replikas en maksimum deurset met minimale skommelinge was nie:
- Die lasgenerator skryf standaardstatistieke oor die aantal gepubliseerde boodskappe en die foutkoers. Die foutkoers moet dieselfde bly
0,00%. - , wat deur kafka-operateur ontplooi is, verskaf 'n dashboard waar ons ook die toestand van die groepering kan monitor. Om hierdie paneel te sien, doen:
supertubes cluster cruisecontrol show -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> - ISR vlak (aantal "gesinkroniseerde" replikas) krimp en uitbreiding is gelyk aan 0.
Metingsresultate
3 makelaars, boodskapgrootte - 512 grepe
Met partisies wat eweredig oor drie makelaars versprei is, kon ons prestasie behaal ~500 Mb/s (ongeveer 990 duisend boodskappe per sekonde):
Die geheueverbruik van die JVM virtuele masjien het nie 2 GB oorskry nie:
Skyfdeurset het die maksimum I/O-node-deurset bereik op al drie gevalle waarop die makelaars aan die gang was:
Uit die data oor geheuegebruik deur nodusse, volg dit dat stelselbuffering en kas ~10-15 GB geneem het:
3 makelaars, boodskapgrootte - 100 grepe
Soos die boodskapgrootte afneem, daal deurset met ongeveer 15-20%: die tyd wat spandeer word om elke boodskap te verwerk, beïnvloed dit. Daarbenewens het die verwerkerlading byna verdubbel.
Aangesien makelaarnodusse steeds ongebruikte kerns het, kan prestasie verbeter word deur die Kafka-konfigurasie te verander. Dit is nie 'n maklike taak nie, so om deurset te verhoog is dit beter om met groter boodskappe te werk.
4 makelaars, boodskapgrootte - 512 grepe
Jy kan maklik die prestasie van 'n Kafka-kluster verhoog deur eenvoudig nuwe makelaars by te voeg en 'n balans van partisies te handhaaf (dit verseker dat die las eweredig tussen makelaars versprei word). In ons geval, na die byvoeging van 'n makelaar, het die kluster deurset toegeneem tot ~580 Mb/s (~1,1 miljoen boodskappe per sekonde). Die groei blyk minder te wees as wat verwag is: dit word hoofsaaklik verklaar deur die wanbalans van partisies (nie alle makelaars werk op die hoogtepunt van hul vermoëns nie).
Geheueverbruik van die JVM-masjien het onder 2 GB gebly:
Die werk van makelaars met aandrywers is beïnvloed deur die wanbalans van partisies:
Bevindinge
Die iteratiewe benadering wat hierbo aangebied word, kan uitgebrei word om meer komplekse scenario's te dek wat honderde verbruikers behels, herverdeling, rollende opdaterings, pod-herbegin, ens. Dit alles stel ons in staat om die grense van die Kafka-kluster se vermoëns in verskeie toestande te evalueer, knelpunte in die werking daarvan te identifiseer en maniere te vind om dit te bekamp.
Ons het Supertubes ontwerp om vinnig en maklik 'n groepering te ontplooi, dit op te stel, makelaars en onderwerpe by te voeg/verwyder, op waarskuwings te reageer en te verseker dat Kafka in die algemeen behoorlik op Kubernetes werk. Ons doel is om jou te help om op die hooftaak te konsentreer (“genereer” en “verbruik” Kafka-boodskappe), en al die harde werk aan Supertubes en die Kafka-operateur oor te laat.
As jy belangstel in Banzai Wolk-tegnologieë en oopbronprojekte, teken in op die maatskappy by , of .
PS van vertaler
Lees ook op ons blog:
- «»;
- «»;
- «".
Bron: will.com