Tinoa ang angay nga gidak-on alang sa usa ka Kafka cluster sa Kubernetes

Nota. transl.: Niining artikuloha, ang Banzai Cloud mipaambit ug pananglitan kon sa unsang paagi magamit ang naandang mga himan niini aron mas sayon ​​gamiton ang Kafka sulod sa Kubernetes. Ang mosunud nga mga panudlo nag-ilustrar kung giunsa nimo mahibal-an ang kamalaumon nga gidak-on sa imong imprastraktura ug i-configure ang Kafka mismo aron makab-ot ang gikinahanglan nga throughput.

Ang Apache Kafka usa ka gipang-apod-apod nga platform sa streaming alang sa pagmugna og kasaligan, scalable ug high-performance nga real-time nga mga sistema sa streaming. Ang mga impresibo nga kapabilidad niini mahimong mapalapdan gamit ang Kubernetes. Alang niini among naugmad Open Source Kafka operator ug usa ka himan nga gitawag Mga supertube. Gitugotan ka nila sa pagpadagan sa Kafka sa Kubernetes ug paggamit sa lainlaing mga bahin niini, sama sa pag-ayo sa pag-configure sa broker, metric-based scaling nga adunay rebalancing, rack awareness, "humok" (graceful) paglansad sa mga update, etc.

Sulayi ang Supertubes sa imong cluster:

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

O kontaka dokumentasyon. Mahimo usab nimo mabasa ang bahin sa pipila ka mga kapabilidad sa Kafka, ang trabaho nga awtomatiko gamit ang Supertubes ug Kafka operator. Gisulat na namo ang mahitungod kanila sa blog:

• Oh dili! Usa pa ka operator sa Kafka para sa Kubernetes;
• Pag-monitor ug pag-operate sa Kafka base sa Prometheus metrics;
• Kafka rack awareness sa Kubernetes;
• Pagpadagan sa Apache Kafka ibabaw sa Istio - benchmark;
• Gipamatud-an sa tiggamit ug gi-access ang mga kontroladong cluster sa Kafka operator;
• Kafka rolling upgrade ug dinamikong configuration sa Kubernetes;
• Envoy protocol filter para sa Kafka, gi-meshed.

Kung magdesisyon ka nga magbutang usa ka cluster sa Kafka sa Kubernetes, lagmit mag-atubang ka sa hagit sa pagtino sa kamalaumon nga gidak-on sa nagpahiping imprastraktura ug ang panginahanglan sa pag-ayo sa imong pag-configure sa Kafka aron matubag ang mga kinahanglanon sa throughput. Ang labing kataas nga pasundayag sa matag broker gitino pinaagi sa paghimo sa nagpahiping mga sangkap sa imprastraktura, sama sa memorya, processor, katulin sa disk, bandwidth sa network, ug uban pa.

Sa tinuud, ang pagsasaayos sa broker kinahanglan nga ingon nga ang tanan nga mga elemento sa imprastraktura gigamit sa ilang labing kataas nga kapabilidad. Bisan pa, sa tinuud nga kinabuhi kini nga pag-setup medyo komplikado. Mas lagmit nga ang mga tiggamit mag-configure sa mga broker aron mapadako ang paggamit sa usa o duha nga mga sangkap (disk, memorya, o processor). Sa kinatibuk-an nga pagsulti, ang usa ka broker nagpakita sa labing kataas nga pasundayag kung ang pag-configure niini nagtugot sa labing hinay nga sangkap nga magamit sa tibuuk nga gidak-on niini. Niining paagiha makakuha kami usa ka dili maayo nga ideya sa pagkarga nga mahimo sa usa ka broker.

Sa teoriya, mahimo usab natong banabanaon ang gidaghanon sa mga broker nga gikinahanglan sa pagdumala sa gihatag nga load. Bisan pa, sa praktis adunay daghang mga kapilian sa pag-configure sa lainlaing lebel nga lisud kaayo (kon dili imposible) ang pagtimbang-timbang sa potensyal nga paghimo sa usa ka partikular nga pagsumpo. Sa laing pagkasulti, lisud kaayo ang pagplano og configuration base sa pipila ka performance.

Alang sa mga tiggamit sa Supertubes, kasagaran namong gihimo ang mosunod nga pamaagi: magsugod kami sa pipila ka mga configuration (infrastructure + settings), dayon sukda ang performance niini, i-adjust ang mga setting sa broker ug balika ang proseso pag-usab. Kini mahitabo hangtud nga ang pinakahinay nga bahin sa imprastraktura hingpit nga magamit.

Niining paagiha, nakakuha kami usa ka mas tin-aw nga ideya kung pila ang mga broker nga kinahanglan sa usa ka cluster nga magdumala sa usa ka piho nga karga (ang gidaghanon sa mga broker nagdepende usab sa ubang mga hinungdan, sama sa minimum nga gidaghanon sa mga replika sa mensahe aron masiguro ang kalig-on, ang gidaghanon sa partisyon. mga lider, ug uban pa). Dugang pa, nakuha namon ang panabut kung unsang mga sangkap sa imprastraktura ang nanginahanglan bertikal nga pag-scale.

Kini nga artikulo maghisgot bahin sa mga lakang nga among gihimo aron makuha ang labing kadaghan sa labing hinay nga mga sangkap sa inisyal nga mga pag-configure ug pagsukod sa throughput sa usa ka cluster sa Kafka. Ang usa ka labi ka lig-on nga pagsumpo nanginahanglan labing menos tulo nga nagdagan nga mga broker (min.insync.replicas=3), giapod-apod sa tulo ka lainlain nga accessibility zones. Aron i-configure, sukdon ug bantayan ang imprastraktura sa Kubernetes, gigamit namo ang among kaugalingong plataporma sa pagdumala sa sudlanan alang sa hybrid clouds - Pipeline. Gisuportahan niini ang on-premise (bare metal, VMware) ug lima ka matang sa mga panganod (Alibaba, AWS, Azure, Google, Oracle), ingon man ang bisan unsang kombinasyon niini.

Mga hunahuna sa imprastraktura ug pag-configure sa cluster sa Kafka

Para sa mga pananglitan sa ubos, among gipili ang AWS isip cloud provider ug EKS isip Kubernetes distribution. Ang usa ka susama nga pag-configure mahimong ipatuman gamit ang P.K.E. - Pag-apod-apod sa Kubernetes gikan sa Banzai Cloud, gipamatud-an sa CNCF.

disk

Nagtanyag ang Amazon og lainlain Mga tipo sa volume sa EBS. Sa kinauyokan gp2 и io1 adunay mga SSD drive, bisan pa, aron masiguro ang taas nga throughput gp2 nagkonsumo sa natipon nga mga kredito (I/O credits), mao nga gipalabi namo ang tipo io1, nga nagtanyag makanunayon nga taas nga throughput.

Mga tipo sa pananglitan

Ang pasundayag sa Kafka nagsalig kaayo sa cache sa panid sa operating system, busa kinahanglan namon ang mga higayon nga adunay igo nga memorya alang sa mga broker (JVM) ug cache sa panid. Pananglitan c5.2x dako - usa ka maayong pagsugod, tungod kay kini adunay 16 GB nga memorya ug optimized sa pagtrabaho uban sa EBS. Ang disbentaha niini mao nga kini makahimo lamang sa paghatag og pinakataas nga performance sulod sa dili molapas sa 30 minutos matag 24 ka oras. Kung ang imong workload nanginahanglan peak performance sa mas taas nga yugto sa panahon, mahimo nimong hunahunaon ang ubang mga tipo sa instance. Mao gyud na among gibuhat, nihunong c5.4x dako. Naghatag kini og maximum nga throughput sa 593,75 Mb/s. Maximum nga throughput sa usa ka EBS volume io1 mas taas kay sa instance c5.4x dako, mao nga ang pinakahinay nga elemento sa imprastraktura lagmit mao ang I/O throughput niining instance type (nga kinahanglan usab nga kumpirmahon sa among load tests).

Network

Ang network throughput kinahanglan nga igo nga dako kon itandi sa performance sa VM instance ug disk, kung dili ang network mahimong bottleneck. Sa among kaso, ang interface sa network c5.4x dako nagsuporta sa katulin nga hangtod sa 10 Gb/s, nga mas taas kay sa I/O throughput sa usa ka VM nga pananglitan.

Pag-deploy sa Broker

Ang mga broker kinahanglan nga i-deploy (gi-iskedyul sa Kubernetes) sa gipahinungod nga mga node aron malikayan ang pagkompetensya sa ubang mga proseso alang sa CPU, memorya, network, ug mga kapanguhaan sa disk.

Java nga bersyon

Ang lohikal nga pagpili mao ang Java 11 tungod kay kini nahiuyon sa Docker sa diwa nga ang JVM husto nga nagtino sa mga processor ug memorya nga anaa sa sudlanan diin ang broker nagdagan. Kay nahibal-an nga ang mga limitasyon sa processor importante, ang JVM sa sulod ug sa transparent nagtakda sa gidaghanon sa GC thread ug JIT threads. Gigamit namon ang imahe sa Kafka banzaicloud/kafka:2.13-2.4.0, nga naglakip sa Kafka nga bersyon 2.4.0 (Scala 2.13) sa Java 11.

Kung gusto nimong makat-on og dugang bahin sa Java/JVM sa Kubernetes, susiha ang among mosunod nga mga post:

• Ngano nga ang akong aplikasyon sa Java OOMKilled;
• Giunsa ang husto nga gidak-on sa mga sudlanan alang sa Java 10 nga aplikasyon.

Mga setting sa memorya sa broker

Adunay duha ka mahinungdanong aspeto sa pag-configure sa memorya sa broker: mga setting alang sa JVM ug alang sa pod sa Kubernetes. Ang limitasyon sa panumduman nga gitakda alang sa usa ka pod kinahanglang mas dako pa kay sa kinatas-ang gidak-on sa pundok aron ang JVM adunay lawak alang sa Java metaspace nga anaa sa kaugalingong memorya ug alang sa cache sa pahina sa operating system nga aktibong gigamit ni Kafka. Sa among mga pagsulay gilusad namon ang mga broker sa Kafka nga adunay mga parameter -Xmx4G -Xms2G, ug ang limitasyon sa memorya alang sa pod kay 10 Gi. Palihug timan-i nga ang mga setting sa memorya alang sa JVM mahimong makuha nga awtomatiko gamit -XX:MaxRAMPercentage и -X:MinRAMPercentage, base sa limitasyon sa memorya sa pod.

Mga setting sa processor sa broker

Sa kinatibuk-an, mahimo nimong pauswagon ang pasundayag pinaagi sa pagdugang sa paralelismo pinaagi sa pagdugang sa gidaghanon sa mga hilo nga gigamit sa Kafka. Ang daghang mga processor nga magamit alang sa Kafka, mas maayo. Sa among pagsulay, nagsugod kami sa usa ka limitasyon sa 6 nga mga processor ug sa hinay-hinay (pinaagi sa mga pag-uli) gipataas ang ilang gidaghanon ngadto sa 15. Dugang pa, among gitakda num.network.threads=12 sa mga setting sa broker aron madugangan ang gidaghanon sa mga hilo nga makadawat mga datos gikan sa network ug ipadala kini. Diha-diha dayon nga nahibal-an nga ang mga follower broker dili makadawat og mga replika dayon, ilang gipataas num.replica.fetchers ngadto sa 4 aron madugangan ang katulin diin ang mga follower brokers nag-replicate sa mga mensahe gikan sa mga lider.

Load Generation Tool

Kinahanglan nimong sigurohon nga ang gipili nga load generator dili mahurot sa kapasidad sa dili pa ang Kafka cluster (nga gi-benchmark) makaabot sa pinakataas nga load niini. Sa laing pagkasulti, gikinahanglan ang pagpahigayon sa usa ka preliminary assessment sa mga kapabilidad sa load generation tool, ug usab pagpili sa mga tipo sa pananglitan niini nga adunay igo nga gidaghanon sa mga processor ug memorya. Sa kini nga kaso, ang among himan makahimo og daghang karga kaysa sa Kafka cluster nga makaya. Human sa daghang mga eksperimento, kami naghusay sa tulo ka kopya c5.4x dako, nga ang matag usa adunay generator nga nagdagan.

Pag-benchmark

Ang pagsukod sa pasundayag usa ka proseso nga nagbalikbalik nga naglakip sa mga mosunud nga yugto:

• pagpahimutang sa imprastraktura (EKS cluster, Kafka cluster, load generation tool, ingon man Prometheus ug Grafana);
• paghimo og load alang sa usa ka piho nga panahon sa pagsala sa random deviations sa nakolekta nga performance indicators;
• pag-adjust sa imprastraktura ug configuration sa broker base sa naobserbahan nga performance indicators;
• gisubli ang proseso hangtod ang gikinahanglan nga lebel sa Kafka cluster throughput makab-ot. Sa samang higayon, kini kinahanglan nga makanunayon nga mabag-o ug magpakita sa gamay nga mga kalainan sa throughput.

Ang sunod nga seksyon naghulagway sa mga lakang nga gihimo sa panahon sa pagsulay cluster benchmarking proseso.

Mga himan

Ang mosunod nga mga himan gigamit aron dali nga mag-deploy og baseline configuration, makamugna og load, ug masukod ang performance:

• Banzai Cloud Pipeline alang sa pag-organisar sa usa ka EKS cluster gikan sa Amazon c Prometheus (aron makolekta ang Kafka ug mga sukatan sa imprastraktura) ug grafana (aron mahanduraw kini nga mga sukatan). Gipahimuslan namo gihiusa в Pipeline mga serbisyo nga naghatag ug federated monitoring, centralized log collection, vulnerability scanning, disaster recovery, enterprise-grade security ug daghan pa.
• Sangrenel - usa ka himan alang sa pagsulay sa pagkarga sa usa ka cluster sa Kafka.
• Mga dashboard sa Grafana alang sa paghanduraw sa mga sukatan ug imprastraktura sa Kafka: Kubernetes Kafka, Node Exporter.
• Supertubes CLI para sa pinakasayon ​​nga paagi sa pag-set up ug Kafka cluster sa Kubernetes. Ang Zookeeper, Kafka operator, Envoy ug daghang uban pang mga sangkap gi-install ug husto nga gi-configure aron magpadagan sa usa ka andam nga produksiyon nga Kafka cluster sa Kubernetes.
  • Alang sa pag-instalar supertubes nga CLI gamita ang mga instruksiyon nga gihatag dinhi.

EKS cluster

Pag-andam ug EKS cluster nga adunay dedikadong worker node c5.4x dako sa lain-laing mga availability zones alang sa pods uban sa Kafka brokers, ingon man usab sa gipahinungod nga mga node alang sa load generator ug monitoring imprastraktura.

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

Kung nahuman na ug nagdagan ang EKS cluster, i-enable ang integrated niini serbisyo sa pagmonitor - iyang ibutang ang Prometheus ug Grafana ngadto sa usa ka cluster.

Mga sangkap sa sistema sa Kafka

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

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

Kafka cluster

Sa kasagaran, ang EKS naggamit sa EBS volumes of type gp2, mao nga kinahanglan ka maghimo usa ka lahi nga klase sa pagtipig base sa mga volume io1 alang 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

Ibutang ang parameter alang sa mga broker min.insync.replicas=3 ug i-deploy ang mga broker pod sa mga node sa tulo ka lain-laing mga availability zones:

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 hilisgutan

Nagdagan kami tulo nga mga higayon sa generator sa pagkarga nga managsama. Ang matag usa kanila nagsulat sa ilang kaugalingon nga hilisgutan, nga mao, kinahanglan namon ang tulo nga mga hilisgutan sa kinatibuk-an:

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 matag topiko, ang replication factor kay 3—ang minimum nga girekomendar nga bili para sa available kaayo nga mga sistema sa produksiyon.

Load Generation Tool

Naglunsad kami og tulo ka kopya sa load generator (ang matag usa nagsulat sa usa ka linain nga hilisgutan). Alang sa mga load generator pod, kinahanglan nimo nga itakda ang node affinity aron kini ma-iskedyul lamang sa mga node nga gigahin alang 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

Pipila ka mga punto nga hinumdoman:

• Ang load generator nagmugna og mga mensahe nga 512 bytes ang gitas-on ug gipatik kini sa Kafka sa mga batch nga 500 ka mga mensahe.
• Paggamit ug argumento -required-acks=all Ang publikasyon gikonsiderar nga malampuson kung ang tanan nga na-synchronize nga mga kopya sa mensahe nadawat ug gikumpirma sa mga broker sa Kafka. Kini nagpasabot nga sa benchmark atong gisukod dili lamang ang katulin sa mga lider sa pagdawat sa mga mensahe, apan usab ang ilang mga sumusunod nga nagsundog sa mga mensahe. Ang katuyoan sa kini nga pagsulay dili aron masusi ang katulin sa pagbasa sa mga konsumedor (mga konsumidor) bag-o lang nakadawat og mga mensahe nga nagpabilin gihapon sa OS page cache, ug ang pagtandi niini sa gikusgon sa pagbasa sa mga mensahe nga gitipigan sa disk.
• Ang load generator nagpadagan sa 20 ka mga trabahante nga managsama (-workers=20). Ang matag trabahante adunay 5 nga mga prodyuser nga nag-ambit sa koneksyon sa trabahante sa cluster sa Kafka. Ingon usa ka sangputanan, ang matag generator adunay 100 nga mga prodyuser, ug silang tanan nagpadala mga mensahe sa cluster sa Kafka.

Pag-monitor sa kahimsog sa cluster

Atol sa load testing sa Kafka cluster, gimonitor usab namo ang panglawas niini aron maseguro nga walay pod restarts, walay out-of-sync replicas, ug maximum throughput nga adunay gamay nga pag-usab-usab:

• Ang load generator nagsulat sa standard statistics mahitungod sa gidaghanon sa mga mensahe nga gipatik ug sa error rate. Ang rate sa sayup kinahanglan magpabilin nga parehas 0,00%.
• Pagkontrol sa Cruise, nga gipakatap sa kafka-operator, naghatag ug dashboard diin mamonitor usab nato ang kahimtang sa cluster. Aron makita kini nga panel buhata:

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

• ISR nga lebel (gidaghanon sa "in-sync" nga mga replika) Ang pagkunhod ug pagpalapad katumbas sa 0.

Mga resulta sa pagsukod

3 nga mga broker, gidak-on sa mensahe - 512 bytes

Uban sa mga partisyon nga parehas nga giapod-apod sa tulo ka mga broker, nakab-ot namon ang pasundayag ~500 Mb/s (gibana-bana nga 990 ka libo nga mga mensahe kada segundo):

Ang konsumo sa memorya sa JVM virtual machine dili molapas sa 2 GB:

Ang disk throughput nakaabot sa pinakataas nga I/O node throughput sa tanang tulo ka higayon diin ang mga brokers nagdagan:

Gikan sa datos sa paggamit sa panumduman pinaagi sa mga node, kini nagsunod nga ang buffering sa sistema ug caching gikuha ~ 10-15 GB:

3 nga mga broker, gidak-on sa mensahe - 100 bytes

Samtang ang gidak-on sa mensahe mikunhod, ang throughput mikunhod sa gibana-bana nga 15-20%: ang oras nga gigugol sa pagproseso sa matag mensahe makaapekto niini. Dugang pa, ang pagkarga sa processor halos doble.

Tungod kay ang mga node sa broker aduna pa'y wala magamit nga mga core, ang pasundayag mahimong mapauswag pinaagi sa pagbag-o sa configuration sa Kafka. Dili kini sayon ​​nga buluhaton, mao nga aron madugangan ang throughput mas maayo nga magtrabaho uban ang dagkong mga mensahe.

4 nga mga broker, gidak-on sa mensahe - 512 bytes

Dali nimong madugangan ang pasundayag sa usa ka cluster sa Kafka pinaagi lamang sa pagdugang sa mga bag-ong broker ug pagpadayon sa balanse sa mga partisyon (kini nagsiguro nga ang load parehas nga giapod-apod tali sa mga broker). Sa among kaso, human sa pagdugang sa usa ka broker, ang cluster throughput misaka ngadto sa ~580 Mb/s (~1,1 milyon nga mensahe kada segundo). Ang pag-uswag nahimo nga dili kaayo gipaabut: kini labi nga gipatin-aw sa dili balanse sa mga partisyon (dili tanan nga mga broker nagtrabaho sa kinapungkayan sa ilang mga kapabilidad).

Ang konsumo sa memorya sa JVM machine nagpabilin ubos sa 2 GB:

Ang trabaho sa mga broker nga adunay mga drive naapektuhan sa dili balanse sa mga partisyon:

kaplag

Ang iterative approach nga gipresentar sa ibabaw mahimong mapalapad aron matabonan ang mas komplikadong mga senaryo nga naglambigit sa gatusan ka mga konsumidor, repartitioning, rolling updates, pod restarts, etc. Kining tanan nagtugot kanamo sa pag-assess sa mga limitasyon sa kapabilidad sa Kafka cluster sa nagkalain-laing mga kondisyon, pag-ila sa mga bottleneck sa operasyon niini ug pagpangita og mga paagi aron mabuntog kini.

Gidisenyo namo ang Supertubes nga dali ug dali nga mag-deploy og cluster, i-configure kini, idugang/kuhaon ang mga broker ug mga hilisgutan, pagtubag sa mga alerto, ug pagsiguro nga ang Kafka sa kinatibuk-an nagtrabaho sa husto sa Kubernetes. Ang among tumong mao ang pagtabang kanimo sa pagkonsentrar sa nag-unang buluhaton ("pagmugna" ug "pagkonsumo" sa mga mensahe sa Kafka), ug ibilin ang tanang kahago sa Supertubes ug sa Kafka operator.

Kung interesado ka sa mga teknolohiya sa Banzai Cloud ug mga proyekto sa Open Source, pag-subscribe sa kompanya sa GitHub, LinkedIn o Twitter.

PS gikan sa tighubad

Basaha usab sa among blog:

• «Usa ka istorya sa Redis operator sa K8s ug usa ka mini-review sa mga utilities alang sa pag-analisar sa datos gikan niini nga database";
• «Seamless RabbitMQ sa Kubernetes nga paglalin";
• «zetcd gikan sa CoreOS: Pag-ilis sa ZooKeeper sa...etcd storage".

Source: www.habr.com