Tukuyin ang naaangkop na laki para sa isang Kafka cluster sa Kubernetes

Tandaan. transl.: Sa artikulong ito, nagbahagi ang Banzai Cloud ng isang halimbawa kung paano magagamit ang mga custom na tool nito upang gawing mas madaling gamitin ang Kafka sa loob ng Kubernetes. Ang mga sumusunod na tagubilin ay naglalarawan kung paano mo matutukoy ang pinakamainam na laki ng iyong imprastraktura at i-configure ang Kafka mismo upang makamit ang kinakailangang throughput.

Ang Apache Kafka ay isang distributed streaming platform para sa paglikha ng maaasahan, scalable at high-performance na real-time streaming system. Ang mga kahanga-hangang kakayahan nito ay maaaring palawigin gamit ang Kubernetes. Para dito binuo namin Open Source Kafka operator at isang tool na tinatawag Mga supertube. Nagbibigay-daan sa iyo ang mga ito na patakbuhin ang Kafka sa Kubernetes at gamitin ang iba't ibang feature nito, tulad ng pag-fine-tune ng configuration ng broker, metric-based scaling na may rebalancing, rack awareness, "soft" (maganda) paglulunsad ng mga update, atbp.

Subukan ang Supertubes sa iyong cluster:

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

O makipag-ugnayan dokumentasyon. Maaari mo ring basahin ang tungkol sa ilan sa mga kakayahan ng Kafka, ang gawain na kung saan ay awtomatiko gamit ang Supertubes at Kafka operator. Naisulat na namin ang tungkol sa kanila sa blog:

• Oh hindi! Isa pang operator ng Kafka para sa Kubernetes;
• Subaybayan at patakbuhin ang Kafka batay sa mga sukatan ng Prometheus;
• Kafka rack awareness sa Kubernetes;
• Pagpapatakbo ng Apache Kafka sa ibabaw ng Istio - benchmark;
• Na-authenticate ng user at na-access ang mga kinokontrol na cluster gamit ang Kafka operator;
• Kafka rolling upgrade at dynamic na configuration sa Kubernetes;
• Envoy protocol filter para sa Kafka, meshed.

Kapag nagpasya kang mag-deploy ng Kafka cluster sa Kubernetes, malamang na mahaharap ka sa hamon ng pagtukoy sa pinakamainam na laki ng pinagbabatayan na imprastraktura at ang pangangailangang i-fine-tune ang iyong configuration ng Kafka upang matugunan ang mga kinakailangan sa throughput. Ang pinakamataas na pagganap ng bawat broker ay tinutukoy ng pagganap ng mga pinagbabatayan na bahagi ng imprastraktura, tulad ng memorya, processor, bilis ng disk, bandwidth ng network, atbp.

Sa isip, ang pagsasaayos ng broker ay dapat na ang lahat ng mga elemento ng imprastraktura ay ginagamit sa kanilang pinakamataas na kakayahan. Gayunpaman, sa totoong buhay ang setup na ito ay medyo kumplikado. Mas malamang na i-configure ng mga user ang mga broker upang i-maximize ang paggamit ng isa o dalawang bahagi (disk, memory, o processor). Sa pangkalahatan, ang isang broker ay nagpapakita ng pinakamataas na pagganap kapag ang pagsasaayos nito ay nagbibigay-daan sa pinakamabagal na bahagi na magamit sa buong lawak nito. Sa ganitong paraan makakakuha tayo ng magaspang na ideya ng pagkarga na kayang hawakan ng isang broker.

Sa teorya, maaari din nating tantyahin ang bilang ng mga broker na kinakailangan upang mahawakan ang isang naibigay na load. Gayunpaman, sa pagsasagawa mayroong napakaraming mga pagpipilian sa pagsasaayos sa iba't ibang antas na napakahirap (kung hindi imposible) na suriin ang potensyal na pagganap ng isang partikular na pagsasaayos. Sa madaling salita, napakahirap magplano ng pagsasaayos batay sa ilang partikular na pagganap.

Para sa mga gumagamit ng Supertubes, karaniwang ginagawa namin ang sumusunod na diskarte: nagsisimula kami sa ilang pagsasaayos (imprastraktura + mga setting), pagkatapos ay sukatin ang pagganap nito, ayusin ang mga setting ng broker at ulitin muli ang proseso. Nangyayari ito hanggang sa ganap na magamit ang pinakamabagal na bahagi ng imprastraktura.

Sa ganitong paraan, nakakakuha tayo ng mas malinaw na ideya kung gaano karaming mga broker ang kailangan ng isang cluster na humawak ng isang partikular na load (ang bilang ng mga broker ay nakasalalay din sa iba pang mga kadahilanan, tulad ng minimum na bilang ng mga replika ng mensahe upang matiyak ang katatagan, ang bilang ng mga partisyon. mga pinuno, atbp.). Bilang karagdagan, nakakakuha kami ng insight sa kung aling mga bahagi ng imprastraktura ang nangangailangan ng vertical scaling.

Tatalakayin ng artikulong ito ang tungkol sa mga hakbang na gagawin namin para masulit ang pinakamabagal na bahagi sa mga paunang configuration at sukatin ang throughput ng isang Kafka cluster. Ang isang lubos na nababanat na pagsasaayos ay nangangailangan ng hindi bababa sa tatlong tumatakbong broker (min.insync.replicas=3), na ipinamahagi sa tatlong magkakaibang mga accessibility zone. Upang i-configure, sukatin at subaybayan ang imprastraktura ng Kubernetes, ginagamit namin ang aming sariling platform sa pamamahala ng container para sa mga hybrid na ulap - Padaanin sa tubo. Sinusuportahan nito ang on-premise (bare metal, VMware) at limang uri ng cloud (Alibaba, AWS, Azure, Google, Oracle), pati na rin ang anumang kumbinasyon ng mga ito.

Mga saloobin sa imprastraktura at pagsasaayos ng cluster ng Kafka

Para sa mga halimbawa sa ibaba, pinili namin ang AWS bilang cloud provider at EKS bilang Kubernetes distribution. Ang isang katulad na pagsasaayos ay maaaring ipatupad gamit ang P.K.E. - Pamamahagi ng Kubernetes mula sa Banzai Cloud, na na-certify ng CNCF.

Disk

Nag-aalok ang Amazon ng iba't ibang Mga uri ng volume ng EBS. Sa kaibuturan gp2 и io1 may mga SSD drive, gayunpaman, upang matiyak ang mataas na throughput gp2 kumukonsumo ng mga naipon na kredito (I/O credits), kaya mas pinili namin ang uri io1, na nag-aalok ng pare-parehong mataas na throughput.

Mga uri ng instance

Ang pagganap ng Kafka ay lubos na nakadepende sa cache ng pahina ng operating system, kaya kailangan namin ng mga pagkakataon na may sapat na memorya para sa mga broker (JVM) at cache ng pahina. Halimbawa c5.2xmalaki - isang magandang simula, dahil mayroon itong 16 GB ng memorya at na-optimize upang gumana sa EBS. Ang kawalan nito ay ang kakayahan lamang nitong magbigay ng pinakamataas na pagganap nang hindi hihigit sa 30 minuto bawat 24 na oras. Kung ang iyong workload ay nangangailangan ng pinakamataas na pagganap sa loob ng mas mahabang panahon, maaari mong isaalang-alang ang iba pang mga uri ng instance. Iyon mismo ang ginawa namin, huminto sa c5.4xmalaki. Nagbibigay ito ng maximum na throughput sa 593,75 Mb/s. Pinakamataas na throughput ng dami ng EBS io1 mas mataas kaysa sa halimbawa c5.4xmalaki, kaya ang pinakamabagal na elemento ng imprastraktura ay malamang na ang I/O throughput ng ganitong uri ng instance (na dapat ding kumpirmahin ng aming mga pagsubok sa pag-load).

Сеть

Ang network throughput ay dapat sapat na malaki kumpara sa performance ng VM instance at disk, kung hindi, ang network ay magiging bottleneck. Sa aming kaso, ang interface ng network c5.4xmalaki sumusuporta sa mga bilis na hanggang 10 Gb/s, na mas mataas kaysa sa I/O throughput ng isang VM instance.

Pag-deploy ng Broker

Dapat na i-deploy ang mga broker (naka-iskedyul sa Kubernetes) sa mga nakalaang node upang maiwasan ang pakikipagkumpitensya sa iba pang mga proseso para sa CPU, memorya, network, at mga mapagkukunan ng disk.

bersyon ng Java

Ang lohikal na pagpipilian ay Java 11 dahil ito ay katugma sa Docker sa kahulugan na ang JVM ay wastong tinutukoy ang mga processor at memorya na magagamit sa lalagyan kung saan tumatakbo ang broker. Dahil alam na mahalaga ang mga limitasyon ng CPU, panloob at malinaw na itinatakda ng JVM ang bilang ng mga GC thread at JIT thread. Ginamit namin ang imahe ng Kafka banzaicloud/kafka:2.13-2.4.0, na kinabibilangan ng Kafka na bersyon 2.4.0 (Scala 2.13) sa Java 11.

Kung gusto mong matuto nang higit pa tungkol sa Java/JVM sa Kubernetes, tingnan ang aming mga sumusunod na post:

• Bakit ang aking Java application ay OOMKilled;
• Paano tama ang laki ng mga container para sa Java 10 application.

Mga setting ng memory ng broker

Mayroong dalawang pangunahing aspeto sa pag-configure ng memory ng broker: mga setting para sa JVM at para sa pod ng Kubernetes. Ang limitasyon ng memory na itinakda para sa isang pod ay dapat na mas malaki kaysa sa maximum na laki ng heap upang ang JVM ay may puwang para sa Java metaspace na nasa sarili nitong memorya at para sa cache ng pahina ng operating system na aktibong ginagamit ng Kafka. Sa aming mga pagsubok, inilunsad namin ang mga Kafka broker na may mga parameter -Xmx4G -Xms2G, at ang limitasyon ng memorya para sa pod ay 10 Gi. Pakitandaan na ang mga setting ng memory para sa JVM ay maaaring awtomatikong makuha gamit ang -XX:MaxRAMPercentage и -X:MinRAMPercentage, batay sa limitasyon ng memorya para sa pod.

Mga setting ng processor ng broker

Sa pangkalahatan, maaari mong pagbutihin ang pagganap sa pamamagitan ng pagpapataas ng paralelismo sa pamamagitan ng pagtaas ng bilang ng mga thread na ginagamit ng Kafka. Ang mas maraming mga processor na magagamit para sa Kafka, mas mahusay. Sa aming pagsubok, nagsimula kami sa limitasyon na 6 na processor at unti-unti (sa pamamagitan ng mga pag-ulit) ay itinaas ang kanilang numero sa 15. Bilang karagdagan, itinakda namin num.network.threads=12 sa mga setting ng broker upang madagdagan ang bilang ng mga thread na tumatanggap ng data mula sa network at ipadala ito. Kaagad na natuklasan na ang mga tagasunod na broker ay hindi makakatanggap ng mga replika nang sapat na mabilis, itinaas nila num.replica.fetchers hanggang 4 upang mapataas ang bilis kung saan ang mga tagasunod na broker ay ginagaya ang mga mensahe mula sa mga pinuno.

Tool sa Pagbuo ng Load

Dapat mong tiyakin na ang napiling load generator ay hindi mauubusan ng kapasidad bago maabot ng Kafka cluster (na sinusuri) ang pinakamataas na load nito. Sa madaling salita, kinakailangan na magsagawa ng isang paunang pagtatasa ng mga kakayahan ng tool sa pagbuo ng pag-load, at pumili din ng mga uri ng halimbawa para dito na may sapat na bilang ng mga processor at memorya. Sa kasong ito, ang aming tool ay gagawa ng mas maraming load kaysa sa Kafka cluster na kayang hawakan. Pagkatapos ng maraming mga eksperimento, kami ay nanirahan sa tatlong kopya c5.4xmalaki, na ang bawat isa ay may generator na tumatakbo.

Pag-benchmark

Ang pagsukat ng pagganap ay isang umuulit na proseso na kinabibilangan ng mga sumusunod na yugto:

• pag-set up ng imprastraktura (EKS cluster, Kafka cluster, load generation tool, pati na rin ang Prometheus at Grafana);
• pagbuo ng load para sa isang tiyak na panahon upang i-filter ang mga random na paglihis sa mga nakolektang tagapagpahiwatig ng pagganap;
• pagsasaayos ng imprastraktura at pagsasaayos ng broker batay sa naobserbahang mga tagapagpahiwatig ng pagganap;
• inuulit ang proseso hanggang sa maabot ang kinakailangang antas ng throughput ng cluster ng Kafka. Kasabay nito, dapat itong tuluy-tuloy na nagagawa at nagpapakita ng kaunting mga pagkakaiba-iba sa throughput.

Inilalarawan ng susunod na seksyon ang mga hakbang na isinagawa sa panahon ng proseso ng pag-benchmark ng cluster ng pagsubok.

Tools

Ginamit ang mga sumusunod na tool para mabilis na mag-deploy ng baseline configuration, makabuo ng load, at sukatin ang performance:

• Banzai Cloud Pipeline para sa pag-aayos ng isang EKS cluster mula sa Amazon c Promiteyus (upang mangolekta ng Kafka at mga sukatan ng imprastraktura) at grafana (upang makita ang mga sukatan na ito). Sinamantala namin pinagsama-sama в Padaanin sa tubo mga serbisyong nagbibigay ng federated monitoring, centralized log collection, vulnerability scanning, disaster recovery, enterprise-grade security at marami pang iba.
• Sangrenel — isang tool para sa pag-load ng pagsubok sa isang Kafka cluster.
• Mga dashboard ng Grafana para sa pagpapakita ng mga sukatan at imprastraktura ng Kafka: Kubernetes Kafka, Node Exporter.
• Supertubes CLI para sa pinakamadaling paraan upang mag-set up ng Kafka cluster sa Kubernetes. Ang Zookeeper, Kafka operator, Envoy at marami pang ibang bahagi ay naka-install at maayos na na-configure upang magpatakbo ng isang handa sa produksyon na Kafka cluster sa Kubernetes.
  • Upang mai-install supertubes CLI gamitin ang mga tagubiling ibinigay dito.

EKS cluster

Maghanda ng EKS cluster na may mga nakalaang worker node c5.4xmalaki sa iba't ibang mga availability zone para sa mga pod na may mga Kafka broker, pati na rin ang mga nakalaang node para sa load generator at monitoring infrastructure.

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

Kapag gumagana na ang EKS cluster, paganahin ang integrated nito serbisyo sa pagsubaybay — ide-deploy niya ang Prometheus at Grafana sa isang cluster.

Mga bahagi ng sistema ng Kafka

I-install ang mga bahagi ng sistema ng Kafka (Zookeeper, kafka-operator) sa EKS gamit ang supertubes CLI:

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

Kumpol ng Kafka

Bilang default, gumagamit ang EKS ng mga volume ng uri ng EBS gp2, kaya kailangan mong lumikha ng hiwalay na klase ng storage batay sa mga volume io1 para sa Kafka cluster:

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

Itakda ang parameter para sa mga broker min.insync.replicas=3 at mag-deploy ng mga broker pod sa mga node sa tatlong magkakaibang availability zone:

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

Mga Paksa

Nagpatakbo kami ng tatlong instance ng load generator nang magkatulad. Ang bawat isa sa kanila ay nagsusulat sa kanilang sariling paksa, iyon ay, kailangan natin ng tatlong paksa sa kabuuan:

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

Para sa bawat paksa, ang salik ng pagtitiklop ay 3—ang pinakamababang inirerekomendang halaga para sa mga sistema ng produksiyon na lubos na magagamit.

Tool sa Pagbuo ng Load

Naglunsad kami ng tatlong kopya ng load generator (bawat isa ay sumulat sa isang hiwalay na paksa). Para sa mga load generator pod, kailangan mong magtakda ng node affinity upang ang mga ito ay naka-iskedyul lamang sa mga node na nakalaan para sa kanila:

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

Ilang puntos na dapat tandaan:

• Ang load generator ay bumubuo ng mga mensahe na 512 bytes ang haba at ini-publish ang mga ito sa Kafka sa mga batch ng 500 na mensahe.
• Paggamit ng argumento -required-acks=all Ang publikasyon ay itinuturing na matagumpay kapag ang lahat ng naka-synchronize na mga replika ng mensahe ay natanggap at nakumpirma ng mga Kafka broker. Nangangahulugan ito na sa benchmark ay sinukat namin hindi lamang ang bilis ng pagtanggap ng mga mensahe ng mga pinuno, kundi pati na rin ang kanilang mga tagasunod na nagkokopya ng mga mensahe. Ang layunin ng pagsusulit na ito ay hindi upang suriin ang bilis ng pagbasa ng mamimili (mga mamimili) kamakailang natanggap na mga mensahe na nananatili pa rin sa cache ng pahina ng OS, at ang paghahambing nito sa bilis ng pagbasa ng mga mensaheng nakaimbak sa disk.
• Ang load generator ay nagpapatakbo ng 20 manggagawa nang magkatulad (-workers=20). Naglalaman ang bawat manggagawa ng 5 producer na nakikibahagi sa koneksyon ng manggagawa sa cluster ng Kafka. Bilang resulta, ang bawat generator ay may 100 producer, at lahat sila ay nagpapadala ng mga mensahe sa Kafka cluster.

Pagsubaybay sa kalusugan ng kumpol

Sa panahon ng pagsubok sa pag-load ng Kafka cluster, sinusubaybayan din namin ang kalusugan nito upang matiyak na walang mga pag-restart ng pod, walang mga out-of-sync na replika, at maximum na throughput na may kaunting pagbabagu-bago:

• Ang load generator ay nagsusulat ng mga karaniwang istatistika tungkol sa bilang ng mga mensaheng nai-publish at ang rate ng error. Dapat manatiling pareho ang rate ng error 0,00%.
• Cruise Control, na na-deploy ng kafka-operator, ay nagbibigay ng dashboard kung saan masusubaybayan din namin ang estado ng cluster. Upang tingnan ang panel na ito gawin:

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

• Antas ng ISR (bilang ng "in-sync" na mga replika) ang pag-urong at pagpapalawak ay katumbas ng 0.

Mga resulta ng pagsukat

3 broker, laki ng mensahe - 512 bytes

Sa pantay na pagkakabahagi ng mga partisyon sa tatlong broker, nagawa naming makamit ang pagganap ~500 Mb/s (humigit-kumulang 990 libong mga mensahe bawat segundo):

Ang pagkonsumo ng memorya ng JVM virtual machine ay hindi lalampas sa 2 GB:

Naabot ng disk throughput ang maximum I/O node throughput sa lahat ng tatlong pagkakataon kung saan tumatakbo ang mga broker:

Mula sa data sa paggamit ng memorya ng mga node, sumusunod na ang buffering at caching ng system ay tumagal ng ~10-15 GB:

3 broker, laki ng mensahe - 100 bytes

Habang bumababa ang laki ng mensahe, bumababa ang throughput ng humigit-kumulang 15-20%: ang oras na ginugol sa pagproseso ng bawat mensahe ay nakakaapekto dito. Bilang karagdagan, ang pag-load ng processor ay halos nadoble.

Dahil ang mga node ng broker ay mayroon pa ring hindi nagamit na mga core, maaaring mapabuti ang pagganap sa pamamagitan ng pagbabago sa configuration ng Kafka. Ito ay hindi isang madaling gawain, kaya upang madagdagan ang throughput mas mahusay na magtrabaho kasama ang mas malalaking mensahe.

4 broker, laki ng mensahe - 512 bytes

Madali mong mapapalaki ang pagganap ng isang cluster ng Kafka sa pamamagitan lamang ng pagdaragdag ng mga bagong broker at pagpapanatili ng balanse ng mga partisyon (sinisigurado nito na ang load ay pantay na ipinamamahagi sa pagitan ng mga broker). Sa aming kaso, pagkatapos magdagdag ng broker, tumaas ang cluster throughput sa ~580 Mb/s (~1,1 milyong mensahe bawat segundo). Ang paglago ay naging mas mababa kaysa sa inaasahan: ito ay pangunahing ipinaliwanag sa pamamagitan ng kawalan ng timbang ng mga partisyon (hindi lahat ng mga broker ay gumagana sa tuktok ng kanilang mga kakayahan).

Ang pagkonsumo ng memorya ng JVM machine ay nanatili sa ibaba 2 GB:

Ang gawain ng mga broker na may mga drive ay naapektuhan ng kawalan ng balanse ng mga partisyon:

Natuklasan

Ang umuulit na diskarte na ipinakita sa itaas ay maaaring palawakin upang masakop ang mas kumplikadong mga senaryo na kinasasangkutan ng daan-daang mga consumer, muling paghahati, rolling update, pod restart, atbp. Ang lahat ng ito ay nagbibigay-daan sa amin upang masuri ang mga limitasyon ng mga kakayahan ng Kafka cluster sa iba't ibang mga kondisyon, tukuyin ang mga bottleneck sa operasyon nito at maghanap ng mga paraan upang labanan ang mga ito.

Idinisenyo namin ang Supertubes upang mabilis at madaling mag-deploy ng cluster, i-configure ito, magdagdag/mag-alis ng mga broker at paksa, tumugon sa mga alerto, at matiyak na gumagana nang maayos ang Kafka sa pangkalahatan sa Kubernetes. Ang aming layunin ay tulungan kang mag-concentrate sa pangunahing gawain (“bumuo” at “gamitin” ang mga mensahe ng Kafka), at ipaubaya ang lahat ng pagsusumikap sa Supertubes at sa Kafka operator.

Kung interesado ka sa mga teknolohiya ng Banzai Cloud at mga proyekto ng Open Source, mag-subscribe sa kumpanya sa GitHub, LinkedIn o kaba.

PS mula sa tagasalin

Basahin din sa aming blog:

• «Isang kuwento sa operator ng Redis sa K8s at isang mini-review ng mga utility para sa pagsusuri ng data mula sa database na ito";
• «Walang putol na paglipat ng RabbitMQ sa Kubernetes";
• «zetcd mula sa CoreOS: Pinapalitan ang ZooKeeper ng...etcd storage'.

Pinagmulan: www.habr.com