Одредување на соодветната големина за кластерот Кафка во Кубернетес

Забелешка. превод.: Во оваа статија, Banzai Cloud споделува пример за тоа како неговите сопствени алатки може да се користат за да се олесни користењето на Кафка во Kubernetes. Следниве инструкции илустрираат како можете да ја одредите оптималната големина на вашата инфраструктура и да го конфигурирате самиот Кафка за да ја постигне потребната пропусност.

Apache Kafka е дистрибуирана платформа за стриминг за создавање сигурни, скалабилни и со високи перформанси системи за стриминг во реално време. Неговите импресивни способности може да се прошират со користење на Kubernetes. За ова развивме Оператор Кафка со отворен код и алатка наречена Суперцевки. Тие ви дозволуваат да го стартувате Кафка на Kubernetes и да ги користите неговите различни функции, како што се дотерување на конфигурацијата на брокерот, скалирање базирано на метрика со ребалансирање, свесност за решетката, „меко“ (грациозно) објавување ажурирања, итн.

Пробајте ги Supertubes во вашиот кластер:

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

Или контактирајте документација. Можете да прочитате и за некои од можностите на Кафка, работата со која е автоматизирана со помош на Supertubes и Kafka оператор. Веќе пишувавме за нив на блогот:

• О не! Уште еден оператор на Кафка за Кубернетес;
• Следете го и управувајте со Кафка врз основа на метриката на Прометеј;
• Свеста за решетката за Кафка на Кубернет;
• Трчање на Апачи Кафка над Истио - репер;
• Корисникот автентицирал и контролирал пристап кластери со операторот Кафка;
• Надградба на тркалање на Kafka и динамична конфигурација на Kubernetes;
• Филтер за протокол на пратеник за Кафка, мрежен.

Кога ќе одлучите да распоредите кластер на Кафка на Кубернетес, најверојатно ќе се соочите со предизвикот да ја одредите оптималната големина на основната инфраструктура и потребата да ја дотерате вашата конфигурација на Кафка за да ги исполните барањата за пропусната моќ. Максималните перформанси на секој брокер се одредуваат според перформансите на основните инфраструктурни компоненти, како што се меморијата, процесорот, брзината на дискот, мрежниот опсег итн.

Идеално, конфигурацијата на брокерот треба да биде таква што сите инфраструктурни елементи се користат до нивните максимални можности. Меѓутоа, во реалниот живот ова поставување е доста сложено. Поверојатно е дека корисниците ќе ги конфигурираат брокерите да ја максимизираат употребата на една или две компоненти (диск, меморија или процесор). Општо земено, брокерот покажува максимални перформанси кога неговата конфигурација дозволува најбавната компонента да се користи до максимум. На овој начин можеме да добиеме груба идеја за товарот што може да го поднесе еден брокер.

Теоретски, можеме да го процениме и бројот на брокери потребни за да се справат со одреден товар. Меѓутоа, во пракса има толку многу опции за конфигурација на различни нивоа што е многу тешко (ако не и невозможно) да се оцени потенцијалната изведба на одредена конфигурација. Со други зборови, многу е тешко да се планира конфигурација врз основа на некои дадени перформанси.

За корисниците на Supertubes, ние обично го користиме следниов пристап: започнуваме со одредена конфигурација (инфраструктура + поставки), потоа ги мериме неговите перформанси, ги прилагодуваме поставките на брокерот и го повторуваме процесот повторно. Ова се случува додека најспората компонента на инфраструктурата не биде целосно искористена.

На овој начин, добиваме појасна идеја за тоа колку брокери треба на еден кластер да се справи со одреден товар (бројот на брокери зависи и од други фактори, како што е минималниот број на реплики на пораки за да се обезбеди еластичност, бројот на партиции лидери итн.). Дополнително, добиваме увид во кои инфраструктурни компоненти бараат вертикално скалирање.

Оваа статија ќе зборува за чекорите што ги преземаме за да го извлечеме максимумот од најбавните компоненти во почетните конфигурации и да ја измериме пропусната моќ на кластерот Кафка. За многу еластична конфигурација потребни се најмалку три активни брокери (min.insync.replicas=3), дистрибуирани низ три различни зони за пристапност. За да ја конфигурираме, размериме и следиме инфраструктурата Кубернетес, ние користиме сопствена платформа за управување со контејнери за хибридни облаци - Гасоводот. Поддржува on-premise (гол метал, VMware) и пет типа облаци (Alibaba, AWS, Azure, Google, Oracle), како и секоја нивна комбинација.

Размислувања за инфраструктурата и конфигурацијата на кластерот Кафка

За примерите подолу, го избравме AWS како давател на облак и EKS како дистрибуција на Kubernetes. Слична конфигурација може да се имплементира со користење ПКЕ - Дистрибуција на Kubernetes од Banzai Cloud, сертифицирана од CNCF.

диск

Амазон нуди различни Типови на јачина на EBS. Во сржта gp2 и io1 има SSD-дискови, сепак, за да се обезбеди висока пропусност gp2 троши акумулирани кредити (В/И кредити), па го претпочитавме типот io1, кој нуди постојана висока пропусност.

Видови на примери

Перформансите на Кафка се многу зависни од кешот на страниците на оперативниот систем, така што ни требаат примероци со доволно меморија за брокерите (JVM) и кешот на страниците. Пример c5.2xголем - добар почеток, бидејќи има 16 GB меморија и оптимизиран за работа со EBS. Неговиот недостаток е тоа што е способен да обезбеди максимални перформанси не повеќе од 30 минути на секои 24 часа. Ако вашиот обем на работа бара врвни перформанси во подолг временски период, можеби ќе сакате да размислите за други типови на примероци. Тоа е токму она што го направивме, застанувајќи на c5.4xголем. Обезбедува максимална пропусност во 593,75 Mbps. Максимална пропусност на јачина на EBS io1 повисока од инстанцата c5.4xголем, така што најбавниот елемент на инфраструктурата најверојатно е пропусната моќ на В/И од овој тип на пример (што треба да го потврдат и нашите тестови за оптоварување).

Мрежа

Пропусната моќ на мрежата мора да биде доволно голема во споредба со перформансите на примерокот на VM и дискот, инаку мрежата станува тесно грло. Во нашиот случај, мрежниот интерфејс c5.4xголем поддржува брзини до 10 Gb/s, што е значително повисоко од протокот на влез/излез на примерок на VM.

Распоредување на брокер

Брокерите треба да бидат распоредени (закажани во Кубернетес) на посветени јазли за да се избегне конкуренција со други процеси за процесорот, меморијата, мрежата и ресурсите на дискот.

Јава верзија

Логичниот избор е Java 11 бидејќи е компатибилен со Docker во смисла дека JVM правилно ги одредува процесорите и меморијата достапни за контејнерот во кој работи брокерот. Знаејќи дека ограничувањата на процесорот се важни, JVM внатрешно и транспарентно го поставува бројот на GC нишки и JIT нишки. Ја користевме сликата на Кафка banzaicloud/kafka:2.13-2.4.0, која ја вклучува верзијата на Кафка 2.4.0 (Scala 2.13) на Java 11.

Ако сакате да дознаете повеќе за Java/JVM на Kubernetes, проверете ги нашите следни објави:

• Зошто мојата Java апликација е OOMKilled;
• Како правилно да ги големината на контејнерите за Java 10 апликации.

Поставки за меморија на брокерот

Постојат два клучни аспекти за конфигурирање на брокерската меморија: поставки за JVM и за Kubernetes pod. Ограничувањето за меморија поставено за подлога мора да биде поголемо од максималната големина на купот, така што JVM-от има простор за метапросторот Јава што се наоѓа во сопствената меморија и за кешот на страниците на оперативниот систем што Кафка активно го користи. Во нашите тестови ги лансиравме брокерите на Кафка со параметри -Xmx4G -Xms2G, а ограничувањето на меморијата за подлогата беше 10 Gi. Ве молиме имајте предвид дека поставките за меморија за JVM може да се добијат автоматски со користење -XX:MaxRAMPercentage и -X:MinRAMPercentage, врз основа на ограничувањето на меморијата за подлогата.

Поставки на процесорот на брокерот

Општо земено, можете да ги подобрите перформансите со зголемување на паралелизмот со зголемување на бројот на нишки што ги користи Кафка. Колку повеќе процесори се достапни за Кафка, толку подобро. Во нашиот тест, започнавме со ограничување од 6 процесори и постепено (преку повторувања) го подигнавме нивниот број на 15. Покрај тоа, поставивме num.network.threads=12 во поставките на брокерот за да го зголемите бројот на нишки кои примаат податоци од мрежата и ги испраќаат. Веднаш открија дека следбениците брокери не можат да добијат реплики доволно брзо, тие покренаа num.replica.fetchers до 4 за да се зголеми брзината со која брокерите кои следат ги реплицираат пораките од лидерите.

Оптоварување генерирање алатка

Треба да се погрижите избраниот генератор на оптоварување да не остане без капацитет пред кластерот Кафка (кој се мери) да го достигне своето максимално оптоварување. Со други зборови, неопходно е да се спроведе прелиминарна проценка на можностите на алатката за генерирање оптоварување, а исто така да се изберат типови на примероци за него со доволен број процесори и меморија. Во овој случај, нашата алатка ќе произведе повеќе оптоварување отколку што може да поднесе кластерот Кафка. По многу експерименти, се решивме на три примероци c5.4xголем, од кои секоја имаше генератор што работи.

Бенчмаркинг

Мерењето на перформансите е итеративен процес кој ги вклучува следните фази:

• поставување инфраструктура (Кластер ЕКС, кластер Кафка, алатка за генерирање оптоварување, како и Прометеј и Графана);
• генерирање на оптоварување за одреден период за филтрирање на случајни отстапувања во собраните индикатори за изведба;
• прилагодување на инфраструктурата и конфигурацијата на брокерот врз основа на набљудуваните индикатори за изведба;
• повторување на процесот додека не се постигне потребното ниво на пропусност на кластерот Кафка. Во исто време, тој мора постојано да се репродуцира и да демонстрира минимални варијации во пропусната моќ.

Следниот дел ги опишува чекорите што беа извршени за време на процесот на бенчмаркирање на тест кластерот.

Алатки

Следниве алатки беа користени за брзо распоредување на основната конфигурација, генерирање оптоварувања и мерење на перформансите:

• Гасовод за облак Банзаи за организирање на EKS кластер од Amazon в Прометеј (да се соберат метрика на Кафка и инфраструктура) и Графана (да се визуелизираат овие метрики). Ние ја искористивме предноста интегриран в Гасоводот услуги кои обезбедуваат федерален мониторинг, централизирано собирање на дневници, скенирање на ранливост, враќање при катастрофи, безбедност од ниво на претпријатие и многу повеќе.
• Сангренел — алатка за тестирање на оптоварување на кластерот Кафка.
• Графана контролни табли за визуелизација на метриката и инфраструктурата на Кафка: Кубернетес Кафка, Извозник на јазли.
• Supertubes CLI за најлесниот начин да поставите кластер на Кафка на Kubernetes. Zookeeper, Kafka operator, Envoy и многу други компоненти се инсталирани и соодветно конфигурирани за да се кандидира кластерот на Kafka подготвен за производство на Kubernetes.
  • Да се ​​инсталира суперцевки CLI користете ги дадените упатства тука.

Кластерот ЕКС

Подгответе EKS кластер со посветени работнички јазли c5.4xголем во различни зони на достапност за мешунки со брокери на Кафка, како и наменски јазли за генератор на оптоварување и инфраструктура за следење.

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

Штом кластерот EKS ќе се вклучи и работи, овозможете го неговото интегрирано служба за следење - таа ќе ги распореди Прометеј и Графана во кластер.

Компоненти на системот Кафка

Инсталирајте ги компонентите на системот Кафка (Zookeeper, kafka-оператор) во EKS користејќи суперцевки CLI:

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

Кластерот Кафка

Стандардно, EKS користи EBS томови од типот gp2, така што треба да креирате посебна класа за складирање врз основа на волумени io1 за кластерот Кафка:

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

Поставете го параметарот за брокери min.insync.replicas=3 и распореди брокерски подлоги на јазли во три различни зони на достапност:

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

Теми

Направивме три примери на генератор на оптоварување паралелно. Секој од нив пишува на својата тема, односно ни требаат вкупно три теми:

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

За секоја тема, факторот на репликација е 3 - минималната препорачана вредност за високо достапни производствени системи.

Оптоварување генерирање алатка

Лансиравме три копии од генераторот на оптоварување (секој од нив напиша во посебна тема). За подлоги за генератор на оптоварување, треба да го поставите афинитетот на јазлите така што тие да се закажани само на јазлите доделени за нив:

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

Неколку точки што треба да се забележат:

• Генераторот на оптоварување генерира пораки во должина од 512 бајти и ги објавува на Кафка во серии од 500 пораки.
• Користење на аргумент -required-acks=all Објавувањето се смета за успешно кога сите синхронизирани реплики на пораката се примени и потврдени од брокерите на Кафка. Ова значи дека во реперот ја измеривме не само брзината на лидерите кои примаат пораки, туку и нивните следбеници кои ги повторуваат пораките. Целта на овој тест не е да се оцени брзината на читање на потрошувачите (потрошувачи) неодамна примените пораки кои сè уште остануваат во кешот на страниците на ОС и нејзината споредба со брзината на читање на пораките зачувани на дискот.
• Генераторот на оптоварување работи 20 работници паралелно (-workers=20). Секој работник содржи 5 производители кои ја делат врската на работникот со кластерот Кафка. Како резултат на тоа, секој генератор има 100 производители и сите тие испраќаат пораки до кластерот Кафка.

Следење на здравјето на кластерот

За време на тестирањето на оптоварувањето на кластерот Кафка, го следевме и неговото здравје за да се осигураме дека нема рестартирање на подлогата, нема несинхронизирани реплики и максимална пропусност со минимални флуктуации:

• Генераторот на оптоварување пишува стандардна статистика за бројот на објавени пораки и стапката на грешка. Стапката на грешка треба да остане иста 0,00%.
• Круз контрола, распореден од кафка-оператор, обезбедува контролна табла каде што можеме да ја следиме состојбата на кластерот. За да го видите овој панел, направете:

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

• Ниво на ISR (број на „во синхронизирани“ реплики) собирањето и проширувањето се еднакви на 0.

Резултати од мерењето

3 брокери, големина на порака - 512 бајти

Со рамномерно распоредени партиции на три брокери, успеавме да постигнеме перформанси ~500 Mb/s (приближно 990 илјади пораки во секунда):

Потрошувачката на меморија на виртуелната машина JVM не надминува 2 GB:

Пропусната моќ на дискот ја достигна максималната пропусност на В/И јазол на сите три примери на кои работеа брокерите:

Од податоците за користењето на меморијата по јазли, следува дека системското баферирање и кеширање траело ~ 10-15 GB:

3 брокери, големина на порака - 100 бајти

Како што се намалува големината на пораката, пропусната моќ се намалува за приближно 15-20%: времето поминато за обработка на секоја порака влијае на тоа. Покрај тоа, оптоварувањето на процесорот е речиси двојно зголемено.

Бидејќи брокерските јазли сè уште имаат неискористени јадра, перформансите може да се подобрат со промена на конфигурацијата на Кафка. Ова не е лесна задача, па за да се зголеми пропусната моќ, подобро е да се работи со поголеми пораки.

4 брокери, големина на порака - 512 бајти

Можете лесно да ги зголемите перформансите на кластерот Кафка со едноставно додавање на нови брокери и одржување на рамнотежа на партициите (ова осигурува дека товарот е рамномерно распределен помеѓу брокерите). Во нашиот случај, по додавањето на брокер, пропусната моќ на кластерот се зголеми на ~580 Mb/s (~1,1 милиони пораки во секунда). Растот се покажа како помал од очекуваниот: ова главно се објаснува со нерамнотежата на партициите (не сите брокери работат на врвот на нивните способности).

Потрошувачката на меморија на JVM машината остана под 2 GB:

Работата на брокерите со дискови беше под влијание на нерамнотежата на партициите:

Наоди

Итеративниот пристап претставен погоре може да се прошири за да покрие посложени сценарија кои вклучуваат стотици потрошувачи, препартиционирање, ажурирања во тек, рестартирање на подлоги итн. Сето ова ни овозможува да ги процениме границите на можностите на кластерот Кафка во различни услови, да ги идентификуваме тесните грла во неговото работење и да најдеме начини за борба против нив.

Дизајниравме Supertubes за брзо и лесно распоредување кластер, негово конфигурирање, додавање/отстранување на брокери и теми, одговарање на предупредувања и обезбедување на Кафка воопшто да работи правилно на Kubernetes. Нашата цел е да ви помогнеме да се концентрирате на главната задача („генерирање“ и „конзумирање“ на пораките на Кафка), а целата напорна работа да ја оставиме на Supertubes и на операторот на Кафка.

Ако сте заинтересирани за Banzai Cloud технологии и проекти со отворен код, претплатете се на компанијата на GitHub, Скопје или Twitter.

PS од преведувач

Прочитајте и на нашиот блог:

• «Една приказна со операторот Redis во K8s и мини-преглед на комуналните услуги за анализа на податоците од оваа база на податоци";
• «Беспрекорна миграција на RabbitMQ во Kubernetes";
• «zetcd од CoreOS: Замена на ZooKeeper со складирање...etcd".

Извор: www.habr.com