Kubernetesdagi Kafka klasteri uchun mos hajmni aniqlash

Eslatma. tarjima.: Ushbu maqolada Banzai Cloud, Kafkadan Kubernetes ichida foydalanishni osonlashtirish uchun uning maxsus vositalaridan qanday foydalanish mumkinligi haqidagi misol bilan o'rtoqlashadi. Quyidagi ko'rsatmalar sizning infratuzilmangizning optimal hajmini qanday aniqlashingiz va kerakli o'tkazuvchanlikka erishish uchun Kafkaning o'zini qanday sozlashingiz mumkinligini ko'rsatadi.

Apache Kafka ishonchli, kengaytiriladigan va yuqori unumli real vaqtda oqim tizimlarini yaratish uchun taqsimlangan oqim platformasidir. Uning ta'sirchan imkoniyatlarini Kubernetes yordamida kengaytirish mumkin. Buning uchun biz ishlab chiqdik Ochiq kodli Kafka operatori va vosita deb ataladi Supertrubalar. Ular sizga Kafka-ni Kubernetes-da ishga tushirishga va uning turli xil xususiyatlaridan foydalanishga imkon beradi, masalan, broker konfiguratsiyasini nozik sozlash, muvozanatlash bilan metrikaga asoslangan masshtablash, rack xabardorligi, "yumshoq" (odobli) yangilanishlarni tarqatish va boshqalar.

Klasteringizda Supertubes-ni sinab ko'ring:

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

Yoki aloqa hujjatlar. Shuningdek, Kafkaning ba'zi imkoniyatlari haqida o'qishingiz mumkin, ular bilan ishlash Supertubes va Kafka operatori yordamida avtomatlashtirilgan. Biz ular haqida allaqachon blogda yozganmiz:

• Oh yo'q! Kubernetes uchun yana bir Kafka operatori;
• Prometey ko'rsatkichlari asosida Kafkani kuzatib boring va boshqaring;
• Kubernetesda Kafka rack xabardorligi;
• Apache Kafkani Istio orqali ishga tushirish - benchmark;
• Kafka operatori yordamida foydalanuvchi autentifikatsiya qilingan va boshqariladigan klasterlarga kirish;
• Kubernetes-da Kafkani yangilash va dinamik konfiguratsiya;
• Kafka uchun elchi protokol filtri, meshed.

Kubernetes-da Kafka klasterini joylashtirishga qaror qilganingizda, siz asosiy infratuzilmaning optimal hajmini aniqlash va o'tkazish qobiliyati talablariga javob berish uchun Kafka konfiguratsiyasini nozik sozlash zarurati bilan duch kelishingiz mumkin. Har bir brokerning maksimal ishlashi xotira, protsessor, disk tezligi, tarmoq o'tkazish qobiliyati va boshqalar kabi asosiy infratuzilma komponentlarining ishlashi bilan belgilanadi.

Ideal holda, broker konfiguratsiyasi shunday bo'lishi kerakki, barcha infratuzilma elementlari o'zlarining maksimal imkoniyatlaridan foydalaniladi. Biroq, haqiqiy hayotda bu o'rnatish juda murakkab. Foydalanuvchilar brokerlarni bir yoki ikkita komponentdan (disk, xotira yoki protsessor) maksimal darajada foydalanish uchun sozlashlari ehtimoli katta. Umuman olganda, broker konfiguratsiyasi eng sekin komponentdan to'liq foydalanishga imkon berganda maksimal ishlashni ko'rsatadi. Shunday qilib, biz bitta broker ko'tara oladigan yuk haqida taxminiy tasavvurga ega bo'lishimiz mumkin.

Nazariy jihatdan, biz ma'lum bir yukni ko'tarish uchun zarur bo'lgan brokerlar sonini ham taxmin qilishimiz mumkin. Biroq, amalda turli darajadagi konfiguratsiya variantlari shunchalik ko'pki, ma'lum bir konfiguratsiyaning potentsial ishlashini baholash juda qiyin (agar imkonsiz bo'lsa). Boshqacha qilib aytadigan bo'lsak, ba'zi berilgan ishlashga asoslangan konfiguratsiyani rejalashtirish juda qiyin.

Supertubes foydalanuvchilari uchun biz odatda quyidagi yondashuvni qo'llaymiz: biz ba'zi konfiguratsiyalardan (infratuzilma + sozlamalari) boshlaymiz, so'ngra uning ish faoliyatini o'lchaymiz, broker sozlamalarini sozlaymiz va jarayonni yana takrorlaymiz. Bu infratuzilmaning eng sekin komponenti to'liq foydalanilgunga qadar sodir bo'ladi.

Shunday qilib, biz klasterga ma'lum bir yukni ko'tarish uchun qancha broker kerakligi haqida aniqroq tasavvurga ega bo'lamiz (brokerlar soni boshqa omillarga ham bog'liq, masalan, moslashuvchanlikni ta'minlash uchun xabarlar replikalarining minimal soni, bo'limlar soni. rahbarlar va boshqalar). Bundan tashqari, biz qaysi infratuzilma komponentlari vertikal masshtabni talab qilishini tushunamiz.

Ushbu maqolada biz boshlang'ich konfiguratsiyalardagi eng sekin komponentlardan maksimal darajada foydalanish va Kafka klasterining o'tkazuvchanligini o'lchash uchun qanday qadamlar qo'yilishi haqida gapiramiz. Yuqori moslashuvchan konfiguratsiya kamida uchta ishlaydigan brokerni talab qiladi (min.insync.replicas=3), uchta turli qulaylik zonalarida taqsimlangan. Kubernetes infratuzilmasini sozlash, masshtablash va monitoring qilish uchun biz gibrid bulutlar uchun konteynerlarni boshqarish platformamizdan foydalanamiz - quvuri. U mahalliy (yalang'och metall, VMware) va besh turdagi bulutlarni (Alibaba, AWS, Azure, Google, Oracle) hamda ularning har qanday kombinatsiyasini qo'llab-quvvatlaydi.

Kafka klasteri infratuzilmasi va konfiguratsiyasi haqidagi fikrlar

Quyidagi misollar uchun biz bulut provayderi sifatida AWS va Kubernetes tarqatish sifatida EKS ni tanladik. Shu kabi konfiguratsiya yordamida amalga oshirilishi mumkin P.K.E. - CNCF tomonidan sertifikatlangan Banzai Cloud-dan Kubernetes tarqatish.

disk

Amazon turli xil takliflarni taklif qiladi EBS hajmi turlari. Asosiyda gp2 и io1 Biroq, yuqori o'tkazuvchanlikni ta'minlash uchun SSD drayvlar mavjud gp2 to'plangan kreditlarni iste'mol qiladi (I/O kreditlari), shuning uchun biz turni afzal ko'rdik io1, bu doimiy yuqori o'tkazuvchanlikni ta'minlaydi.

Namuna turlari

Kafkaning ishlashi operatsion tizimning sahifa keshiga juda bog'liq, shuning uchun bizga brokerlar (JVM) va sahifa keshi uchun etarli xotiraga ega bo'lgan misollar kerak. Misol c5.2x katta - yaxshi boshlanish, chunki u 16 GB xotiraga ega va EBS bilan ishlash uchun optimallashtirilgan. Kamchiliklari shundaki, u har 30 soatda 24 daqiqadan ko'p bo'lmagan maksimal ishlashni ta'minlashga qodir. Agar sizning ish yukingiz uzoq vaqt davomida eng yuqori ishlashni talab qilsa, boshqa misol turlarini ko'rib chiqishingiz mumkin. Aynan shunday qildik, to'xtadik c5.4x katta. U maksimal o'tkazuvchanlikni ta'minlaydi 593,75 Mb/s. EBS hajmining maksimal o'tkazuvchanligi io1 misoldan yuqori c5.4x katta, shuning uchun infratuzilmaning eng sekin elementi, ehtimol, ushbu namuna turining kiritish/chiqarish o'tkazuvchanligi bo'lishi mumkin (buni bizning yuk testlarimiz ham tasdiqlashi kerak).

Tarmoq

Tarmoqning o'tkazuvchanligi VM nusxasi va diskning ishlashi bilan solishtirganda etarlicha katta bo'lishi kerak, aks holda tarmoq muammoga aylanadi. Bizning holatda, tarmoq interfeysi c5.4x katta 10 Gb/s gacha tezlikni qo‘llab-quvvatlaydi, bu esa VM instansiyasining kiritish/chiqarish qobiliyatidan sezilarli darajada yuqori.

Brokerni joylashtirish

Protsessor, xotira, tarmoq va disk resurslari uchun boshqa jarayonlar bilan raqobatlashmaslik uchun brokerlar ajratilgan tugunlarga joylashtirilishi kerak (Kubernetesda rejalashtirilgan).

Java versiyasi

Mantiqiy tanlov Java 11, chunki u Docker bilan mos keladi, ya'ni JVM broker ishlayotgan konteyner uchun mavjud protsessorlar va xotirani to'g'ri aniqlaydi. Protsessor chegaralari muhim ekanligini bilib, JVM ichki va shaffof tarzda GC va JIT iplari sonini o'rnatadi. Biz Kafka tasviridan foydalandik banzaicloud/kafka:2.13-2.4.0, Java 2.4.0 da Kafka 2.13 (Scala 11) versiyasini o'z ichiga oladi.

Agar siz Kubernetes-da Java/JVM haqida ko'proq bilmoqchi bo'lsangiz, quyidagi xabarlarimizga qarang:

• Nima uchun mening Java ilovam OOMKilled;
• Java 10 ilovalari uchun konteynerlarni qanday qilib to'g'ri o'lchash mumkin.

Broker xotirasi sozlamalari

Broker xotirasini sozlashning ikkita asosiy jihati mavjud: JVM va Kubernetes pod uchun sozlamalar. JVM o'z xotirasida joylashgan Java metafazosi va Kafka faol foydalanadigan operatsion tizim sahifa keshi uchun joy bo'lishi uchun pod uchun o'rnatilgan xotira chegarasi maksimal yig'ish hajmidan kattaroq bo'lishi kerak. Sinovlarimizda biz parametrlari bilan Kafka brokerlarini ishga tushirdik -Xmx4G -Xms2G, va pod uchun xotira chegarasi edi 10 Gi. E'tibor bering, JVM uchun xotira sozlamalari yordamida avtomatik ravishda olinishi mumkin -XX:MaxRAMPercentage и -X:MinRAMPercentage, pod uchun xotira chegarasiga asoslangan.

Broker protsessor sozlamalari

Umuman olganda, Kafka ishlatadigan iplar sonini ko'paytirish orqali parallellikni oshirish orqali ishlashni yaxshilash mumkin. Kafka uchun qancha protsessor mavjud bo'lsa, shuncha yaxshi. Sinovimizda biz 6 ta protsessor chegarasidan boshladik va asta-sekin (iteratsiyalar orqali) ularning sonini 15 taga oshirdik. Bundan tashqari, biz o'rnatdik. num.network.threads=12 broker sozlamalarida tarmoqdan ma'lumotlarni qabul qiluvchi va uni jo'natuvchi iplar sonini ko'paytirish uchun. Izdosh brokerlari replikalarni tezda qabul qila olmasligini darhol bilib, ular ko'tardilar num.replica.fetchers izdoshlar brokerlari rahbarlarning xabarlarini takrorlash tezligini oshirish uchun 4 ga.

Yuk yaratish vositasi

Tanlangan yuk generatorining Kafka klasteri (qiyoslanayotgan) maksimal yuklanish darajasiga yetguncha quvvati tugamasligiga ishonch hosil qilishingiz kerak. Boshqacha qilib aytganda, yukni yaratish vositasining imkoniyatlarini dastlabki baholash, shuningdek, etarli miqdordagi protsessor va xotiraga ega bo'lgan namuna turlarini tanlash kerak. Bunday holda, bizning vositamiz Kafka klasteri bardosh bera oladigan yukdan ko'proq yuk hosil qiladi. Ko'p tajribalardan so'ng biz uchta nusxaga qaror qildik c5.4x katta, ularning har birida ishlaydigan generator mavjud edi.

Benchmarking

Samaradorlikni o'lchash iterativ jarayon bo'lib, quyidagi bosqichlarni o'z ichiga oladi:

• infratuzilmani o'rnatish (EKS klasteri, Kafka klasteri, yuklarni ishlab chiqarish vositasi, shuningdek Prometey va Grafana);
• to'plangan ishlash ko'rsatkichlarida tasodifiy og'ishlarni filtrlash uchun ma'lum bir davr uchun yuk hosil qilish;
• kuzatilgan faoliyat ko‘rsatkichlari asosida broker infratuzilmasi va konfiguratsiyasini sozlash;
• Kafka klasterining kerakli o'tkazuvchanligi darajasiga erishilgunga qadar jarayonni takrorlash. Shu bilan birga, u doimiy ravishda takrorlanishi va o'tkazish qobiliyatidagi minimal o'zgarishlarni namoyish qilishi kerak.

Keyingi bo'lim test klasterini taqqoslash jarayonida bajarilgan qadamlarni tavsiflaydi.

asboblar

Asosiy konfiguratsiyani tezda o'rnatish, yuklarni yaratish va ishlashni o'lchash uchun quyidagi vositalar ishlatilgan:

• Banzay bulutli quvur liniyasi Amazondan EKS klasterini tashkil qilish uchun c Prometheus (Kafka va infratuzilma ko'rsatkichlarini to'plash uchun) va grafana (ushbu ko'rsatkichlarni tasavvur qilish uchun). Biz foyda oldik integratsiyalashgan в quvuri federal monitoring, markazlashtirilgan jurnallarni yig'ish, zaifliklarni skanerlash, ofatlarni tiklash, korporativ darajadagi xavfsizlik va boshqalarni ta'minlaydigan xizmatlar.
• Sangrenel — Kafka klasterini yukni sinash uchun vosita.
• Kafka ko'rsatkichlari va infratuzilmasini ko'rish uchun Grafana asboblar paneli: Kubernetes Kafka, Tugun eksportchisi.
• Kubernetes-da Kafka klasterini o'rnatishning eng oson usuli uchun Supertubes CLI. Zookeeper, Kafka operatori, Envoy va boshqa ko'plab komponentlar Kubernetesda ishlab chiqarishga tayyor Kafka klasterini ishga tushirish uchun o'rnatilgan va to'g'ri sozlangan.
  • O'rnatish uchun supertubalar CLI taqdim etilgan ko'rsatmalardan foydalaning shu yerda.

EKS klasteri

Maxsus ishchi tugunlari bilan EKS klasterini tayyorlang c5.4x katta Kafka brokerlari bilan pods uchun turli mavjud zonalarda, shuningdek yuk generatori va monitoring infratuzilmasi uchun ajratilgan tugunlar.

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

EKS klasteri ishga tushirilgandan so'ng uning integratsiyasini yoqing monitoring xizmati - u Prometey va Grafanani klasterga joylashtiradi.

Kafka tizimining komponentlari

Kafka tizimi komponentlarini (Zookeeper, kafka-operator) CLI supertubalari yordamida EKSga o'rnating:

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

Kafka klasteri

Odatiy bo'lib, EKS turi EBS hajmlaridan foydalanadi gp2, shuning uchun siz hajmlar asosida alohida saqlash sinfini yaratishingiz kerak io1 Kafka klasteri uchun:

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

Brokerlar uchun parametrni o'rnating min.insync.replicas=3 va uch xil mavjudlik zonalaridagi tugunlarga broker podkastlarini joylashtiring:

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

Mavzular

Biz uchta yuk generatorini parallel ravishda ishga tushirdik. Ularning har biri o'z mavzusiga yozadi, ya'ni bizga jami uchta mavzu kerak:

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

Har bir mavzu uchun replikatsiya koeffitsienti 3 ni tashkil qiladi - yuqori darajadagi ishlab chiqarish tizimlari uchun tavsiya etilgan minimal qiymat.

Yuk yaratish vositasi

Biz yuk generatorining uchta nusxasini ishga tushirdik (har biri alohida mavzuda yozgan). Yuklash generatorlari podkastlari uchun siz tugunlarning yaqinligini belgilashingiz kerak, shunda ular faqat ular uchun ajratilgan tugunlarga rejalashtirilgan:

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

E'tiborga olish kerak bo'lgan bir nechta fikrlar:

• Yuklash generatori uzunligi 512 bayt bo'lgan xabarlarni ishlab chiqaradi va ularni Kafkaga 500 ta xabarlar to'plamida nashr etadi.
• Argumentdan foydalanish -required-acks=all Xabarning barcha sinxronlashtirilgan nusxalari Kafka brokerlari tomonidan qabul qilinganda va tasdiqlanganda nashr muvaffaqiyatli hisoblanadi. Bu shuni anglatadiki, benchmarkda biz nafaqat liderlarning xabarlarni qabul qilish tezligini, balki ularning izdoshlarining xabarlarni takrorlash tezligini ham o'lchadik. Ushbu testning maqsadi iste'molchining o'qish tezligini baholash emas (iste'molchilar) OS sahifa keshida hali ham saqlanib qolgan yaqinda qabul qilingan xabarlar va uni diskda saqlangan xabarlarni o'qish tezligi bilan taqqoslash.
• Yuk generatori parallel ravishda 20 ishchini ishlaydi (-workers=20). Har bir ishchi ishchining Kafka klasteri bilan aloqasini baham ko'radigan 5 ta ishlab chiqaruvchidan iborat. Natijada, har bir generatorda 100 ta ishlab chiqaruvchi bor va ularning barchasi Kafka klasteriga xabarlar yuboradi.

Klasterning sog'lig'ini kuzatish

Kafka klasterini yuklashda sinovdan o'tkazish jarayonida biz podkastlarni qayta ishga tushirishlar, sinxronlashtirilmagan replikatsiyalar va minimal tebranishlar bilan maksimal o'tkazish qobiliyati yo'qligiga ishonch hosil qilish uchun uning holatini ham kuzatib bordik:

• Yuklash generatori chop etilgan xabarlar soni va xatolik darajasi haqida standart statistik ma'lumotlarni yozadi. Xato darajasi bir xil bo'lishi kerak 0,00%.
• Kruiz nazorati, kafka-operator tomonidan joylashtirilgan, biz klaster holatini kuzatishimiz mumkin bo'lgan asboblar panelini taqdim etadi. Ushbu panelni ko'rish uchun quyidagilarni bajaring:

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

• ISR darajasi ("sinxronlashtirilgan" nusxalar soni) qisqarish va kengayish 0 ga teng.

O'lchov natijalari

3 broker, xabar hajmi - 512 bayt

Bo'limlar uchta brokerga teng taqsimlanganligi sababli, biz ishlashga erishdik ~500 Mb/s (sekundiga taxminan 990 ming xabar):

JVM virtual mashinasining xotira iste'moli 2 GB dan oshmadi:

Diskning o'tkazuvchanligi brokerlar ishlayotgan uchta holatda ham maksimal kiritish/chiqarish tugunining o'tkazuvchanligiga yetdi:

Tugunlar bo'yicha xotiradan foydalanish ma'lumotlariga ko'ra, tizimni buferlash va keshlash ~10-15 Gb vaqtni oladi:

3 broker, xabar hajmi - 100 bayt

Xabar hajmi kamayishi bilan o'tkazish qobiliyati taxminan 15-20% ga kamayadi: har bir xabarni qayta ishlashga sarflangan vaqt unga ta'sir qiladi. Bundan tashqari, protsessor yuki deyarli ikki barobar oshdi.

Broker tugunlarida hali ham foydalanilmagan yadrolar borligi sababli, Kafka konfiguratsiyasini o'zgartirish orqali ishlash yaxshilanishi mumkin. Bu oson ish emas, shuning uchun o'tkazish qobiliyatini oshirish uchun kattaroq xabarlar bilan ishlash yaxshiroqdir.

4 broker, xabar hajmi - 512 bayt

Siz shunchaki yangi brokerlarni qo'shish va bo'limlar muvozanatini saqlash orqali Kafka klasterining unumdorligini osongina oshirishingiz mumkin (bu yuk brokerlar o'rtasida teng taqsimlanishini ta'minlaydi). Bizning holatda, brokerni qo'shgandan so'ng, klasterning o'tkazuvchanligi oshdi ~580 Mb/s (sekundiga ~1,1 million xabar). O'sish kutilganidan kamroq bo'ldi: bu asosan bo'limlarning nomutanosibligi bilan izohlanadi (barcha brokerlar o'z imkoniyatlarining eng yuqori cho'qqisida ishlamaydi).

JVM mashinasining xotira iste'moli 2 GB dan past bo'lib qoldi:

Disklar bilan brokerlarning ishlashiga bo'limlarning nomutanosibligi ta'sir ko'rsatdi:

topilmalar

Yuqorida keltirilgan iterativ yondashuv yuzlab iste'molchilarni o'z ichiga olgan yanada murakkab stsenariylarni qamrab olish uchun kengaytirilishi mumkin, qismlarga bo'linish, yangilanishlar, podkastlarni qayta ishga tushirish va hokazo. Bularning barchasi turli sharoitlarda Kafka klasterining imkoniyatlari chegaralarini baholash, uning faoliyatidagi qiyinchiliklarni aniqlash va ularga qarshi kurashish yo‘llarini topish imkonini beradi.

Biz Supertubes-ni klasterni tez va oson joylashtirish, uni sozlash, brokerlar va mavzularni qo‘shish/o‘chirish, ogohlantirishlarga javob berish va umuman Kafkaning Kubernetesda to‘g‘ri ishlashini ta’minlash uchun ishlab chiqdik. Bizning maqsadimiz diqqatni asosiy vazifaga (“Kafka xabarlarini yaratish” va “iste’mol qilish”) qaratishga yordam berish va barcha mashaqqatli ishni Supertubes va Kafka operatoriga topshirishdir.

Agar siz Banzai Cloud texnologiyalari va Open Source loyihalariga qiziqsangiz, quyidagi manzilda kompaniyaga obuna bo'ling GitHub, LinkedIn yoki Twitter.

Tarjimondan PS

Shuningdek, bizning blogimizda o'qing:

• «K8-dagi Redis operatori bilan bitta hikoya va ushbu ma'lumotlar bazasidan ma'lumotlarni tahlil qilish uchun yordamchi dasturlarni mini-ko'rib chiqish";
• «RabbitMQ-ning Kubernetes-ga uzluksiz ko'chishi";
• «CoreOS-dan zetcd: ZooKeeper-ni ... va hokazo xotira bilan almashtirish".

Manba: www.habr.com