Kubernetes-də Kafka klasteri üçün uyğun ölçüsü müəyyən edin

Qeyd. tərcümə.: Bu məqalədə Banzai Cloud, Kafkanın Kubernetes daxilində istifadəsini asanlaşdırmaq üçün onun xüsusi alətlərindən necə istifadə oluna biləcəyinə dair bir nümunə paylaşır. Aşağıdakı təlimatlar infrastrukturunuzun optimal ölçüsünü necə təyin edə biləcəyinizi və tələb olunan ötürmə qabiliyyətinə nail olmaq üçün Kafkanın özünü necə konfiqurasiya edə biləcəyinizi göstərir.

Apache Kafka etibarlı, genişlənən və yüksək performanslı real vaxt axın sistemləri yaratmaq üçün paylanmış axın platformasıdır. Onun təsir edici imkanları Kubernetes istifadə edərək genişləndirilə bilər. Bunun üçün biz inkişaf etmişik Açıq mənbəli Kafka operatoru və adlı alət Super borular. Onlar sizə Kafkanı Kubernetes-də işə salmağa və broker konfiqurasiyasının dəqiq tənzimlənməsi, balanslaşdırma ilə metrik əsaslı miqyaslama, rack məlumatlılığı, “yumşaq” kimi müxtəlif xüsusiyyətlərindən istifadə etməyə imkan verir. (zərif) yeniləmələrin yayılması və s.

Klasterinizdə Supertubes-i sınayın:

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

Və ya əlaqə saxlayın sənədləşdirmə. Supertubes və Kafka operatorundan istifadə etməklə işi avtomatlaşdırılan Kafkanın bəzi imkanları haqqında da oxuya bilərsiniz. Onlar haqqında artıq blogda yazmışıq:

• Oh yox! Kubernetes üçün daha bir Kafka operatoru;
• Prometey ölçüləri əsasında Kafkanı izləyin və idarə edin;
• Kubernetesdə Kafka şüurluluğu;
• Apache Kafkanın Istio üzərində işlədilməsi - etalon;
• Kafka operatoru ilə istifadəçinin autentifikasiyası və idarə olunan klasterlərə girişi;
• Kubernetes-də Kafka təkmilləşdirmə və dinamik konfiqurasiya;
• Kafka üçün elçi protokol filtri, meshed.

Kubernetes-də Kafka klasterini yerləşdirmək qərarına gəldikdə, çox güman ki, əsas infrastrukturun optimal ölçüsünü müəyyən etmək problemi və ötürmə qabiliyyəti tələblərinə cavab vermək üçün Kafka konfiqurasiyanızı dəqiq tənzimləmək ehtiyacı ilə qarşılaşacaqsınız. Hər bir brokerin maksimum performansı yaddaş, prosessor, disk sürəti, şəbəkə bant genişliyi və s. kimi əsas infrastruktur komponentlərinin performansı ilə müəyyən edilir.

İdeal olaraq, broker konfiqurasiyası elə olmalıdır ki, bütün infrastruktur elementləri maksimum imkanlarından istifadə edilsin. Ancaq real həyatda bu quraşdırma olduqca mürəkkəbdir. Çox güman ki, istifadəçilər bir və ya iki komponentdən (disk, yaddaş və ya prosessor) maksimum istifadə etmək üçün brokerləri konfiqurasiya edəcəklər. Ümumiyyətlə, bir broker, konfiqurasiyası ən yavaş komponentdən tam şəkildə istifadə etməyə imkan verəndə maksimum performans göstərir. Beləliklə, bir brokerin öhdəsindən gələ biləcəyi yük haqqında təxmini bir fikir əldə edə bilərik.

Teorik olaraq, müəyyən bir yükü idarə etmək üçün tələb olunan brokerlərin sayını da təxmin edə bilərik. Bununla belə, praktikada müxtəlif səviyyələrdə çoxlu konfiqurasiya variantları mövcuddur ki, müəyyən bir konfiqurasiyanın potensial performansını qiymətləndirmək çox çətindir (mümkün deyilsə). Başqa sözlə, müəyyən bir performansa əsaslanaraq konfiqurasiya planlaşdırmaq çox çətindir.

Supertubes istifadəçiləri üçün biz adətən aşağıdakı yanaşmadan istifadə edirik: bəzi konfiqurasiyadan (infrastruktur + parametrlər) başlayırıq, sonra onun performansını ölçürük, broker parametrlərini tənzimləyirik və prosesi yenidən təkrar edirik. Bu, infrastrukturun ən yavaş komponenti tam istifadə olunana qədər baş verir.

Beləliklə, bir klasterin müəyyən bir yükü idarə etmək üçün neçə brokerə ehtiyacı olduğu barədə daha aydın təsəvvür əldə edirik (brokerlərin sayı, həmçinin davamlılığı təmin etmək üçün mesaj replikalarının minimum sayı, bölmələrin sayı kimi digər amillərdən asılıdır. liderlər və s.). Bundan əlavə, biz hansı infrastruktur komponentlərinin şaquli miqyas tələb etməsi barədə məlumat əldə edirik.

Bu məqalə ilkin konfiqurasiyalarda ən yavaş komponentlərdən maksimum yararlanmaq və Kafka klasterinin ötürmə qabiliyyətini ölçmək üçün atdığımız addımlardan bəhs edəcək. Yüksək davamlı konfiqurasiya ən azı üç işləyən broker tələb edir (min.insync.replicas=3), üç müxtəlif əlçatanlıq zonası üzrə paylanmışdır. Kubernetes infrastrukturunu konfiqurasiya etmək, ölçmək və monitorinq etmək üçün hibrid buludlar üçün öz konteyner idarəetmə platformamızdan istifadə edirik - Kəmər. O, yerli (çılpaq metal, VMware) və beş növ bulud (Alibaba, AWS, Azure, Google, Oracle), eləcə də onların istənilən kombinasiyasını dəstəkləyir.

Kafka klaster infrastrukturu və konfiqurasiyası haqqında fikirlər

Aşağıdakı nümunələr üçün biz bulud provayderi kimi AWS-i və Kubernetes paylanması kimi EKS-i seçdik. Bənzər bir konfiqurasiya istifadə edərək həyata keçirilə bilər P.K.E. - CNCF tərəfindən təsdiqlənmiş Banzai Cloud-dan Kubernetes paylanması.

disk

Amazon müxtəlif təkliflər edir EBS həcm növləri... Ürəyində gp2 и io1 yüksək ötürmə qabiliyyətini təmin etmək üçün SSD sürücüləri var gp2 yığılmış kreditləri sərf edir (I/O kreditləri), ona görə də növünə üstünlük verdik io1, ardıcıl yüksək ötürmə qabiliyyəti təklif edir.

Nümunə növləri

Kafkanın performansı əməliyyat sisteminin səhifə keşindən çox asılıdır, ona görə də brokerlər (JVM) və səhifə keşi üçün kifayət qədər yaddaşa malik nümunələrə ehtiyacımız var. Nümunə c5.2x böyük - yaxşı başlanğıcdır, çünki 16 GB yaddaşa malikdir və EBS ilə işləmək üçün optimallaşdırılmışdır. Onun dezavantajı odur ki, hər 30 saatdan bir 24 dəqiqədən çox olmayan maksimum performansı təmin edə bilir. Əgər iş yükünüz daha uzun müddət ərzində pik performans tələb edirsə, digər nümunə növlərini nəzərdən keçirmək istəyə bilərsiniz. Məhz bunu etdik, dayandıq c5.4x böyük. Maksimum ötürmə qabiliyyətini təmin edir 593,75 Mb/s. EBS həcminin maksimum ötürmə qabiliyyəti io1 misaldan yüksəkdir c5.4x böyük, buna görə də infrastrukturun ən yavaş elementi çox güman ki, bu nümunə növünün I/O ötürmə qabiliyyətidir (bunu bizim yükləmə testlərimiz də təsdiq etməlidir).

Şəbəkə

Şəbəkə ötürmə qabiliyyəti VM instansiyasının və diskinin performansı ilə müqayisədə kifayət qədər böyük olmalıdır, əks halda şəbəkə darboğaza çevrilir. Bizim vəziyyətimizdə şəbəkə interfeysi c5.4x böyük VM instansiyasının giriş/çıxış qabiliyyətindən əhəmiyyətli dərəcədə yüksək olan 10 Gb/s-ə qədər sürəti dəstəkləyir.

Broker Yerləşdirmə

Brokerlər CPU, yaddaş, şəbəkə və disk resursları üçün digər proseslərlə rəqabət etməmək üçün xüsusi qovşaqlara yerləşdirilməlidir (Kubernetes-də planlaşdırılıb).

Java versiyası

Məntiqi seçim Java 11-dir, çünki o, Docker ilə uyğun gəlir, o mənada ki, JVM brokerin işlədiyi konteynerdə mövcud olan prosessorları və yaddaşı düzgün müəyyənləşdirir. Prosessor məhdudiyyətlərinin vacib olduğunu bilən JVM daxili və şəffaf şəkildə GC iplərinin və JIT iplərinin sayını təyin edir. Kafka obrazından istifadə etdik banzaicloud/kafka:2.13-2.4.0Java 2.4.0-də Kafka versiyası 2.13 (Scala 11) daxildir.

Kubernetes-də Java/JVM haqqında daha çox öyrənmək istəyirsinizsə, aşağıdakı yazılarımıza baxın:

• Niyə mənim Java tətbiqim OOMKilled-dir;
• Java 10 tətbiqləri üçün konteynerlərin ölçüsünü necə düzgün müəyyənləşdirmək olar.

Broker yaddaş parametrləri

Broker yaddaşını konfiqurasiya etməyin iki əsas aspekti var: JVM və Kubernetes podu üçün parametrlər. Pod üçün müəyyən edilmiş yaddaş limiti maksimum yığın ölçüsündən böyük olmalıdır ki, JVM öz yaddaşında yerləşən Java meta məkanı və Kafkanın aktiv şəkildə istifadə etdiyi əməliyyat sisteminin səhifə keşi üçün yer tutsun. Testlərimizdə parametrləri olan Kafka brokerlərini işə saldıq -Xmx4G -Xms2G, və pod üçün yaddaş limiti idi 10 Gi. Nəzərə alın ki, JVM üçün yaddaş parametrləri avtomatik olaraq istifadə oluna bilər -XX:MaxRAMPercentage и -X:MinRAMPercentage, pod üçün yaddaş limitinə əsaslanır.

Broker prosessorunun parametrləri

Ümumiyyətlə, Kafkanın istifadə etdiyi iplərin sayını artırmaqla paralelliyi artırmaqla performansı yaxşılaşdıra bilərsiniz. Kafka üçün nə qədər çox prosessor olsa, bir o qədər yaxşıdır. Testimizə 6 prosessor limiti ilə başladıq və tədricən (iterasiyalar vasitəsilə) onların sayını 15-ə çatdırdıq. Bundan əlavə, biz müəyyən etdik. num.network.threads=12 şəbəkədən məlumatları qəbul edən və göndərən mövzuların sayını artırmaq üçün broker parametrlərində. İzləyici brokerlərin replikaları kifayət qədər tez ala bilmədiklərini dərhal aşkar edərək, qaldırdılar num.replica.fetchers izləyici brokerlərin liderlərdən gələn mesajları təkrarlama sürətini artırmaq üçün 4-ə qədər.

Yükləmə aləti

Kafka klasteri (qiymətləndirmə aparılır) maksimum yükə çatana qədər seçilmiş yük generatorunun tutumunun tükənməməsinə əmin olmalısınız. Başqa sözlə, yük yaratma vasitəsinin imkanlarının ilkin qiymətləndirilməsini aparmaq, həmçinin onun üçün kifayət qədər sayda prosessor və yaddaşa malik nümunə növlərini seçmək lazımdır. Bu halda alətimiz Kafka klasterinin öhdəsindən gələ biləcəyindən daha çox yük çıxaracaq. Çoxlu təcrübələrdən sonra üç nüsxədə qərarlaşdıq c5.4x böyük, hər birində işləyən generator var idi.

Bençmarkinq

Performansın ölçülməsi aşağıdakı mərhələləri əhatə edən iterativ bir prosesdir:

• infrastrukturun qurulması (EKS klasteri, Kafka klasteri, yük yaratma aləti, həmçinin Prometheus və Grafana);
• toplanmış performans göstəricilərində təsadüfi kənarlaşmaları süzgəcdən keçirmək üçün müəyyən müddətə yük yaratmaq;
• müşahidə edilmiş fəaliyyət göstəriciləri əsasında brokerin infrastrukturunun və konfiqurasiyasının tənzimlənməsi;
• Kafka klasterinin tələb olunan səviyyəsinə çatana qədər prosesin təkrarlanması. Eyni zamanda, o, ardıcıl olaraq təkrar istehsal olunmalı və ötürmə qabiliyyətində minimal dəyişikliklər nümayiş etdirməlidir.

Növbəti bölmə test klasterinin müqayisəsi prosesi zamanı yerinə yetirilən addımları təsvir edir.

Tools

Əsas konfiqurasiyanı tez bir zamanda yerləşdirmək, yükləri yaratmaq və performansı ölçmək üçün aşağıdakı vasitələrdən istifadə edilmişdir:

• Banzai Bulud Boru Kəməri Amazon-dan EKS klasterinin təşkili üçün c Prometey (Kafka və infrastruktur ölçülərini toplamaq üçün) və Qrafana (bu göstəriciləri vizuallaşdırmaq üçün). Biz yararlandıq inteqrasiya olunmuş в Kəmər federativ monitorinq, mərkəzləşdirilmiş jurnalların toplanması, zəifliyin skan edilməsi, fəlakətin bərpası, korporativ səviyyəli təhlükəsizlik və s. təmin edən xidmətlər.
• Sanqrenel — Kafka klasterinin yükünü yoxlamaq üçün alət.
• Kafka ölçülərini və infrastrukturunu vizuallaşdırmaq üçün Grafana panelləri: Kubernetes Kafka, Node İxracatçı.
• Kubernetes-də Kafka klasterini qurmağın ən asan yolu üçün Supertubes CLI. Zookeeper, Kafka operatoru, Envoy və bir çox digər komponentlər Kubernetes-də istehsala hazır Kafka klasterini idarə etmək üçün quraşdırılıb və düzgün şəkildə konfiqurasiya edilib.
  • Quraşdırmaq üçün supertubes CLI verilmiş təlimatlardan istifadə edin burada.

EKS çoxluğu

Xüsusi işçi qovşaqları ilə EKS klasterini hazırlayın c5.4x böyük Kafka brokerləri ilə podlar üçün müxtəlif əlçatanlıq zonalarında, həmçinin yük generatoru və monitorinq infrastrukturu üçün ayrılmış qovşaqlarda.

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

EKS klasteri işə düşdükdən sonra onun inteqrasiyasını aktivləşdirin monitorinq xidməti - o, Prometey və Qrafananı bir klasterə yerləşdirəcək.

Kafka sisteminin komponentləri

Supertubes CLI istifadə edərək EKS-də Kafka sistem komponentlərini (Zookeeper, kafka-operator) quraşdırın:

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

Kafka çoxluğu

Varsayılan olaraq, EKS EBS tipli həcmlərdən istifadə edir gp2, buna görə də həcmlərə əsaslanan ayrıca saxlama sinifi yaratmalısınız io1 Kafka çoxluğu üçün:

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

Brokerlər üçün parametr təyin edin min.insync.replicas=3 və üç fərqli əlçatanlıq zonasındakı qovşaqlarda broker podlarını yerləşdirin:

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

Mövzular

Paralel olaraq üç yük generatorunu işə saldıq. Onların hər biri öz mövzusuna yazır, yəni cəmi üç mövzuya ehtiyacımız var:

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

Hər bir mövzu üçün təkrarlama əmsalı 3-dür - yüksək əlçatan istehsal sistemləri üçün tövsiyə olunan minimum dəyər.

Yükləmə aləti

Yük generatorunun üç nüsxəsini işə saldıq (hər biri ayrı bir mövzuda yazdı). Yük generatoru podları üçün qovşaq yaxınlığını təyin etməlisiniz ki, onlar yalnız onlar üçün ayrılmış qovşaqlarda planlaşdırılsın:

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

Qeyd etmək üçün bir neçə məqam:

• Yük generatoru 512 bayt uzunluğunda mesajlar yaradır və onları 500 mesaj toplusunda Kafkaya dərc edir.
• Arqumentdən istifadə -required-acks=all Mesajın bütün sinxronlaşdırılmış replikaları Kafka brokerləri tərəfindən qəbul edildikdə və təsdiq edildikdə nəşr uğurlu sayılır. Bu o deməkdir ki, bençmarkda biz təkcə liderlərin mesajları alma sürətini deyil, həm də onların izləyicilərinin mesajları təkrarlama sürətini ölçmüşük. Bu testin məqsədi istehlakçının oxu sürətini qiymətləndirmək deyil (istehlakçılar) bu yaxınlarda hələ də OS səhifəsinin keşində qalan mesajlar və onun diskdə saxlanılan mesajların oxunma sürəti ilə müqayisəsi.
• Yük generatoru paralel olaraq 20 işçi işləyir (-workers=20). Hər bir işçidə işçinin Kafka klasteri ilə əlaqəsini paylaşan 5 istehsalçı var. Nəticədə hər bir generatorun 100 istehsalçısı var və onların hamısı Kafka klasterinə mesaj göndərir.

Klasterin sağlamlığının monitorinqi

Kafka klasterinin yük sınağı zamanı biz onun sağlamlığına da nəzarət etdik ki, heç bir podun yenidən işə salınması, sinxronizasiya olunmayan replikaların olmaması və minimal dalğalanmalarla maksimum ötürmə qabiliyyəti olmasın:

• Yük generatoru dərc edilmiş mesajların sayı və xəta dərəcəsi haqqında standart statistika yazır. Səhv nisbəti eyni qalmalıdır 0,00%.
• Cruise Control, kafka-operator tərəfindən yerləşdirilən, klasterin vəziyyətini də izləyə biləcəyimiz bir idarə paneli təqdim edir. Bu panelə baxmaq üçün edin:

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

• ISR səviyyəsi ("sinxronlaşdırılmış" replikaların sayı) daralma və genişlənmə 0-a bərabərdir.

Ölçmə nəticələri

3 broker, mesaj ölçüsü - 512 bayt

Üç broker arasında bərabər paylanmış arakəsmələrlə biz performansa nail ola bildik ~500 Mb/s (saniyədə təxminən 990 min mesaj):

JVM virtual maşınının yaddaş istehlakı 2 GB-ı keçmədi:

Disk ötürmə qabiliyyəti brokerlərin işlədiyi hər üç instansiyada maksimum I/O node ötürücülüyünə çatdı:

Qovşaqlar üzrə yaddaş istifadəsi ilə bağlı məlumatlardan belə nəticə çıxır ki, sistemin buferləşdirilməsi və keşləşdirilməsi ~10-15 GB vaxt aparır:

3 broker, mesaj ölçüsü - 100 bayt

Mesaj ölçüsü azaldıqca ötürmə qabiliyyəti təxminən 15-20% azalır: hər bir mesajın işlənməsinə sərf olunan vaxt ona təsir edir. Bundan əlavə, prosessor yükü demək olar ki, iki dəfə artıb.

Broker qovşaqlarında hələ də istifadə olunmamış nüvələr olduğundan, performans Kafka konfiqurasiyasını dəyişdirməklə yaxşılaşdırıla bilər. Bu asan məsələ deyil, ona görə də ötürmə qabiliyyətini artırmaq üçün daha böyük mesajlarla işləmək daha yaxşıdır.

4 broker, mesaj ölçüsü - 512 bayt

Siz sadəcə olaraq yeni brokerlər əlavə etməklə və arakəsmələr balansını saxlamaqla Kafka klasterinin performansını asanlıqla artıra bilərsiniz (bu, yükün brokerlər arasında bərabər paylanmasını təmin edir). Bizim vəziyyətimizdə, bir broker əlavə etdikdən sonra, klaster ötürmə qabiliyyəti artdı ~580 Mb/s (saniyədə ~1,1 milyon mesaj). Artım gözləniləndən az oldu: bu, əsasən arakəsmələrin balanssızlığı ilə izah olunur (bütün brokerlər öz imkanlarının zirvəsində işləmir).

JVM maşınının yaddaş istehlakı 2 GB-dan aşağı qaldı:

Sürücülərlə brokerlərin işinə arakəsmələrin balanssızlığı təsir etdi:

Tapıntılar

Yuxarıda təqdim olunan iterativ yanaşma, yüzlərlə istehlakçının daxil olduğu daha mürəkkəb ssenariləri əhatə etmək üçün genişləndirilə bilər, yenidən bölmə, yayma yeniləmələri, podun yenidən işə salınması və s. Bütün bunlar bizə müxtəlif şəraitlərdə Kafka klasterinin imkanlarının hüdudlarını qiymətləndirməyə, onun fəaliyyətindəki darboğazları müəyyən etməyə və onlarla mübarizə yollarını tapmağa imkan verir.

Biz Supertubes-u klasteri tez və asanlıqla yerləşdirmək, konfiqurasiya etmək, brokerlər və mövzular əlavə etmək/çıxarmaq, xəbərdarlıqlara cavab vermək və ümumilikdə Kafkanın Kubernetes-də düzgün işləməsini təmin etmək üçün hazırladıq. Məqsədimiz diqqətinizi əsas tapşırığa (“Kafka mesajları yaratmaq” və “istehlak etmək”) kömək etmək və bütün çətin işi Supertubes və Kafka operatoruna həvalə etməkdir.

Banzai Cloud texnologiyaları və Açıq Mənbə layihələri ilə maraqlanırsınızsa, şirkətə abunə olun Github, LinkedIn və ya Twitter.

Tərcüməçidən PS

Bloqumuzda da oxuyun:

• «K8-lərdə Redis operatoru ilə bir hekayə və bu verilənlər bazasından məlumatların təhlili üçün kommunal proqramların mini icmalı";
• «Kubernetes miqrasiyasına qüsursuz RabbitMQ";
• «CoreOS-dan zetcd: ZooKeeper-in...etcd yaddaşı ilə əvəz edilməsi.

Mənbə: www.habr.com