Maganda ba ang Kafka sa Kubernetes?

Pagbati, Habr!

Sa isang pagkakataon, kami ang unang nagpakilala ng paksa sa merkado ng Russia Kafka at magpatuloy subaybayan para sa pag-unlad nito. Sa partikular, natagpuan namin ang paksa ng pakikipag-ugnayan sa pagitan ng Kafka at Kubernetes. Mapapansin (at medyo maingat) artikulo ang paksang ito ay nai-publish sa Confluent blog noong Oktubre noong nakaraang taon sa ilalim ng pag-akda ni Gwen Shapira. Ngayon nais naming iguhit ang iyong pansin sa isang mas kamakailang artikulo mula Abril ni Johann Gyger, na, bagama't walang tandang pananong sa pamagat, ay sinusuri ang paksa sa isang mas makabuluhang paraan, kasama ang teksto na may mga kagiliw-giliw na link. Patawarin mo kami sa libreng pagsasalin ng "chaos monkey" kung kaya mo!

Pagpapakilala

Ang Kubernetes ay idinisenyo upang pangasiwaan ang mga walang estadong workload. Karaniwan, ang mga naturang workload ay ipinakita sa anyo ng isang microservice architecture, ang mga ito ay magaan, mahusay na sukat nang pahalang, sundin ang mga prinsipyo ng 12-factor na aplikasyon, at maaaring gumana sa mga circuit breaker at chaos monkey.

Ang Kafka, sa kabilang banda, ay mahalagang gumaganap bilang isang distributed database. Kaya, kapag nagtatrabaho, kailangan mong harapin ang estado, at ito ay mas mabigat kaysa sa isang microservice. Sinusuportahan ng Kubernetes ang mga stateful load, ngunit tulad ng itinuturo ng Kelsey Hightower sa dalawang tweet, dapat silang pangasiwaan nang may pag-iingat:

Nararamdaman ng ilang tao na kung gagawin mo ang Kubernetes sa isang stateful workload, ito ay magiging ganap na pinamamahalaang database na kalaban ng RDS. Mali ito. Siguro, kung magtatrabaho ka nang husto, magdagdag ng mga karagdagang bahagi at maakit ang isang pangkat ng mga inhinyero ng SRE, magagawa mong bumuo ng RDS sa ibabaw ng Kubernetes.

Palagi kong inirerekomenda na ang lahat ay mag-ingat nang husto kapag nagpapatakbo ng mga stateful na workload sa Kubernetes. Karamihan sa mga taong nagtatanong ng "maaari ba akong magpatakbo ng mga stateful workloads sa Kubernetes" ay walang sapat na karanasan sa Kubernetes, at madalas sa workload na kanilang itinatanong.

Kaya, dapat mo bang patakbuhin ang Kafka sa Kubernetes? Counter question: gagana ba ang Kafka nang walang Kubernetes? Iyon ang dahilan kung bakit gusto kong i-highlight sa artikulong ito kung paano pinagsasama-sama ng Kafka at Kubernetes ang isa't isa, at kung anong mga pitfalls ang maaaring dumating sa pagsasama-sama ng mga ito.

Oras ng pagkumpleto

Pag-usapan natin ang pangunahing bagay - ang runtime environment mismo

paraan

Ang mga Kafka broker ay CPU friendly. Maaaring magpakilala ang TLS ng ilang overhead. Gayunpaman, ang mga kliyente ng Kafka ay maaaring maging mas masinsinang CPU kung gumagamit sila ng pag-encrypt, ngunit hindi ito nakakaapekto sa mga broker.

memorya

Ang mga broker ng Kafka ay kumakain ng memorya. Karaniwang limitado sa 4-5 GB ang laki ng heap ng JVM, ngunit kakailanganin mo rin ng maraming memorya ng system dahil masyadong ginagamit ng Kafka ang cache ng page. Sa Kubernetes, magtakda ng container resource at humiling ng mga limitasyon nang naaayon.

Tindahan ng data

Ang imbakan ng data sa mga lalagyan ay panandalian - nawawala ang data kapag na-restart. Para sa data ng Kafka maaari kang gumamit ng volume emptyDir, at magiging katulad ang epekto: mawawala ang data ng iyong broker pagkatapos makumpleto. Ang iyong mga mensahe ay maaari pa ring maimbak sa ibang mga broker bilang mga replika. Samakatuwid, pagkatapos ng pag-restart, dapat munang kopyahin ng nabigong broker ang lahat ng data, at ang prosesong ito ay maaaring tumagal ng maraming oras.

Ito ang dahilan kung bakit dapat mong gamitin ang pangmatagalang imbakan ng data. Hayaan itong maging hindi lokal na pangmatagalang imbakan na may XFS file system o, mas tiyak, ext4. Huwag gumamit ng NFS. Binalaan kita. Hindi gagana ang mga bersyon ng NFS na v3 o v4. Sa madaling salita, mag-crash ang Kafka broker kung hindi nito matanggal ang direktoryo ng data dahil sa problemang "stupid rename" sa NFS. Kung hindi pa kita nakumbinsi, mag-ingat basahin ang artikulong ito. Ang data store ay dapat na hindi lokal upang ang Kubernetes ay mas madaling pumili ng bagong node pagkatapos ng pag-restart o paglipat.

Сеть

Tulad ng karamihan sa mga naka-distribute na system, ang pagganap ng Kafka ay lubos na nakadepende sa pagpapanatili ng network latency sa isang minimum at bandwidth sa maximum. Huwag subukang i-host ang lahat ng mga broker sa parehong node, dahil mababawasan nito ang kakayahang magamit. Kung nabigo ang isang Kubernetes node, mabibigo ang buong cluster ng Kafka. Gayundin, huwag ikalat ang Kafka cluster sa buong data center. Ang parehong napupunta para sa Kubernetes cluster. Ang isang magandang kompromiso sa kasong ito ay ang pumili ng iba't ibang mga availability zone.

Configuration

Mga regular na manifesto

Ang website ng Kubernetes ay mayroong napakahusay na gabay tungkol sa kung paano i-configure ang ZooKeeper gamit ang mga manifest. Dahil ang ZooKeeper ay bahagi ng Kafka, ito ay isang magandang lugar para magsimulang maging pamilyar sa kung aling mga konsepto ng Kubernetes ang nalalapat dito. Kapag naunawaan mo na ito, maaari mong gamitin ang parehong mga konsepto sa isang Kafka cluster.

• Sa ilalim: Ang pod ay ang pinakamaliit na nade-deploy na unit sa Kubernetes. Ang isang pod ay naglalaman ng iyong workload, at ang pod mismo ay tumutugma sa isang proseso sa iyong cluster. Ang isang pod ay naglalaman ng isa o higit pang mga lalagyan. Ang bawat ZooKeeper server sa ensemble at bawat broker sa Kafka cluster ay tatakbo sa isang hiwalay na pod.
• StatefulSet: Ang StatefulSet ay isang bagay na Kubernetes na humahawak ng maraming stateful na workload, at ang mga naturang workload ay nangangailangan ng koordinasyon. Ang StatefulSets ay nagbibigay ng mga garantiya tungkol sa pag-order ng mga pod at ang kanilang pagiging natatangi.
• Mga serbisyong walang ulo: Nagbibigay-daan sa iyo ang mga serbisyo na tanggalin ang mga pod mula sa mga kliyente gamit ang isang lohikal na pangalan. Ang mga Kubernetes sa kasong ito ay responsable para sa pagbabalanse ng load. Gayunpaman, kapag nagpapatakbo ng mga stateful workload, tulad ng ZooKeeper at Kafka, kailangang makipag-ugnayan ang mga kliyente sa isang partikular na pagkakataon. Dito magagamit ang mga serbisyong walang ulo: sa kasong ito, magkakaroon pa rin ng lohikal na pangalan ang kliyente, ngunit hindi mo na kailangang direktang makipag-ugnayan sa pod.
• Pangmatagalang dami ng imbakan: Ang mga volume na ito ay kailangan para i-configure ang hindi lokal na block na patuloy na storage na binanggit sa itaas.

Sa Yolean Nagbibigay ng komprehensibong hanay ng mga manifest upang matulungan kang makapagsimula sa Kafka sa Kubernetes.

Helm chart

Ang Helm ay isang package manager para sa isang Kubernetes na maihahambing sa mga OS package manager gaya ng yum, apt, Homebrew o Chocolatey. Ginagawa nitong madali ang pag-install ng mga paunang natukoy na software package na inilarawan sa mga Helm chart. Ang isang mahusay na napiling Helm chart ay ginagawang madali ang mahirap na gawain kung paano maayos na i-configure ang lahat ng mga parameter upang magamit ang Kafka sa Kubernetes. Mayroong ilang mga diagram ng Kafka: ang opisyal ay matatagpuan sa kondisyon ng incubator, may isa mula sa Lakas, isa pa - mula sa Bitnami.

Mga operator

Dahil may ilang mga pagkukulang ang Helm, ang isa pang tool ay nakakakuha ng malaking katanyagan: mga operator ng Kubernetes. Ang operator ay hindi lamang nag-package ng software para sa Kubernetes, ngunit nagbibigay-daan din sa iyo na i-deploy ang naturang software at pamahalaan ito.

Sa listahan kamangha-manghang mga operator Dalawang operator para sa Kafka ang nabanggit. Isa sa kanila - Strimzi. Sa Strimzi, madaling paandarin ang iyong Kafka cluster sa ilang minuto. Halos walang configuration ang kinakailangan, bilang karagdagan, ang operator mismo ay nagbibigay ng ilang magagandang tampok, halimbawa, point-to-point TLS encryption sa loob ng cluster. Nagbibigay din ang Confluent sariling operator.

Pagiging Produktibo

Mahalagang subukan ang pagganap sa pamamagitan ng pag-benchmark sa iyong Kafka instance. Tutulungan ka ng mga ganitong pagsubok na makahanap ng mga potensyal na bottleneck bago mangyari ang mga problema. Sa kabutihang palad, ang Kafka ay nagbibigay na ng dalawang mga tool sa pagsubok sa pagganap: kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. Gawing aktibong gamitin ang mga ito. Para sa sanggunian, maaari kang sumangguni sa mga resultang inilarawan sa itong poste Jay Kreps, o tumutok sa pagsusuring ito Amazon MSK ni Stéphane Maarek.

Mga Operasyon

Pagsubaybay

Napakahalaga ng transparency sa system - kung hindi, hindi mo mauunawaan kung ano ang nangyayari dito. Ngayon ay mayroong solid toolkit na nagbibigay ng pagsubaybay na nakabatay sa sukatan sa istilong cloud native. Dalawang tanyag na tool para sa layuning ito ay Prometheus at Grafana. Maaaring mangolekta ang Prometheus ng mga sukatan mula sa lahat ng proseso ng Java (Kafka, Zookeeper, Kafka Connect) gamit ang isang JMX exporter - sa pinakasimpleng paraan. Kung magdaragdag ka ng mga sukatan ng cAdvisor, mas lubos mong mauunawaan kung paano ginagamit ang mga mapagkukunan sa Kubernetes.

Ang Strimzi ay may isang napaka-maginhawang halimbawa ng isang Grafana dashboard para sa Kafka. Nakikita nito ang mga pangunahing sukatan, halimbawa, tungkol sa mga sektor na hindi ginagaya o iyong mga offline. Napakalinaw ng lahat doon. Ang mga sukatang ito ay kinukumpleto ng paggamit ng mapagkukunan at impormasyon sa pagganap, pati na rin ang mga tagapagpahiwatig ng katatagan. Kaya nakakakuha ka ng pangunahing Kafka cluster monitoring para sa wala!

Pinagmulan: streamzi.io/docs/master/#kafka_dashboard

Mainam na dagdagan ang lahat ng ito ng pagsubaybay sa kliyente (mga sukatan sa mga mamimili at producer), pati na rin ang pagsubaybay sa latency (para dito mayroong lungga) at end-to-end na pagsubaybay - para sa paggamit na ito Monitor ng Kafka.

Pagtotroso

Ang pag-log ay isa pang kritikal na gawain. Tiyaking naka-log sa lahat ng container sa iyong pag-install ng Kafka stdout и stderr, at tiyakin din na pinagsasama-sama ng iyong Kubernetes cluster ang lahat ng log sa isang central logging infrastructure, hal. Elasticsearch.

Health Check

Gumagamit ang Kubernetes ng liveness at readiness probe para tingnan kung normal na tumatakbo ang iyong mga pod. Kung nabigo ang liveness check, ihihinto ng Kubernetes ang container na iyon at pagkatapos ay awtomatikong i-restart ito kung itinakda nang naaayon ang patakaran sa pag-restart. Kung nabigo ang pagsusuri sa kahandaan, ihihiwalay ng Kubernetes ang pod sa mga kahilingan sa paglilingkod. Kaya, sa ganitong mga kaso, ang manu-manong interbensyon ay hindi na kinakailangan, na isang malaking plus.

Inilunsad ang mga update

Sinusuportahan ng StatefulSets ang mga awtomatikong pag-update: kung pipiliin mo ang diskarte sa RollingUpdate, ang bawat isa sa ilalim ng Kafka ay maa-update nang sunod-sunod. Sa ganitong paraan, maaaring mabawasan ang downtime sa zero.

Pagsusukat

Ang pag-scale ng isang Kafka cluster ay hindi isang madaling gawain. Gayunpaman, napakadali ng Kubernetes na i-scale ang mga pod sa isang tiyak na bilang ng mga replika, na nangangahulugang maaari mong tukuyin ang bilang ng maraming Kafka broker hangga't gusto mo. Ang pinakamahirap na bagay sa kasong ito ay ang muling pagtatalaga ng mga sektor pagkatapos i-scale pataas o bago i-scale pababa. Muli, tutulungan ka ng Kubernetes sa gawaing ito.

Pangangasiwa

Ang mga gawaing nauugnay sa pangangasiwa sa iyong Kafka cluster, tulad ng paggawa ng mga paksa at muling pagtatalaga ng mga sektor, ay maaaring gawin gamit ang mga umiiral nang shell script sa pamamagitan ng pagbubukas ng command line interface sa iyong mga pod. Gayunpaman, ang solusyon na ito ay hindi masyadong maganda. Sinusuportahan ng Strimzi ang pamamahala ng mga paksa gamit ang ibang operator. Mayroong ilang lugar para sa pagpapabuti dito.

I-backup at i-restore

Ngayon ang pagkakaroon ng Kafka ay depende rin sa pagkakaroon ng Kubernetes. Kung nabigo ang iyong Kubernetes cluster, sa pinakamasamang sitwasyon, ang iyong Kafka cluster ay mabibigo din. Ayon sa batas ni Murphy, tiyak na mangyayari ito, at mawawalan ka ng data. Para mabawasan ang ganitong uri ng panganib, magkaroon ng magandang backup na konsepto. Maaari mong gamitin ang MirrorMaker, ang isa pang pagpipilian ay ang paggamit ng S3 para dito, tulad ng inilarawan dito post mula sa Zalando.

Konklusyon

Kapag nagtatrabaho sa maliit hanggang katamtamang laki ng mga cluster ng Kafka, tiyak na sulit ang paggamit ng Kubernetes dahil nagbibigay ito ng karagdagang flexibility at pinapasimple ang karanasan ng operator. Kung mayroon kang napakalaking hindi gumaganang latency at/o mga kinakailangan sa throughput, maaaring mas mahusay na isaalang-alang ang ilang iba pang opsyon sa pag-deploy.

Pinagmulan: www.habr.com