Určete vhodnou velikost pro cluster Kafka v Kubernetes

Poznámka. přel.: V tomto článku Banzai Cloud sdílí příklad toho, jak lze jeho vlastní nástroje použít ke snazšímu používání Kafky v Kubernetes. Následující pokyny ilustrují, jak můžete určit optimální velikost vaší infrastruktury a nakonfigurovat samotnou Kafku tak, abyste dosáhli požadované propustnosti.

Apache Kafka je distribuovaná streamovací platforma pro vytváření spolehlivých, škálovatelných a vysoce výkonných streamovacích systémů v reálném čase. Jeho působivé schopnosti lze rozšířit pomocí Kubernetes. K tomu jsme vyvinuli Open Source operátor Kafka a nástroj tzv Supertubes. Umožňují vám spouštět Kafka na Kubernetes a používat jeho různé funkce, jako je jemné vyladění konfigurace brokera, škálování na základě metrik s rebalancováním, povědomí o racku, „soft“ (elegantní) vydávání aktualizací atd.

Vyzkoušejte Supertubes ve svém clusteru:

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

Nebo kontaktujte dokumentace. Můžete se také dočíst o některých schopnostech Kafky, s níž je práce automatizována pomocí Supertubes a Kafka operátora. Už jsme o nich psali na blogu:

• Ach ne! Další operátor Kafka pro Kubernetes;
• Monitorujte a provozujte Kafku na základě metrik Prometheus;
• Povědomí o racku Kafka na Kubernetes;
• Spuštění Apache Kafka přes Istio - benchmark;
• Uživatelsky ověřené a řízené clustery s operátorem Kafka;
• Průběžný upgrade a dynamická konfigurace Kafka na Kubernetes;
• Filtr protokolu Envoy pro Kafku, síťovaný.

Když se rozhodnete nasadit cluster Kafka na Kubernetes, budete pravděpodobně čelit výzvě určit optimální velikost základní infrastruktury a potřebě doladit konfiguraci Kafka tak, aby splňovala požadavky na propustnost. Maximální výkon každého brokera je určen výkonem základních komponent infrastruktury, jako je paměť, procesor, rychlost disku, šířka pásma sítě atd.

V ideálním případě by konfigurace brokera měla být taková, aby byly všechny prvky infrastruktury využity na maximum. V reálném životě je však toto nastavení poměrně složité. Je pravděpodobnější, že uživatelé nakonfigurují brokery tak, aby maximalizovali využití jedné nebo dvou komponent (disk, paměť nebo procesor). Obecně řečeno, broker vykazuje maximální výkon, když jeho konfigurace umožňuje využít nejpomalejší komponentu v plném rozsahu. Můžeme tak získat přibližnou představu o zátěži, kterou jeden broker zvládne.

Teoreticky můžeme také odhadnout počet brokerů potřebných pro zvládnutí dané zátěže. V praxi však existuje tolik možností konfigurace na různých úrovních, že je velmi obtížné (ne-li nemožné) vyhodnotit potenciální výkon konkrétní konfigurace. Jinými slovy, je velmi obtížné naplánovat konfiguraci na základě určitého daného výkonu.

Pro uživatele Supertubes obvykle volíme následující přístup: začneme s nějakou konfigurací (infrastruktura + nastavení), poté změříme její výkon, upravíme nastavení brokera a proces znovu opakujeme. To se děje, dokud není plně využita nejpomalejší komponenta infrastruktury.

Získáme tak jasnější představu o tom, kolik zprostředkovatelů cluster potřebuje ke zvládnutí určité zátěže (počet zprostředkovatelů závisí také na dalších faktorech, jako je minimální počet replik zpráv pro zajištění odolnosti, počet oddílů vedoucí atd.). Navíc získáme přehled o tom, které komponenty infrastruktury vyžadují vertikální škálování.

Tento článek bude hovořit o krocích, které podnikáme, abychom co nejlépe využili nejpomalejší komponenty v počátečních konfiguracích a změřili propustnost clusteru Kafka. Vysoce odolná konfigurace vyžaduje alespoň tři běžící brokery (min.insync.replicas=3), distribuované ve třech různých zónách dostupnosti. Ke konfiguraci, škálování a monitorování infrastruktury Kubernetes používáme vlastní platformu pro správu kontejnerů pro hybridní cloudy – Potrubí. Podporuje on-premise (holý kov, VMware) a pět typů cloudů (Alibaba, AWS, Azure, Google, Oracle), stejně jako libovolnou jejich kombinaci.

Úvahy o infrastruktuře a konfiguraci clusteru Kafka

Pro níže uvedené příklady jsme vybrali AWS jako poskytovatele cloudu a EKS jako distribuci Kubernetes. Podobnou konfiguraci lze implementovat pomocí P.K.E. - Distribuce Kubernetes od Banzai Cloud, certifikovaná CNCF.

Drive

Amazon nabízí různé Typy svazků EBS... V srdci gp2 и io1 Pro zajištění vysoké propustnosti však existují SSD disky gp2 spotřebovává nasbírané kredity (I/O kredity), tak jsme dali přednost typu io1, který nabízí trvale vysokou propustnost.

Typy instancí

Výkon Kafky je vysoce závislý na mezipaměti stránek operačního systému, takže potřebujeme instance s dostatkem paměti pro brokery (JVM) a mezipaměť stránek. Instance c5.2xvelký - dobrý začátek, protože má 16 GB paměti a optimalizované pro práci s EBS. Jeho nevýhodou je, že je schopen poskytovat maximální výkon pouze po dobu maximálně 30 minut každých 24 hodin. Pokud vaše pracovní zatížení vyžaduje špičkový výkon po delší dobu, možná budete chtít zvážit jiné typy instancí. Přesně to jsme udělali, zastavili jsme se u toho c5.4xvelký. Poskytuje maximální propustnost 593,75 Mb/s. Maximální propustnost svazku EBS io1 vyšší než instance c5.4xvelký, takže nejpomalejším prvkem infrastruktury bude pravděpodobně I/O propustnost tohoto typu instance (což by měly potvrdit i naše zátěžové testy).

Síť

Propustnost sítě musí být dostatečně velká v porovnání s výkonem instance VM a disku, jinak se síť stane úzkým hrdlem. V našem případě síťové rozhraní c5.4xvelký podporuje rychlosti až 10 Gb/s, což je výrazně více než I/O propustnost instance VM.

Nasazení makléře

Brokeři by měli být nasazeni (naplánováno v Kubernetes) do vyhrazených uzlů, aby se vyhnuli konkurenci s jinými procesy o CPU, paměť, síť a diskové prostředky.

verze Java

Logickou volbou je Java 11, protože je kompatibilní s Dockerem v tom smyslu, že JVM správně určuje procesory a paměť dostupnou pro kontejner, ve kterém broker běží. S vědomím, že limity CPU jsou důležité, JVM interně a transparentně nastavuje počet vláken GC a vláken JIT. Použili jsme obrázek Kafka banzaicloud/kafka:2.13-2.4.0, která obsahuje Kafka verze 2.4.0 (Scala 2.13) na Javě 11.

Pokud se chcete dozvědět více o Javě/JVM na Kubernetes, podívejte se na naše následující příspěvky:

• Proč je moje Java aplikace OOMKilled;
• Jak správně nastavit velikost kontejnerů pro aplikace Java 10.

Nastavení paměti brokera

Existují dva klíčové aspekty konfigurace paměti brokera: nastavení pro JVM a pro Kubernetes pod. Limit paměti nastavený pro pod musí být větší než maximální velikost haldy, aby JVM mělo místo pro metaprostor Java, který se nachází v jeho vlastní paměti, a pro mezipaměť stránek operačního systému, kterou Kafka aktivně používá. V našich testech jsme spustili Kafka brokery s parametry -Xmx4G -Xms2Ga limit paměti pro modul byl 10 Gi. Pamatujte, že nastavení paměti pro JVM lze získat automaticky pomocí -XX:MaxRAMPercentage и -X:MinRAMPercentagena základě limitu paměti pro modul.

Nastavení procesoru brokera

Obecně řečeno, můžete zlepšit výkon zvýšením paralelismu zvýšením počtu vláken používaných Kafkou. Čím více procesorů má Kafka k dispozici, tím lépe. V našem testu jsme začínali s limitem 6 procesorů a postupně (pomocí iterací) zvýšili jejich počet na 15. Navíc jsme nastavili num.network.threads=12 v nastavení brokera zvýšit počet vláken, která přijímají data ze sítě a odesílají je. Okamžitě zjistili, že sledující makléři nedokážou dostat repliky dostatečně rychle, zvýšili hlas num.replica.fetchers na 4, aby se zvýšila rychlost, s jakou zprostředkovatelé sledujících replikovali zprávy od vedoucích.

Nástroj pro generování zatížení

Měli byste zajistit, aby zvolenému generátoru zatížení nedošla kapacita dříve, než cluster Kafka (který je testován) dosáhne maximálního zatížení. Jinými slovy, je nutné provést předběžné posouzení schopností nástroje pro generování zátěže a také pro něj vybrat typy instancí s dostatečným počtem procesorů a paměti. V tomto případě bude náš nástroj produkovat větší zátěž, než dokáže cluster Kafka zvládnout. Po mnoha experimentech jsme se rozhodli pro tři kopie c5.4xvelký, z nichž každý měl spuštěný generátor.

Benchmarking

Měření výkonu je iterativní proces, který zahrnuje následující fáze:

• nastavení infrastruktury (klastr EKS, cluster Kafka, nástroj pro generování zátěže, stejně jako Prometheus a Grafana);
• generování zátěže po určitou dobu pro filtrování náhodných odchylek ve shromážděných ukazatelích výkonu;
• úprava infrastruktury a konfigurace brokera na základě pozorovaných ukazatelů výkonnosti;
• opakování procesu, dokud není dosaženo požadované úrovně propustnosti clusteru Kafka. Zároveň musí být důsledně reprodukovatelné a vykazovat minimální odchylky v propustnosti.

Další část popisuje kroky, které byly provedeny během procesu benchmarkingu testovacího clusteru.

Nástroje

K rychlému nasazení základní konfigurace, generování zatížení a měření výkonu byly použity následující nástroje:

• Banzai Cloud Pipeline pro organizaci clusteru EKS od Amazonu c Prometheus (pro sběr Kafkových a infrastrukturních metrik) a grafana (pro vizualizaci těchto metrik). Využili jsme toho integrovaný в Potrubí služby, které poskytují federované monitorování, centralizovaný sběr protokolů, skenování zranitelnosti, zotavení po havárii, zabezpečení na podnikové úrovni a mnoho dalšího.
• Sangrenel — nástroj pro zátěžové testování clusteru Kafka.
• Dashboardy Grafana pro vizualizaci Kafkových metrik a infrastruktury: Kubernetes Kafka, Exportér uzlů.
• Supertubes CLI pro nejjednodušší způsob, jak nastavit cluster Kafka na Kubernetes. Zookeeper, operátor Kafka, Envoy a mnoho dalších komponent jsou nainstalovány a správně nakonfigurovány pro provoz produkčního Kafka clusteru na Kubernetes.
  • Chcete-li nainstalovat supertubes CLI použijte dodané pokyny zde.

cluster EKS

Připravte cluster EKS s vyhrazenými pracovními uzly c5.4xvelký v různých zónách dostupnosti pro moduly s makléři Kafka, stejně jako vyhrazené uzly pro generátor zátěže a monitorovací infrastrukturu.

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

Jakmile je cluster EKS spuštěn a spuštěn, povolte jeho integraci monitorovací služba — rozmístí Promethea a Grafana do klastru.

Komponenty systému Kafka

Nainstalujte komponenty systému Kafka (Zookeeper, kafka-operator) do EKS pomocí supertubes CLI:

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

Kafkův klastr

Ve výchozím nastavení používá EKS svazky typu EBS gp2, takže musíte vytvořit samostatnou třídu úložiště na základě svazků io1 pro klastr 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 parametr pro brokery min.insync.replicas=3 a nasadit moduly brokerů na uzly ve třech různých zónách 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émata

Paralelně jsme spustili tři instance generátoru zatížení. Každý z nich píše do svého vlastního tématu, to znamená, že potřebujeme celkem tři témata:

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

Pro každé téma je replikační faktor 3 – minimální doporučená hodnota pro vysoce dostupné produkční systémy.

Nástroj pro generování zatížení

Spustili jsme tři kopie generátoru zatížení (každá psala do samostatného tématu). U modulů generátoru zatížení je třeba nastavit afinitu uzlů tak, aby byly naplánovány pouze na uzlech, které jsou jim přiděleny:

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ěkolik bodů k poznámce:

• Generátor zátěže generuje zprávy o délce 512 bajtů a publikuje je Kafkovi v dávkách po 500 zprávách.
• Použití argumentu -required-acks=all Publikace je považována za úspěšnou, když jsou všechny synchronizované repliky zprávy přijaty a potvrzeny makléři Kafka. To znamená, že v benchmarku jsme měřili nejen rychlost lídrů přijímajících zprávy, ale také jejich následovníků replikujících zprávy. Účelem tohoto testu není hodnotit rychlost čtení spotřebitelů (spotřebitelé) nedávno přijaté zprávy, které stále zůstávají v mezipaměti stránky OS, a její porovnání s rychlostí čtení zpráv uložených na disku.
• Generátor zátěže provozuje paralelně 20 pracovníků (-workers=20). Každý pracovník obsahuje 5 producentů, kteří sdílejí připojení pracovníka ke clusteru Kafka. Výsledkem je, že každý generátor má 100 výrobců a všichni posílají zprávy do clusteru Kafka.

Sledování stavu clusteru

Během zátěžového testování clusteru Kafka jsme také sledovali jeho stav, abychom se ujistili, že nedochází k restartování modulu, nesynchronizovaným replikám a maximální propustnost s minimálními výkyvy:

• Generátor zatížení vypisuje standardní statistiky o počtu publikovaných zpráv a chybovosti. Chybovost by měla zůstat stejná 0,00%.
• Tempomat, nasazený kafka-operator, poskytuje dashboard, kde můžeme také sledovat stav clusteru. Chcete-li zobrazit tento panel, postupujte takto:

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

• úroveň ISR (počet „synchronizovaných“ replik) smrštění a roztažení se rovná 0.

Výsledky měření

3 brokeři, velikost zprávy - 512 bajtů

S oddíly rovnoměrně rozdělenými mezi tři brokery jsme byli schopni dosáhnout výkonu ~500 Mb/s (přibližně 990 tisíc zpráv za sekundu):

Spotřeba paměti virtuálního stroje JVM nepřesáhla 2 GB:

Propustnost disku dosáhla maximální propustnosti I/O uzlu ve všech třech instancích, na kterých zprostředkovatelé běželi:

Z údajů o využití paměti uzly vyplývá, že ukládání do vyrovnávací paměti a ukládání do mezipaměti trvalo ~10–15 GB:

3 brokeři, velikost zprávy - 100 bajtů

Jak se velikost zprávy zmenšuje, propustnost klesá přibližně o 15-20%: čas strávený zpracováním každé zprávy to ovlivňuje. Vytížení procesoru se navíc téměř zdvojnásobilo.

Vzhledem k tomu, že uzly zprostředkovatele mají stále nevyužitá jádra, lze výkon zlepšit změnou konfigurace Kafka. To není snadný úkol, takže pro zvýšení propustnosti je lepší pracovat s většími zprávami.

4 brokeři, velikost zprávy - 512 bajtů

Výkon Kafka clusteru můžete snadno zvýšit jednoduchým přidáním nových brokerů a udržováním rovnováhy mezi oddíly (to zajistí, že zátěž je rovnoměrně rozdělena mezi brokery). V našem případě se po přidání brokera propustnost clusteru zvýšila na ~580 Mb/s (~1,1 milionu zpráv za sekundu). Růst se ukázal být nižší, než se očekávalo: vysvětluje se to především nevyvážeností oddílů (ne všichni brokeři pracují na vrcholu svých schopností).

Spotřeba paměti stroje JVM zůstala pod 2 GB:

Práce makléřů s disky byla ovlivněna nerovnováhou oddílů:

Závěry

Iterativní přístup uvedený výše lze rozšířit tak, aby pokryl složitější scénáře zahrnující stovky spotřebitelů, přerozdělování, postupné aktualizace, restartování modulu atd. To vše nám umožňuje posoudit limity schopností clusteru Kafka v různých podmínkách, identifikovat úzká místa v jeho provozu a najít způsoby, jak s nimi bojovat.

Navrhli jsme Supertubes pro rychlé a snadné nasazení clusteru, jeho konfiguraci, přidávání/odebírání brokerů a témat, reagování na výstrahy a zajištění správného fungování Kafky na Kubernetes. Naším cílem je pomoci vám soustředit se na hlavní úkol („generovat“ a „spotřebovat“ zprávy Kafka) a přenechat veškerou tvrdou práci Supertubes a operátorovi Kafka.

Pokud vás zajímají technologie Banzai Cloud a projekty Open Source, sledujte společnost na adrese GitHub, LinkedIn nebo X.

PS od překladatele

Přečtěte si také na našem blogu:

• «Jeden příběh s operátorem Redis v K8s a minirevize nástrojů pro analýzu dat z této databáze";
• «Bezproblémová migrace RabbitMQ na Kubernetes";
• «zetcd z CoreOS: Nahrazení ZooKeeperu úložištěm...etcd".

Zdroj: www.habr.com