Kubernetes-en Kafka kluster baten tamaina egokia zehaztea

Ohar. itzul.: Artikulu honetan, Banzai Cloud-ek bere tresna pertsonalizatuak nola erabil daitezkeen erakusten du Kafka Kubernetesen barruan errazago erabiltzeko. Ondorengo argibideek zure azpiegituraren tamaina optimoa nola zehaztu dezakezun eta Kafka bera nola konfiguratu behar den errendimendua lortzeko erakusten dute.

Apache Kafka banatutako streaming plataforma bat da, denbora errealeko streaming sistema fidagarriak, eskalagarriak eta errendimendu handikoak sortzeko. Bere gaitasun ikusgarriak Kubernetes erabiliz heda daitezke. Horretarako garatu dugu Kode irekiko Kafka operadorea eta izeneko tresna Superhodiak. Kafka Kubernetes-en exekutatzeko eta bere ezaugarri desberdinak erabiltzeko aukera ematen dizute, hala nola, broker-en konfigurazioa doitzea, metriketan oinarritutako eskalatzea berbalekarekin, rack-en kontzientzia, "leuna" (dotorea) eguneratzeak zabaltzea, etab.

Probatu Supertubes zure multzoan:

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

Edo harremanetan jarri dokumentazioa. Kafkaren gaitasun batzuei buruz ere irakur dezakezu, zeinen lana automatizatuta baitago Supertubes eta Kafka operadorea erabiliz. Dagoeneko horiei buruz idatzi dugu blogean:

• Oh ez! Beste Kafka operadore bat Kubernetesentzat;
• Kontrolatu eta funtzionatu Kafka Prometheus-en metriketan oinarrituta;
• Kafka rack kontzientzia Kubernetes-en;
• Apache Kafka Istio gainean exekutatzen - erreferentzia;
• Erabiltzaileak autentifikatu eta atzitu kontrolatutako klusterrak Kafka operadorearekin;
• Kafka-ren bertsio berritzea eta konfigurazio dinamikoa Kubernetes-en;
• Envoy protokolo-iragazkia Kafkarentzat, sareduna.

Kafka kluster bat Kubernetes-en zabaltzea erabakitzen duzunean, litekeena da azpiko azpiegituraren tamaina optimoa zehazteko erronkari eta Kafka konfigurazioa doitzeko beharrari aurre egingo diozu errendimendu-baldintzak betetzeko. Broker bakoitzaren gehienezko errendimendua azpiko azpiegitura osagaien errendimenduak zehazten du, hala nola memoria, prozesadorea, diskoaren abiadura, sareko banda zabalera, etab.

Egokiena, brokerren konfigurazioak azpiegitura-elementu guztiak ahalik eta gaitasun handienarekin erabil daitezen izan behar du. Hala ere, bizitza errealean konfigurazio hau nahiko konplexua da. Litekeena da erabiltzaileek artekariak konfiguratzea osagai baten edo biren (diskoa, memoria edo prozesadorea) erabilera maximizatzeko. Oro har, broker batek errendimendu maximoa erakusten du bere konfigurazioak osagai motelena bere neurrian erabiltzeko aukera ematen duenean. Horrela, broker batek kudeatu dezakeen kargaren ideia gutxi gorabeheratsua izan dezakegu.

Teorian, karga jakin bat kudeatzeko behar diren artekarien kopurua ere kalkula dezakegu. Hala ere, praktikan hainbat konfigurazio-aukera daude maila desberdinetan, non oso zaila da (ezezkoa ez bada) konfigurazio jakin baten errendimendu potentziala ebaluatzea. Beste era batera esanda, oso zaila da errendimendu jakin batean oinarritutako konfigurazio bat planifikatzea.

Supertubes erabiltzaileentzat, normalean, honako ikuspegi hau hartzen dugu: konfigurazio batzuekin hasten gara (azpiegitura + ezarpenak), gero bere errendimendua neurtzen dugu, brokerren ezarpenak doitzen ditugu eta prozesua berriro errepikatzen dugu. Hori gertatzen da azpiegituraren osagai motelena guztiz erabili arte.

Modu honetan, kluster batek zenbat artekari behar dituen karga jakin bat kudeatzeko ideia argiagoa izango dugu (artekarien kopurua beste faktore batzuen araberakoa da, hala nola, erresilientzia bermatzeko mezuen erreplika gutxieneko kopurua, partizio kopurua). liderrak, etab.). Horrez gain, azpiegitura-osagaiek eskalatze bertikala behar duten argitzen dugu.

Artikulu honetan hasierako konfigurazioetan osagai motelenei etekinik handiena ateratzeko eta Kafka kluster baten errendimendua neurtzeko ematen ditugun pausoei buruz hitz egingo da. Erresistentzia handiko konfigurazio batek gutxienez hiru artekari exekutatu behar ditu (min.insync.replicas=3), hiru irisgarritasun gune ezberdinetan banatuta. Kubernetes azpiegitura konfiguratzeko, eskalatzeko eta kontrolatzeko, edukiontzien kudeaketa plataforma propioa erabiltzen dugu hodei hibridoetarako - Pipeline. On-premise (barre metal, VMware) eta bost hodei mota onartzen ditu (Alibaba, AWS, Azure, Google, Oracle), baita horien edozein konbinazio ere.

Kafka klusterraren azpiegiturari eta konfigurazioari buruzko gogoetak

Beheko adibideetarako, AWS aukeratu dugu hodeiko hornitzaile gisa eta EKS Kubernetes banaketa gisa. Antzeko konfigurazio bat inplementa daiteke erabiliz P.K.E. - Banzai Cloud-en Kubernetes banaketa, CNCFk ziurtatua.

diskoan

Amazonek hainbat eskaintzen ditu EBS bolumen motak. Muina gp2 и io1 SSD unitateak daude, ordea, errendimendu handia bermatzeko gp2 metatutako kredituak kontsumitzen ditu (I/O kredituak), beraz, mota nahiago dugu io1, errendimendu handia koherentea eskaintzen duena.

Instantzia motak

Kafkaren errendimendua sistema eragilearen orrialde-cachearen menpe dago oso, beraz, bitartekarientzako (JVM) eta orrialde-cacherako nahikoa memoria duten instantzia behar dugu. Instantzia c5.2xhandia - hasiera ona, 16 GB-ko memoria duelako eta EBSrekin lan egiteko optimizatua. Bere desabantaila da 30 orduz behin 24 minutu baino gehiagoko errendimendu maximoa eskaintzeko gai dela. Zure lan-kargak denbora-tarte luzeagoan errendimendu gorena eskatzen badu, baliteke beste instantzia mota batzuk kontuan hartu nahi izatea. Horixe da, hain zuzen, egin genuena, geldituz c5.4xhandia. Irteera maximoa eskaintzen du 593,75 Mb/s. EBS bolumen baten gehienezko errendimendua io1 instantzia baino altuagoa c5.4xhandia, beraz, litekeena da azpiegiturako elementu motelena instantzia mota honetako I/O-ren errendimendua izatea (gure karga-probak ere baieztatu beharko lukeena).

Sarea

Sarearen transmisioak nahikoa handia izan behar du VM instantziaren eta diskoaren errendimenduarekin alderatuta, bestela sarea botila-lepo bihurtzen da. Gure kasuan, sareko interfazea c5.4xhandia 10 Gb/s-ko abiadura onartzen du, hau da, VM instantzia baten I/O-ren abiadura baino nabarmen handiagoa.

Artekarien hedapena

Artekariak nodo dedikatuetan zabaldu behar dira (Kubernetes-en programatuta) PUZ, memoria, sare eta disko baliabideetarako beste prozesu batzuekin lehiatzea saihesteko.

Java bertsioa

Aukera logikoa Java 11 da, Docker-ekin bateragarria delako, JVM-k zuzen zehazten dituelako brokera exekutatzen ari den edukiontziarentzat eskuragarri dauden prozesadoreak eta memoria. PUZaren mugak garrantzitsuak direla jakinda, JVM-k barrutik eta gardentasunez ezartzen du GC hari eta JIT hari kopurua. Kafkaren irudia erabili dugu banzaicloud/kafka:2.13-2.4.0, Kafka 2.4.0 bertsioa (Scala 2.13) Java 11-n barne hartzen duena.

Kubernetes-en Java/JVM-ri buruz gehiago jakin nahi baduzu, begiratu gure ondorengo argitalpenak:

• Zergatik nire Java aplikazioa OOMKilled da;
• Nola neurtu behar bezala Java 10 aplikazioetarako edukiontziak.

Broker memoria ezarpenak

Broker memoria konfiguratzeko funtsezko bi alderdi daude: JVMrako eta Kubernetes podrako ezarpenak. Pod batentzako ezarritako memoria-mugak gehienezko pila-tamaina baino handiagoa izan behar du, JVM-k bere memorian dagoen Java metaespaziorako eta Kafkak aktiboki erabiltzen duen sistema eragilearen orrialde-cacherako lekua izan dezan. Gure probetan Kafka artekariak parametroekin abiarazi genituen -Xmx4G -Xms2G, eta lekaren memoria-muga zen 10 Gi. Kontuan izan JVMrako memoria ezarpenak automatikoki lor daitezkeela erabiliz -XX:MaxRAMPercentage и -X:MinRAMPercentage, podaren memoria-mugan oinarrituta.

Broker prozesadorearen ezarpenak

Oro har, errendimendua hobetu dezakezu paralelismoa handituz Kafkak erabiltzen dituen hari kopurua handituz. Kafkarentzat zenbat eta prozesadore gehiago erabilgarri, orduan eta hobeto. Gure proban, 6 prozesadoreko mugarekin hasi ginen eta pixkanaka (iterazioen bidez) haien kopurua 15era igo genuen. Horrez gain, ezarri genuen. num.network.threads=12 broker ezarpenetan sareko datuak jaso eta bidaltzen dituzten hari kopurua handitzeko. Jarraitzaile-artekariek erreplikak behar bezain azkar jaso ezin zirela deskubrituz berehala, planteatu zuten num.replica.fetchers 4ra arte jarraitzaileek buruzagien mezuak errepikatzeko abiadura handitzeko.

Karga sortzeko tresna

Aukeratutako karga-sorgailua ez dela agortuko ziurtatu beharko zenuke Kafka klusterra (erreferentzia egiten ari dena) gehienezko kargara iritsi aurretik. Beste era batera esanda, beharrezkoa da karga sortzeko tresnaren gaitasunen aurretiazko ebaluazioa egitea, eta horretarako instantzia motak hautatzea ere prozesadore eta memoria kopuru nahikoarekin. Kasu honetan, gure tresnak Kafka klusterrak jasan dezakeena baino karga gehiago sortuko du. Esperimentu askoren ondoren, hiru kopia jarri ginen c5.4xhandia, bakoitzak sorgailu bat martxan zuen.

Benchmarking

Errendimenduaren neurketa prozesu iteratibo bat da, eta fase hauek barne hartzen ditu:

• azpiegiturak ezartzea (EKS klusterra, Kafka klusterra, karga sortzeko tresna, baita Prometheus eta Grafana ere);
• karga bat sortzea epe jakin baterako bildutako errendimendu-adierazleetan ausazko desbideraketak iragazteko;
• artekariaren azpiegitura eta konfigurazioa doitzea, ikusitako errendimendu-adierazleetan oinarrituta;
• prozesua errepikatuz, Kafka kluster-en transmisio-maila behar den maila lortu arte. Aldi berean, koherentziaz erreproduzigarria izan behar du eta errendimenduaren aldaketa minimoak erakutsi behar ditu.

Hurrengo atalean, proba-klusterren benchmarking-prozesuan zehar egin ziren urratsak deskribatzen dira.

Tresnak

Tresna hauek oinarrizko konfigurazio bat azkar zabaltzeko, kargak sortzeko eta errendimendua neurtzeko erabili ziren:

• Banzai Cloud Pipeline Amazonetik EKS kluster bat antolatzeagatik c Prometeo (Kafka eta azpiegituren neurketak biltzeko) eta Grafana (neurri hauek ikusteko). Aprobetxatu genuen integratua в Pipeline Jarraipen federatua, erregistro-bilketa zentralizatua, ahultasunen azterketa, hondamendien berreskurapena, enpresa mailako segurtasuna eta askoz gehiago eskaintzen dituzten zerbitzuak.
• Sangrenela — Kafka kluster bat karga probatzeko tresna.
• Kafkaren neurketak eta azpiegiturak ikusteko Grafana panelak: Kubernetes Kafka, Nodo esportatzailea.
• Supertubes CLI Kubernetes-en Kafka kluster bat konfiguratzeko modurik errazena lortzeko. Zookeeper, Kafka operadorea, Envoy eta beste osagai asko instalatuta eta behar bezala konfiguratuta daude Kubernetes-en produkziorako prest dagoen Kafka kluster bat exekutatzeko.
  • Instalatzeko supertubes CLI emandako argibideak erabili Hemen.

EKS klusterra

Prestatu EKS kluster bat langile-nodo dedikatuekin c5.4xhandia Kafka artekariak dituzten podetarako erabilgarritasun gune ezberdinetan, baita karga-sorgailurako eta monitorizazio-azpiegiturarako nodo dedikatuetan ere.

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

EKS klusterra martxan dagoenean, gaitu bere integratua jarraipen zerbitzua — Prometheus eta Grafana kluster batean zabalduko ditu.

Kafka sistemaren osagaiak

Instalatu Kafka sistemaren osagaiak (Zookeeper, kafka-operator) EKSn supertubes CLI erabiliz:

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

Kafka multzoa

Lehenespenez, EKS-k EBS motako bolumenak erabiltzen ditu gp2, beraz, bolumenetan oinarritutako biltegiratze klase bereizi bat sortu behar duzu io1 Kafka multzorako:

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

Ezarri bitartekarientzako parametroa min.insync.replicas=3 eta zabaldu broker pods nodoetan hiru erabilgarritasun-eremu ezberdinetan:

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

Gaiak

Hiru karga-sorgailu instantzia exekutatu ditugu paraleloan. Bakoitzak bere gaiari idazten dio, hau da, hiru gai behar ditugu guztira:

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

Gai bakoitzeko, erreplikazio-faktorea 3 da, erabilgarritasun handiko ekoizpen-sistemetarako gomendatutako gutxieneko balioa.

Karga sortzeko tresna

Karga-sorgailuaren hiru kopia jarri genituen martxan (bakoitzak gai batean idatzi zuen). Karga-sorgailuen leketarako, nodoen afinitatea ezarri behar duzu, haientzat esleitutako nodoetan soilik programatu daitezen:

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

Kontuan izan beharreko puntu batzuk:

• Karga-sorgailuak 512 byteko luzerako mezuak sortzen ditu eta Kafkan argitaratzen ditu 500 mezuko sortatan.
• Argudio bat erabiliz -required-acks=all Argitalpena arrakastatsutzat jotzen da Kafka artekariek mezuaren erreplika sinkronizatu guztiak jasotzen eta berresten dituztenean. Horrek esan nahi du erreferentean buruzagiek mezuak jasotzen dituzten abiadura ez ezik, mezuak errepikatzen dituzten jarraitzaileek ere neurtu dugula. Proba honen helburua ez da kontsumitzaileen irakurketa abiadura ebaluatzea (kontsumitzaileak) orain dela gutxi jaso diren mezuak OS orrien cachean geratzen direnak, eta diskoan gordetako mezuen irakurketa-abiadurarekin alderatzea.
• Karga-sorgailuak 20 langile exekutatzen ditu paraleloan (-workers=20). Langile bakoitzak 5 ekoizle ditu, langileak Kafka klusterrarekin duen lotura partekatzen dutenak. Ondorioz, sorgailu bakoitzak 100 ekoizle ditu, eta guztiek mezuak bidaltzen dituzte Kafka klusterera.

Klusterraren osasuna kontrolatzea

Kafka klusterraren karga-probetan, haren osasuna ere kontrolatu dugu, pod berrabiarazteko, sinkronizatu gabeko erreplikarik ez zegoela eta fluktuazio minimoekin errendimendu maximorik ez zegoela ziurtatzeko:

• Karga-sortzaileak argitaratutako mezu kopuruari eta errore-tasari buruzko estatistika estandarrak idazten ditu. Errore-tasa berdina izan behar du 0,00%.
• Cruise Control, kafka-operator-ek zabaldutako aginte-panel bat eskaintzen du, non klusterraren egoera ere kontrolatu dezakegun. Panel hau ikusteko, egin:

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

• ISR maila (sinkronizatutako erreplika kopurua) uzkurdura eta hedapena 0 berdinak dira.

Neurketaren emaitzak

3 bitartekari, mezuaren tamaina - 512 byte

Partizioak hiru artekarietan uniformeki banatuta, errendimendua lortu ahal izan dugu ~500 Mb/s (segundoko 990 mila mezu inguru):

JVM makina birtualaren memoria-kontsumoak ez zuen 2 GB baino gehiago izan:

Diskoaren transmisioa I/O nodoaren gehienezko irteerara iritsi zen artekariak exekutatzen ari ziren hiru instantetan:

Nodoen memoriaren erabilerari buruzko datuetatik, sistemaren buffer-a eta cachean gordetzea ~ 10-15 GB behar zirela ondorioztatzen da:

3 bitartekari, mezuaren tamaina - 100 byte

Mezuaren tamaina txikiagotzen den heinean, transmisioa % 15-20 gutxi gorabehera jaisten da: mezu bakoitza prozesatzen emandako denborak eragina du. Gainera, prozesadorearen karga ia bikoiztu egin da.

Broker-nodoek oraindik erabili gabeko nukleoak dituztenez, errendimendua hobetu daiteke Kafka konfigurazioa aldatuz. Ez da lan erraza, beraz, errendimendua handitzeko hobe da mezu handiagoekin lan egitea.

4 bitartekari, mezuaren tamaina - 512 byte

Kafka kluster baten errendimendua erraz handitu dezakezu artekari berriak gehituz eta partizioen oreka mantenduz (horrek karga artekarien artean berdin banatuko dela ziurtatzen du). Gure kasuan, broker bat gehitu ondoren, kluster-aren errendimendua handitu egin zen ~580 Mb/s (~1,1 milioi mezu segundoko). Hazkundea espero baino txikiagoa izan da: partizioen desorekak azaltzen du nagusiki (artekari guztiek ez dute beren gaitasunen gailurrean lan egiten).

JVM makinaren memoria-kontsumoa 2 GBtik behera geratu zen:

Unitateak dituzten artekarien lana partizioen desorekak eragin zuen:

Findings

Goian aurkeztutako ikuspegi iteratiboa zabaldu daiteke ehunka kontsumitzailek parte hartzen duten agertoki konplexuagoak estaltzeko, birpartizazioak, eguneratzeak, pod berrabiarazteko, etab. Horrek guztiak aukera ematen digu Kafka klusterraren gaitasunen mugak hainbat baldintzatan baloratzeko, bere funtzionamenduan dauden botilak identifikatu eta horiei aurre egiteko bideak aurkitzeko.

Supertubes diseinatu dugu kluster bat azkar eta erraz zabaltzeko, konfiguratzeko, artekariak eta gaiak gehitzeko/kentzeko, alertak erantzuteko eta, oro har, Kafkak Kubernetes-en behar bezala funtzionatzen duela ziurtatzeko. Gure helburua zeregin nagusian kontzentratzen laguntzea da (“sortu” eta “kontsumitu” Kafkaren mezuak), eta lan gogor guztia Supertubes eta Kafka operadorearen esku uztea da.

Banzai Cloud teknologietan eta Kode Irekiko proiektuetan interesa baduzu, harpidetu enpresa helbide honetan GitHub, LinkedIn edo Twitter.

PS itzultzailetik

Irakurri ere gure blogean:

• «Istorio bat Redis operadorearekin K8s-en eta datu-base honetako datuak aztertzeko utilitateen mini-berrikuspena»;
• «RabbitMQ-ren migrazioa Kubernetesera»;
• «CoreOS-eko zetcd: ZooKeeper ordezkatuz... etab biltegiratzearekin'.

Iturria: www.habr.com