Určenie vhodnej veľkosti pre klaster Kafka v Kubernetes

Poznámka. preklad.: V tomto článku Banzai Cloud zdieľa príklad toho, ako možno použiť jeho vlastné nástroje na uľahčenie používania Kafky v Kubernetes. Nasledujúce pokyny ilustrujú, ako môžete určiť optimálnu veľkosť vašej infraštruktúry a nakonfigurovať samotnú Kafku na dosiahnutie požadovanej priepustnosti.

Apache Kafka je distribuovaná streamovacia platforma na vytváranie spoľahlivých, škálovateľných a vysokovýkonných streamovacích systémov v reálnom čase. Jeho pôsobivé schopnosti je možné rozšíriť pomocou Kubernetes. Na to sme vyvinuli Open Source operátor Kafka a nástroj tzv Supertubes. Umožňujú vám spúšťať Kafku na Kubernetes a využívať jeho rôzne funkcie, ako je jemné ladenie konfigurácie brokera, škálovanie na základe metrík s vyvážením, povedomie o stojanoch, „soft“ (ladný) zavádzanie aktualizácií atď.

Vyskúšajte Supertubes vo svojom klastri:

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

Alebo kontaktujte dokumentáciu. Môžete si prečítať aj o niektorých schopnostiach Kafky, s ktorou je práca automatizovaná pomocou Supertubes a Kafka operátora. Už sme o nich na blogu písali:

• Ale nie! Ďalší operátor Kafka pre Kubernetes;
• Monitorujte a prevádzkujte Kafku na základe metrík Prometheus;
• Povedomie o stojanoch Kafka na Kubernetes;
• Beh Apache Kafka cez Istio – benchmark;
• Používateľom overené a kontrolované klastre s operátorom Kafka;
• Priebežná inovácia Kafka a dynamická konfigurácia na Kubernetes;
• Filter protokolu Envoy pre Kafku, sieťovaný.

Keď sa rozhodnete nasadiť klaster Kafka na Kubernetes, pravdepodobne budete čeliť výzve určiť optimálnu veľkosť základnej infraštruktúry a potrebe doladiť konfiguráciu Kafka tak, aby spĺňala požiadavky na priepustnosť. Maximálny výkon každého makléra je určený výkonom základných komponentov infraštruktúry, ako je pamäť, procesor, rýchlosť disku, šírka pásma siete atď.

V ideálnom prípade by konfigurácia brokera mala byť taká, aby sa všetky prvky infraštruktúry využívali na maximum. V reálnom živote je však toto nastavenie dosť zložité. Je pravdepodobnejšie, že používatelia nakonfigurujú brokerov tak, aby maximalizovali využitie jedného alebo dvoch komponentov (disk, pamäť alebo procesor). Všeobecne povedané, maklér vykazuje maximálny výkon, keď jeho konfigurácia umožňuje maximálne využitie najpomalšieho komponentu. Takto môžeme získať približnú predstavu o záťaži, ktorú jeden maklér zvládne.

Teoreticky vieme odhadnúť aj počet maklérov potrebných na zvládnutie daného nákladu. V praxi však existuje toľko možností konfigurácie na rôznych úrovniach, že je veľmi ťažké (ak nie nemožné) vyhodnotiť potenciálny výkon konkrétnej konfigurácie. Inými slovami, je veľmi ťažké naplánovať konfiguráciu na základe určitého daného výkonu.

Pre používateľov Supertubes zvyčajne volíme nasledovný prístup: začneme s nejakou konfiguráciou (infraštruktúra + nastavenia), potom zmeriame jej výkon, upravíme nastavenia brokera a proces zopakujeme. Deje sa tak dovtedy, kým sa úplne nevyužije najpomalší komponent infraštruktúry.

Takto získame jasnejšiu predstavu o tom, koľko maklérov potrebuje klaster na zvládnutie určitej záťaže (počet maklérov závisí aj od iných faktorov, ako je minimálny počet replík správ na zabezpečenie odolnosti, počet partícií vodcovia atď.). Okrem toho získame prehľad o tom, ktoré komponenty infraštruktúry vyžadujú vertikálne škálovanie.

Tento článok bude hovoriť o krokoch, ktoré podnikáme, aby sme čo najlepšie využili najpomalšie komponenty v počiatočných konfiguráciách a zmerali priepustnosť klastra Kafka. Vysoko odolná konfigurácia vyžaduje aspoň troch spustených maklérov (min.insync.replicas=3), distribuované v troch rôznych zónach dostupnosti. Na konfiguráciu, škálovanie a monitorovanie infraštruktúry Kubernetes používame našu vlastnú platformu na správu kontajnerov pre hybridné cloudy – Potrubie. Podporuje on-premise (holý kov, VMware) a päť typov cloudov (Alibaba, AWS, Azure, Google, Oracle), ako aj ich ľubovoľnú kombináciu.

Úvahy o infraštruktúre a konfigurácii klastra Kafka

Pre nižšie uvedené príklady sme vybrali AWS ako poskytovateľa cloudu a EKS ako distribúciu Kubernetes. Podobná konfigurácia môže byť implementovaná pomocou PKE - Distribúcia Kubernetes od Banzai Cloud, certifikovaná CNCF.

disk

Amazon ponúka rôzne Typy zväzkov EBS. V jadre gp2 и io1 existujú však SSD disky, ktoré zaisťujú vysokú priepustnosť gp2 spotrebúva nahromadené kredity (I/O kredity), tak sme uprednostnili typ io1, ktorý ponúka konzistentne vysokú priepustnosť.

Typy inštancií

Kafkov výkon je veľmi závislý od cache stránok operačného systému, takže potrebujeme inštancie s dostatočnou pamäťou pre brokerov (JVM) a cache stránok. Inštancia c5.2xveľký - dobrý začiatok, pretože má 16 GB pamäte a optimalizované pre prácu s EBS. Jeho nevýhodou je, že je schopný poskytnúť maximálny výkon len po dobu maximálne 30 minút každých 24 hodín. Ak vaše pracovné zaťaženie vyžaduje špičkový výkon počas dlhšieho časového obdobia, možno budete chcieť zvážiť iné typy inštancií. Presne to sme urobili, zastavili sme sa pri tom c5.4xveľký. Poskytuje maximálnu priepustnosť 593,75 Mbps. Maximálna priepustnosť zväzku EBS io1 vyššia ako inštancia c5.4xveľký, takže najpomalším prvkom infraštruktúry bude pravdepodobne I/O priepustnosť tohto typu inštancie (čo by mali potvrdiť aj naše záťažové testy).

Sieť

Priepustnosť siete musí byť dostatočne veľká v porovnaní s výkonom inštancie VM a disku, inak sa sieť stane prekážkou. V našom prípade sieťové rozhranie c5.4xveľký podporuje rýchlosti až 10 Gb/s, čo je výrazne viac ako I/O priepustnosť inštancie VM.

Nasadenie makléra

Sprostredkovatelia by mali byť nasadení (naplánovaní v Kubernetes) do vyhradených uzlov, aby sa vyhli konkurencii s inými procesmi o CPU, pamäť, sieť a diskové zdroje.

verzia Java

Logickou voľbou je Java 11, pretože je kompatibilná s Dockerom v tom zmysle, že JVM správne určuje procesory a pamäť dostupnú pre kontajner, v ktorom je spustený broker. S vedomím, že limity CPU sú dôležité, JVM interne a transparentne nastavuje počet vlákien GC a vlákien JIT. Použili sme obrázok Kafku banzaicloud/kafka:2.13-2.4.0, ktorá obsahuje verziu Kafka 2.4.0 (Scala 2.13) na Java 11.

Ak by ste sa chceli dozvedieť viac o Java/JVM na Kubernetes, pozrite si naše nasledujúce príspevky:

• Prečo je moja aplikácia Java OOMKilled;
• Ako správne nastaviť veľkosť kontajnerov pre aplikácie Java 10.

Nastavenia pamäte makléra

Existujú dva kľúčové aspekty konfigurácie pamäte makléra: nastavenia pre JVM a pre modul Kubernetes. Limit pamäte nastavený pre modul musí byť väčší ako maximálna veľkosť haldy, aby mal JVM miesto pre metapriestor Java, ktorý sa nachádza v jeho vlastnej pamäti, a pre vyrovnávaciu pamäť stránok operačného systému, ktorú Kafka aktívne používa. V našich testoch sme spustili Kafka brokerov s parametrami -Xmx4G -Xms2Ga limit pamäte pre modul bol 10 Gi. Upozorňujeme, že nastavenia pamäte pre JVM je možné získať automaticky pomocou -XX:MaxRAMPercentage и -X:MinRAMPercentagena základe limitu pamäte pre modul.

Nastavenia procesora brokera

Všeobecne povedané, výkon môžete zlepšiť zvýšením paralelizmu zvýšením počtu vlákien používaných Kafkou. Čím viac procesorov má Kafka k dispozícii, tým lepšie. V našom teste sme začali s limitom 6 procesorov a postupne (opakovaním) sme ich počet zvýšili na 15. Okrem toho sme nastavili num.network.threads=12 v nastaveniach brokera zvýšiť počet vlákien, ktoré prijímajú dáta zo siete a odosielajú ich. Okamžite zistili, že sledujúci makléri nedokážu dostatočne rýchlo dostať repliky, zdvihli num.replica.fetchers na 4, aby sa zvýšila rýchlosť, akou makléri followerov replikovali správy od lídrov.

Nástroj na generovanie zaťaženia

Mali by ste zabezpečiť, aby sa kapacita zvoleného generátora záťaže nevyčerpala skôr, ako klaster Kafka (ktorý sa testuje) dosiahne svoje maximálne zaťaženie. Inými slovami, je potrebné vykonať predbežné posúdenie schopností nástroja na generovanie záťaže a tiež preň vybrať typy inštancií s dostatočným počtom procesorov a pamäte. V tomto prípade bude náš nástroj produkovať väčšie zaťaženie, než dokáže klaster Kafka zvládnuť. Po mnohých experimentoch sme sa rozhodli pre tri kópie c5.4xveľký, z ktorých každý mal spustený generátor.

Benchmarking

Meranie výkonu je iteratívny proces, ktorý zahŕňa nasledujúce fázy:

• nastavenie infraštruktúry (klaster EKS, klaster Kafka, nástroj na generovanie záťaže, ako aj Prometheus a Grafana);
• generovanie zaťaženia na určité obdobie na filtrovanie náhodných odchýlok v zhromaždených ukazovateľoch výkonnosti;
• úprava infraštruktúry a konfigurácie brokera na základe pozorovaných ukazovateľov výkonnosti;
• opakovanie procesu, kým sa nedosiahne požadovaná úroveň priepustnosti klastra Kafka. Zároveň musí byť konzistentne reprodukovateľný a musí vykazovať minimálne odchýlky v priepustnosti.

Nasledujúca časť popisuje kroky, ktoré sa vykonali počas procesu porovnávania testovacieho klastra.

Nástroje

Nasledujúce nástroje boli použité na rýchle nasadenie základnej konfigurácie, generovanie záťaže a meranie výkonu:

• Banzai Cloud Pipeline na organizovanie klastra EKS od Amazonu c Prometheus (na zber Kafkových a infraštruktúrnych metrík) a grafana (pre vizualizáciu týchto metrík). Využili sme to integrovaný в Potrubie služby, ktoré poskytujú federatívne monitorovanie, centralizovaný zber protokolov, skenovanie zraniteľností, obnovu po havárii, zabezpečenie na podnikovej úrovni a mnoho ďalších.
• Sangrenel — nástroj na testovanie záťaže klastra Kafka.
• Panely Grafana na vizualizáciu Kafkových metrík a infraštruktúry: Kubernetes Kafka, Exportér uzla.
• Supertubes CLI pre najjednoduchší spôsob nastavenia klastra Kafka na Kubernetes. Zookeeper, operátor Kafka, Envoy a mnoho ďalších komponentov sú nainštalované a správne nakonfigurované na spustenie produkčného klastra Kafka na Kubernetes.
  • Inštalácia supertrubice CLI použite poskytnuté pokyny tu.

klaster EKS

Pripravte klaster EKS s vyhradenými pracovnými uzlami c5.4xveľký v rôznych zónach dostupnosti pre moduly s maklérmi Kafka, ako aj vyhradené uzly pre generátor záťaže a monitorovaciu infraštruktúru.

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

Keď je klaster EKS v prevádzke, povoľte jeho integráciu monitorovacia služba — rozmiestni Prometheus a Grafana do klastra.

Komponenty systému Kafka

Nainštalujte komponenty systému Kafka (Zookeeper, kafka-operator) v EKS pomocou supertubes CLI:

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

Kafkov klaster

EKS štandardne používa zväzky typu EBS gp2, takže musíte vytvoriť samostatnú triedu úložiska na základe zväzkov io1 pre klaster Kafka:

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

Nastavte parameter pre brokerov min.insync.replicas=3 a nasadiť moduly brokera na uzly v troch rôznych zónach 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

Témy

Paralelne sme spustili tri inštancie generátora zaťaženia. Každý z nich píše do svojej vlastnej témy, to znamená, že potrebujeme celkovo tri témy:

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

Pre každú tému je replikačný faktor 3 – minimálna odporúčaná hodnota pre vysoko dostupné produkčné systémy.

Nástroj na generovanie zaťaženia

Spustili sme tri kópie generátora zaťaženia (každý bol napísaný v samostatnej téme). Pre moduly generátora zaťaženia musíte nastaviť afinitu uzlov tak, aby boli naplánované iba na uzloch, ktoré sú im pridelené:

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

Je potrebné poznamenať niekoľko bodov:

• Generátor záťaže generuje správy s dĺžkou 512 bajtov a zverejňuje ich Kafkovi v dávkach po 500 správ.
• Použitie argumentu -required-acks=all Publikácia sa považuje za úspešnú, keď makléri Kafka prijmú a potvrdia všetky synchronizované repliky správy. To znamená, že v benchmarku sme merali nielen rýchlosť lídrov prijímajúcich správy, ale aj ich nasledovníkov replikujúcich správy. Účelom tohto testu nie je hodnotiť rýchlosť čítania spotrebiteľa (spotrebitelia) nedávno prijaté správy, ktoré stále zostávajú vo vyrovnávacej pamäti stránky OS, a jej porovnanie s rýchlosťou čítania správ uložených na disku.
• Generátor záťaže beží paralelne 20 pracovníkov (-workers=20). Každý pracovník obsahuje 5 výrobcov, ktorí zdieľajú spojenie pracovníka s klastrom Kafka. Výsledkom je, že každý generátor má 100 výrobcov a všetci posielajú správy do klastra Kafka.

Monitorovanie zdravia klastra

Počas testovania záťaže klastra Kafka sme tiež monitorovali jeho stav, aby sme sa uistili, že nedošlo k reštartovaniu modulu, k nesynchronizovaným replikám a k maximálnej priepustnosti s minimálnymi výkyvmi:

• Generátor záťaže vypisuje štandardné štatistiky o počte zverejnených správ a chybovosti. Chybovosť by mala zostať rovnaká 0,00%.
• Tempomat, nasadený kafka-operator, poskytuje dashboard, kde môžeme sledovať aj stav klastra. Ak chcete zobraziť tento panel, postupujte takto:

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

• úroveň ISR (počet „synchronizovaných“ replík) zmršťovanie a rozťahovanie sa rovná 0.

Výsledky merania

3 makléri, veľkosť správy - 512 bajtov

S oddielmi rovnomerne rozdelenými medzi troch maklérov sme boli schopní dosiahnuť výkon ~500 Mb/s (približne 990 tisíc správ za sekundu):

Spotreba pamäte virtuálneho počítača JVM nepresiahla 2 GB:

Priepustnosť disku dosiahla maximálnu priepustnosť I/O uzla vo všetkých troch inštanciách, na ktorých boli spustení makléri:

Z údajov o využití pamäte uzlami vyplýva, že ukladanie do vyrovnávacej pamäte a vyrovnávacia pamäť systému trvalo ~10-15 GB:

3 makléri, veľkosť správy - 100 bajtov

Keď sa veľkosť správy znižuje, priepustnosť klesá približne o 15-20%: čas strávený spracovaním každej správy to ovplyvňuje. Okrem toho sa zaťaženie procesora takmer zdvojnásobilo.

Keďže maklérske uzly majú stále nevyužité jadrá, výkon možno zlepšiť zmenou konfigurácie Kafka. Nie je to ľahká úloha, takže na zvýšenie priepustnosti je lepšie pracovať s väčšími správami.

4 makléri, veľkosť správy - 512 bajtov

Výkon klastra Kafka môžete ľahko zvýšiť jednoduchým pridávaním nových brokerov a udržiavaním rovnováhy medzi oddielmi (to zaisťuje rovnomerné rozloženie záťaže medzi brokerov). V našom prípade sa po pridaní brokera zvýšila priepustnosť klastra na ~580 Mb/s (~1,1 milióna správ za sekundu). Rast sa ukázal byť nižší, ako sa očakávalo: vysvetľuje sa to najmä nerovnováhou medzi oddielmi (nie všetci makléri pracujú na vrchole svojich schopností).

Spotreba pamäte stroja JVM zostala pod 2 GB:

Práca maklérov s jednotkami bola ovplyvnená nerovnováhou oddielov:

Závery

Vyššie uvedený iteratívny prístup možno rozšíriť tak, aby pokrýval zložitejšie scenáre zahŕňajúce stovky spotrebiteľov, prerozdeľovanie, postupné aktualizácie, reštarty modulu atď. To všetko nám umožňuje posúdiť limity schopností klastra Kafka v rôznych podmienkach, identifikovať úzke miesta v jeho prevádzke a nájsť spôsoby, ako proti nim bojovať.

Navrhli sme Supertubes na rýchle a jednoduché nasadenie klastra, jeho konfiguráciu, pridávanie/odstraňovanie maklérov a tém, reagovanie na upozornenia a zabezpečenie toho, aby Kafka vo všeobecnosti správne fungovala na Kubernetes. Naším cieľom je pomôcť vám sústrediť sa na hlavnú úlohu („generovať“ a „konzumovať“ správy Kafka) a nechať všetku ťažkú ​​prácu na Supertubes a operátorovi Kafka.

Ak máte záujem o Banzai Cloud technológie a Open Source projekty, prihláste sa na odber spoločnosti na GitHub, LinkedIn alebo Twitter.

PS od prekladateľa

Prečítajte si aj na našom blogu:

• «Jeden príbeh s operátorom Redis v K8s a mini-prehľad nástrojov na analýzu údajov z tejto databázy»;
• «Bezproblémová migrácia RabbitMQ do Kubernetes»;
• «zetcd z CoreOS: Nahradenie ZooKeeperu úložiskom...etcd".

Zdroj: hab.com