Kuamua ukubwa unaofaa kwa kundi la Kafka huko Kubernetes

Kumbuka. tafsiri.: Katika makala haya, Banzai Cloud inashiriki mfano wa jinsi zana zake maalum zinaweza kutumika kurahisisha matumizi ya Kafka ndani ya Kubernetes. Maagizo yafuatayo yanaonyesha jinsi unavyoweza kuamua ukubwa bora wa miundombinu yako na kusanidi Kafka yenyewe ili kufikia upitishaji unaohitajika.

Apache Kafka ni jukwaa la utiririshaji lililosambazwa kwa ajili ya kuunda mifumo ya utiririshaji inayotegemewa, inayoweza kusambazwa na yenye utendaji wa hali ya juu. Uwezo wake wa kuvutia unaweza kupanuliwa kwa kutumia Kubernetes. Kwa hili tumeendeleza Open Source Kafka operator na chombo kinachoitwa Supertubes. Hukuruhusu kuendesha Kafka kwenye Kubernetes na kutumia vipengele vyake mbalimbali, kama vile kurekebisha vizuri usanidi wa wakala, kupima kulingana na kipimo na kusawazisha upya, ufahamu wa rack, "laini" (mwenye neema) kusambaza sasisho, nk.

Jaribu Supertubes kwenye nguzo yako:

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

Au wasiliana nyaraka. Unaweza pia kusoma kuhusu baadhi ya uwezo wa Kafka, kazi ambayo ni automatiska kwa kutumia Supertubes na operator Kafka. Tayari tumeandika juu yao kwenye blogi:

• La! Bado mwendeshaji mwingine wa Kafka wa Kubernetes;
• Fuatilia na uendeshe Kafka kulingana na vipimo vya Prometheus;
• Uhamasishaji wa Kafka kwenye Kubernetes;
• Kuendesha Apache Kafka juu ya Istio - benchmark;
• Mtumiaji ameidhinishwa na kufikia vikundi vinavyodhibitiwa na opereta wa Kafka;
• Uboreshaji wa Kafka na usanidi unaobadilika kwenye Kubernetes;
• Kichujio cha itifaki ya mjumbe wa Kafka, chenye matundu.

Unapoamua kupeleka kundi la Kafka kwenye Kubernetes, kuna uwezekano kwamba utakabiliwa na changamoto ya kubainisha ukubwa unaofaa wa miundombinu ya msingi na haja ya kurekebisha usanidi wako wa Kafka ili kukidhi mahitaji ya upitishaji. Utendaji wa juu zaidi wa kila wakala huamuliwa na utendakazi wa vipengele vya msingi vya miundombinu, kama vile kumbukumbu, kichakataji, kasi ya diski, kipimo data cha mtandao, n.k.

Kwa hakika, usanidi wa wakala unapaswa kuwa hivi kwamba vipengele vyote vya miundombinu vinatumika kwa uwezo wao wa juu. Walakini, katika maisha halisi usanidi huu ni ngumu sana. Kuna uwezekano mkubwa kuwa watumiaji watasanidi madalali ili kuongeza matumizi ya kipengele kimoja au viwili (diski, kumbukumbu, au kichakataji). Kwa ujumla, wakala huonyesha utendakazi wa juu zaidi wakati usanidi wake unaruhusu kijenzi cha polepole zaidi kutumika kwa kiwango chake kikamilifu. Kwa njia hii tunaweza kupata wazo mbaya la mzigo ambao wakala mmoja anaweza kushughulikia.

Kinadharia, tunaweza pia kukadiria idadi ya madalali wanaohitajika kushughulikia mzigo fulani. Hata hivyo, katika mazoezi kuna chaguo nyingi za usanidi katika viwango tofauti kwamba ni vigumu sana (ikiwa haiwezekani) kutathmini utendaji unaowezekana wa usanidi fulani. Kwa maneno mengine, ni vigumu sana kupanga usanidi kulingana na utendaji fulani.

Kwa watumiaji wa Supertubes, kwa kawaida tunachukua mbinu ifuatayo: tunaanza na usanidi fulani (miundombinu + mipangilio), kisha kupima utendaji wake, kurekebisha mipangilio ya wakala na kurudia mchakato tena. Hii hutokea hadi sehemu ya polepole zaidi ya miundombinu itumike kikamilifu.

Kwa njia hii, tunapata wazo wazi la ni mawakala wangapi ambao nguzo inahitaji kushughulikia mzigo fulani (idadi ya madalali pia inategemea mambo mengine, kama vile idadi ya chini ya nakala za ujumbe ili kuhakikisha uthabiti, idadi ya kizigeu. viongozi, nk). Kwa kuongeza, tunapata ufahamu kuhusu vipengele vipi vya miundombinu vinahitaji kuongezwa kwa wima.

Makala haya yatazungumza kuhusu hatua tunazochukua ili kupata manufaa zaidi kutoka kwa vipengele vya polepole zaidi katika usanidi wa awali na kupima uboreshaji wa nguzo ya Kafka. Usanidi thabiti unahitaji angalau madalali watatu wanaoendesha (min.insync.replicas=3), kusambazwa katika kanda tatu tofauti za ufikivu. Ili kusanidi, kupima na kufuatilia miundombinu ya Kubernetes, tunatumia jukwaa letu la usimamizi wa kontena kwa mawingu mseto - Pipeline. Inasaidia kwenye msingi (chuma tupu, VMware) na aina tano za mawingu (Alibaba, AWS, Azure, Google, Oracle), pamoja na mchanganyiko wowote wao.

Mawazo juu ya miundombinu ya nguzo ya Kafka na usanidi

Kwa mifano iliyo hapa chini, tulichagua AWS kama mtoa huduma wa wingu na EKS kama usambazaji wa Kubernetes. Usanidi sawa unaweza kutekelezwa kwa kutumia P.K.E. - Usambazaji wa Kubernetes kutoka Banzai Cloud, ulioidhinishwa na CNCF.

disk

Amazon inatoa anuwai Aina za kiasi cha EBS. Katika msingi gp2 и io1 kuna viendeshi vya SSD, hata hivyo, ili kuhakikisha upitishaji wa juu gp2 hutumia mikopo iliyokusanywa (Mikopo ya I/O), kwa hivyo tulipendelea aina io1, ambayo inatoa upitishaji thabiti wa hali ya juu.

Aina za mifano

Utendaji wa Kafka unategemea sana kache ya ukurasa wa mfumo wa uendeshaji, kwa hivyo tunahitaji matukio yenye kumbukumbu ya kutosha kwa madalali (JVM) na kashe ya ukurasa. Mfano c5.2 kubwa - mwanzo mzuri, kwa kuwa ina 16 GB ya kumbukumbu na imeboreshwa kufanya kazi na EBS. Ubaya wake ni kwamba ina uwezo wa kutoa utendaji wa juu kwa si zaidi ya dakika 30 kila masaa 24. Ikiwa mzigo wako wa kazi unahitaji utendakazi wa kilele kwa muda mrefu, unaweza kutaka kuzingatia aina zingine za mifano. Hivyo ndivyo tulivyofanya, tukisimama c5.4 kubwa. Inatoa upeo wa upitishaji ndani 593,75 Mb/s. Upeo wa upitishaji wa ujazo wa EBS io1 juu kuliko mfano c5.4 kubwa, kwa hivyo kipengele cha polepole zaidi cha miundombinu kinaweza kuwa njia ya I/O ya aina hii ya mfano (ambayo vipimo vyetu vya mzigo vinapaswa pia kudhibitisha).

Mtandao

Upitishaji wa mtandao lazima uwe mkubwa wa kutosha ikilinganishwa na utendaji wa mfano wa VM na diski, vinginevyo mtandao unakuwa kizuizi. Kwa upande wetu, interface ya mtandao c5.4 kubwa inasaidia kasi ya hadi 10 Gb/s, ambayo ni kubwa zaidi kuliko upitishaji wa I/O wa mfano wa VM.

Usambazaji wa Dalali

Madalali wanapaswa kutumwa (iliyoratibiwa katika Kubernetes) kwa nodi maalum ili kuepuka kushindana na michakato mingine ya CPU, kumbukumbu, mtandao na rasilimali za diski.

Toleo la Java

Chaguo la kimantiki ni Java 11 kwa sababu inaendana na Docker kwa maana kwamba JVM huamua kwa usahihi vichakataji na kumbukumbu inayopatikana kwenye kontena ambamo wakala anaendesha. Ikijua kwamba vikomo vya CPU ni muhimu, JVM huweka ndani na kwa uwazi idadi ya nyuzi za GC na nyuzi za JIT. Tulitumia picha ya Kafka banzaicloud/kafka:2.13-2.4.0, ambayo inajumuisha toleo la Kafka 2.4.0 (Scala 2.13) kwenye Java 11.

Ikiwa ungependa kujifunza zaidi kuhusu Java/JVM kwenye Kubernetes, angalia machapisho yetu yafuatayo:

• Kwa nini programu yangu ya Java ni OOMKilled;
• Jinsi ya kusawazisha vyombo kwa usahihi kwa programu 10 za Java.

Mipangilio ya kumbukumbu ya wakala

Kuna vipengele viwili muhimu vya kusanidi kumbukumbu ya wakala: mipangilio ya JVM na ganda la Kubernetes. Kikomo cha kumbukumbu kilichowekwa kwa ganda lazima kiwe kikubwa kuliko ukubwa wa juu zaidi wa lundo ili JVM iwe na nafasi ya metaspace ya Java ambayo hukaa katika kumbukumbu yake yenyewe na kwa kashe ya ukurasa wa mfumo wa uendeshaji ambayo Kafka hutumia kikamilifu. Katika vipimo vyetu tulizindua madalali wa Kafka na vigezo -Xmx4G -Xms2G, na kikomo cha kumbukumbu kwa ganda kilikuwa 10 Gi. Tafadhali kumbuka kuwa mipangilio ya kumbukumbu ya JVM inaweza kupatikana kiotomatiki kwa kutumia -XX:MaxRAMPercentage и -X:MinRAMPercentage, kulingana na kikomo cha kumbukumbu kwa pod.

Mipangilio ya kichakataji cha wakala

Kwa ujumla, unaweza kuboresha utendaji kwa kuongeza usawa kwa kuongeza idadi ya nyuzi zinazotumiwa na Kafka. Wasindikaji zaidi wanaopatikana kwa Kafka, ni bora zaidi. Katika mtihani wetu, tulianza na kikomo cha wasindikaji 6 na hatua kwa hatua (kwa njia ya kurudia) iliinua idadi yao hadi 15. Kwa kuongeza, tunaweka. num.network.threads=12 katika mipangilio ya wakala ili kuongeza idadi ya nyuzi zinazopokea data kutoka kwa mtandao na kuzituma. Mara baada ya kugundua kuwa mawakala mfuasi hawakuweza kupokea nakala haraka vya kutosha, waliinua num.replica.fetchers hadi 4 ili kuongeza kasi ambayo wafuasi wa madalali walinakili ujumbe kutoka kwa viongozi.

Zana ya Kuzalisha Mizigo

Unapaswa kuhakikisha kuwa jenereta ya upakiaji iliyochaguliwa haiishiwi na uwezo kabla ya nguzo ya Kafka (ambayo inawekwa alama) kufikia mzigo wake wa juu zaidi. Kwa maneno mengine, ni muhimu kufanya tathmini ya awali ya uwezo wa chombo cha kuzalisha mzigo, na pia kuchagua aina za mfano kwa idadi ya kutosha ya wasindikaji na kumbukumbu. Katika kesi hii, chombo chetu kitatoa mzigo zaidi kuliko nguzo ya Kafka inaweza kushughulikia. Baada ya majaribio mengi, tulitatua nakala tatu c5.4 kubwa, ambayo kila moja ilikuwa na jenereta inayoendesha.

Kuweka alama

Kipimo cha utendaji ni mchakato unaorudiwa unaojumuisha hatua zifuatazo:

• kuanzisha miundombinu (nguzo ya EKS, nguzo ya Kafka, chombo cha kuzalisha mzigo, pamoja na Prometheus na Grafana);
• kuzalisha mzigo kwa kipindi fulani ili kuchuja kupotoka kwa nasibu katika viashiria vya utendaji vilivyokusanywa;
• kurekebisha miundombinu na usanidi wa wakala kulingana na viashiria vya utendaji vilivyozingatiwa;
• kurudia mchakato hadi kiwango kinachohitajika cha upitishaji wa nguzo ya Kafka kinapatikana. Wakati huo huo, lazima iweze kuzaliana mara kwa mara na ionyeshe tofauti ndogo katika upitishaji.

Sehemu inayofuata inaelezea hatua ambazo zilitekelezwa wakati wa mchakato wa kuweka alama kwenye nguzo ya majaribio.

Vyombo vya

Zana zifuatazo zilitumika kupeleka kwa haraka usanidi wa msingi, kuzalisha mizigo, na kupima utendakazi:

• Bomba la Wingu la Banzai kwa kuandaa nguzo ya EKS kutoka Amazon c Prometheus (kukusanya Kafka na vipimo vya miundombinu) na grafana (ili kuibua vipimo hivi). Tulichukua faida jumuishi в Pipeline huduma zinazotoa ufuatiliaji wa shirikisho, ukusanyaji wa kumbukumbu kati, skanning ya uwezekano, uokoaji wa maafa, usalama wa kiwango cha biashara na mengi zaidi.
• Sangrenel - chombo cha kupima upakiaji wa nguzo ya Kafka.
• Dashibodi za Grafana za kuibua metriki na miundombinu ya Kafka: Kubernetes Kafka, Msafirishaji wa nodi.
• Supertubes CLI kwa njia rahisi zaidi ya kusanidi nguzo ya Kafka kwenye Kubernetes. Zookeeper, opereta wa Kafka, Mjumbe na vipengee vingine vingi vimesakinishwa na kusanidiwa ipasavyo ili kuendesha nguzo ya Kafka iliyo tayari kwa uzalishaji kwenye Kubernetes.
  • Kwa ajili ya ufungaji CLI bora tumia maagizo yaliyotolewa hapa.

Kundi la EKS

Andaa nguzo ya EKS iliyo na nodi za wafanyikazi waliojitolea c5.4 kubwa katika maeneo tofauti ya upatikanaji wa maganda na wakala wa Kafka, pamoja na nodi maalum kwa jenereta ya mzigo na miundombinu ya ufuatiliaji.

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

Mara tu nguzo ya EKS inapoanza na kufanya kazi, wezesha kuunganishwa kwake huduma ya ufuatiliaji - atapeleka Prometheus na Grafana kwenye nguzo.

Vipengele vya mfumo wa Kafka

Sakinisha vipengee vya mfumo wa Kafka (Zookeeper, kafka-operator) katika EKS kwa kutumia supertubes CLI:

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

Nguzo ya Kafka

Kwa chaguo-msingi, EKS hutumia viwango vya EBS vya aina gp2, kwa hivyo unahitaji kuunda darasa tofauti la hifadhi kulingana na kiasi io1 kwa nguzo ya Kafka:

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

Weka parameter kwa madalali min.insync.replicas=3 na kupeleka maganda ya wakala kwenye nodi katika maeneo matatu tofauti ya upatikanaji:

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

Mada

Tuliendesha matukio matatu ya jenereta ya mzigo kwa sambamba. Kila mmoja wao anaandika kwa mada yake mwenyewe, ambayo ni, tunahitaji mada tatu kwa jumla:

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

Kwa kila mada, kipengele cha kurudia ni 3—thamani ya chini inayopendekezwa kwa mifumo ya uzalishaji inayopatikana sana.

Zana ya Kuzalisha Mizigo

Tulizindua nakala tatu za jenereta ya mzigo (kila mmoja aliandika katika mada tofauti). Kwa maganda ya jenereta ya kupakia, unahitaji kuweka mshikamano wa nodi ili iweze kupangwa tu kwenye nodi zilizotengwa kwa ajili yao:

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

Mambo machache ya kuzingatia:

• Jenereta ya upakiaji hutoa ujumbe wa baiti 512 kwa urefu na kuzichapisha kwa Kafka katika vikundi vya jumbe 500.
• Kwa kutumia hoja -required-acks=all Uchapishaji huo unachukuliwa kuwa umefaulu wakati nakala zote zilizosawazishwa za ujumbe zinapokewa na kuthibitishwa na madalali wa Kafka. Hii ina maana kwamba katika kipimo hatukupima tu kasi ya viongozi kupokea ujumbe, lakini pia wafuasi wao kunakili ujumbe. Madhumuni ya jaribio hili sio kutathmini kasi ya usomaji wa watumiaji (watumiaji) ujumbe uliopokea hivi karibuni ambao bado unabaki kwenye cache ya ukurasa wa OS, na kulinganisha kwake na kasi ya kusoma ya ujumbe uliohifadhiwa kwenye diski.
• Jenereta ya mzigo inaendesha wafanyikazi 20 kwa sambamba (-workers=20) Kila mfanyakazi ana wazalishaji 5 wanaoshiriki muunganisho wa mfanyakazi kwenye nguzo ya Kafka. Matokeo yake, kila jenereta ina wazalishaji 100, na wote hutuma ujumbe kwa kikundi cha Kafka.

Kufuatilia afya ya nguzo

Wakati wa majaribio ya upakiaji wa nguzo ya Kafka, pia tulifuatilia afya yake ili kuhakikisha kuwa hakuna uanzishaji upya wa ganda, hakuna nakala ambazo hazijasawazishwa, na kiwango cha juu cha upitishaji kilicho na mabadiliko madogo:

• Jenereta ya upakiaji huandika takwimu za kawaida kuhusu idadi ya ujumbe zilizochapishwa na kiwango cha makosa. Kiwango cha makosa kinapaswa kubaki sawa 0,00%.
• Udhibiti wa Cruise, iliyotumwa na kafka-operator, hutoa dashibodi ambapo tunaweza pia kufuatilia hali ya nguzo. Ili kutazama kidirisha hiki fanya:

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

• Kiwango cha ISR (idadi ya nakala za "usawazishaji") kupungua na upanuzi ni sawa na 0.

Matokeo ya kipimo

Madalali 3, saizi ya ujumbe - 512 byte

Kwa partitions kusambazwa sawasawa katika mawakala watatu, tuliweza kufikia utendaji ~500 Mb/s (takriban ujumbe elfu 990 kwa sekunde):

Matumizi ya kumbukumbu ya mashine ya kawaida ya JVM hayakuzidi GB 2:

Upitishaji wa diski ulifikia kiwango cha juu cha upitishaji wa nodi ya I/O katika visa vyote vitatu ambavyo madalali walikuwa wakifanya kazi:

Kutoka kwa data juu ya utumiaji wa kumbukumbu na nodi, inafuata kwamba buffering ya mfumo na caching ilichukua ~ 10-15 GB:

Madalali 3, saizi ya ujumbe - 100 byte

Kadiri ukubwa wa ujumbe unavyopungua, upitishaji hupungua kwa takriban 15-20%: muda unaotumika kuchakata kila ujumbe huathiri. Kwa kuongeza, mzigo wa processor una karibu mara mbili.

Kwa kuwa nodi za wakala bado zina cores ambazo hazijatumiwa, utendaji unaweza kuboreshwa kwa kubadilisha usanidi wa Kafka. Hii sio kazi rahisi, kwa hivyo ili kuongeza upitishaji ni bora kufanya kazi na ujumbe mkubwa.

Madalali 4, saizi ya ujumbe - 512 byte

Unaweza kuongeza utendaji wa nguzo ya Kafka kwa urahisi kwa kuongeza madalali wapya na kudumisha usawa wa sehemu (hii inahakikisha kuwa mzigo unasambazwa sawasawa kati ya madalali). Kwa upande wetu, baada ya kuongeza broker, upitishaji wa nguzo uliongezeka hadi ~580 Mb/s (ujumbe ~ milioni 1,1 kwa sekunde). Ukuaji uligeuka kuwa mdogo kuliko ilivyotarajiwa: hii inaelezewa hasa na usawa wa partitions (sio madalali wote hufanya kazi katika kilele cha uwezo wao).

Matumizi ya kumbukumbu ya mashine ya JVM yalibaki chini ya 2 GB:

Kazi ya madalali walio na anatoa iliathiriwa na usawa wa kizigeu:

Matokeo

Mbinu ya kurudia iliyowasilishwa hapo juu inaweza kupanuliwa ili kujumuisha hali ngumu zaidi zinazohusisha mamia ya watumiaji, kugawa upya, kusasisha, kuwasha tena pod, n.k. Yote hii inatuwezesha kutathmini mipaka ya uwezo wa nguzo ya Kafka katika hali mbalimbali, kutambua vikwazo katika uendeshaji wake na kutafuta njia za kupambana nao.

Tulibuni Supertubes ili kusambaza kundi kwa haraka na kwa urahisi, kulisanidi, kuongeza/kuondoa madalali na mada, kujibu arifa na kuhakikisha kuwa Kafka kwa ujumla inafanya kazi ipasavyo kwenye Kubernetes. Lengo letu ni kukusaidia kuzingatia kazi kuu ("toa" na "tumia" ujumbe wa Kafka), na kuacha kazi ngumu kwa Supertubes na operator wa Kafka.

Ikiwa una nia ya teknolojia ya Banzai Cloud na miradi ya Open Source, jiandikishe kwa kampuni kwa GitHub, LinkedIn au Twitter.

PS kutoka kwa mtafsiri

Soma pia kwenye blogi yetu:

• «Hadithi moja na opereta wa Redis katika K8s na hakiki ndogo ya huduma za kuchambua data kutoka kwa hifadhidata hii.";
• «Uhamiaji bila mshono wa RabbitMQ hadi Kubernetes";
• «zetcd kutoka CoreOS: Kubadilisha ZooKeeper na...nkd hifadhi'.

Chanzo: mapenzi.com