Apa Kafka ing Kubernetes apik?

Sugeng rawuh, Habr!

Ing sawijining wektu, kita minangka sing pisanan ngenalake topik kasebut menyang pasar Rusia Kafka lan terus trek kanggo pangembangane. Utamane, kita nemokake topik interaksi antarane Kafka lan Kubernetes. Bisa diamati (lan cukup ati-ati) artikel topik iki diterbitake ing blog Confluent bali ing Oktober taun pungkasan ing authorship saka Gwen Shapira. Dina iki kita pengin narik kawigaten sampeyan menyang artikel sing luwih anyar saka April dening Johann Gyger, sing, sanajan ora tanpa tandha pitakon ing judhul, mriksa topik kasebut kanthi cara sing luwih substantif, ngiringi teks kanthi pranala sing menarik. Nyuwun pangapunten terjemahan gratis "kethek chaos" yen sampeyan bisa!

Pambuka

Kubernetes dirancang kanggo nangani beban kerja tanpa negara. Biasane, beban kerja kasebut ditampilake ing bentuk arsitektur microservice, entheng, ukurane kanthi horisontal, tindakake prinsip aplikasi 12-faktor, lan bisa digunakake karo pemutus sirkuit lan monyet huru-hara.

Kafka, ing sisih liya, minangka basis data sing disebarake. Mangkono, nalika nggarap, sampeyan kudu ngatasi negara, lan luwih abot tinimbang microservice. Kubernetes ndhukung beban kerja sing lengkap, nanging kaya sing dituduhake Kelsey Hightower ing rong tweet, kudu ditangani kanthi ati-ati:

Sawetara wong rumangsa yen sampeyan muter Kubernetes dadi beban kerja sing lengkap, mula bakal dadi database sing dikelola kanthi lengkap sing saingan karo RDS. Iki salah. Mungkin, yen sampeyan kerja keras, nambah komponen tambahan lan narik tim insinyur SRE, sampeyan bakal bisa mbangun RDS ing ndhuwur Kubernetes.

Aku tansah nyaranake supaya saben wong kudu ngati-ati banget nalika mbukak beban kerja stateful ing Kubernetes. Umume wong sing takon "Apa aku bisa mbukak beban kerja ing Kubernetes" ora duwe pengalaman sing cukup karo Kubernetes, lan asring karo beban kerja sing ditakoni.

Dadi, sampeyan kudu mbukak Kafka ing Kubernetes? Pitakonan counter: bakal Kafka bisa luwih apik tanpa Kubernetes? Mulane aku pengin nyorot ing artikel iki carane Kafka lan Kubernetes nglengkapi saben liyane, lan apa pitfalls bisa teka karo gabungke.

Wektu rampung

Ayo dadi pirembagan bab dhasar - lingkungan runtime dhewe

proses

Kafka makelar sing CPU loropaken. TLS bisa uga ngenalake sawetara overhead. Nanging, klien Kafka bisa uga luwih intensif CPU yen nggunakake enkripsi, nanging iki ora mengaruhi makelar.

memori

Broker Kafka mangan memori. Ukuran tumpukan JVM biasane diwatesi kanggo 4-5 GB, nanging sampeyan uga butuh akeh memori sistem amarga Kafka nggunakake cache kaca banget. Ing Kubernetes, atur sumber daya wadah lan panjaluk watesan sing cocog.

Simpenan data

Panyimpenan data ing kontaner ora suwe - data ilang nalika diwiwiti maneh. Kanggo data Kafka sampeyan bisa nggunakake volume emptyDir, lan efek bakal padha: data broker sampeyan bakal ilang sawise rampung. Pesen sampeyan isih bisa disimpen ing makelar liyane minangka replika. Mulane, sawise miwiti maneh, makelar sing gagal kudu nggawe ulang kabeh data, lan proses iki bisa njupuk wektu akeh.

Mulane sampeyan kudu nggunakake panyimpenan data jangka panjang. Ayo dadi panyimpenan jangka panjang non-lokal kanthi sistem file XFS utawa, luwih tepat, ext4. Aja nggunakake NFS. Aku ngelingake sampeyan. NFS versi v3 utawa v4 ora bisa. Ing cendhak, makelar Kafka bakal nabrak yen ora bisa mbusak direktori data amarga masalah "ganti jeneng bodho" ing NFS. Yen aku durung ngyakinake sampeyan, kanthi ati-ati maca artikel iki. Panyimpenan data kudu non-lokal supaya Kubernetes bisa luwih fleksibel milih simpul anyar sawise miwiti maneh utawa relokasi.

Jaringan

Kaya sistem sing disebarake, kinerja Kafka gumantung banget kanggo njaga latensi jaringan dadi minimal lan bandwidth maksimal. Aja nyoba dadi tuan rumah kabeh makelar ing simpul sing padha, amarga iki bakal nyuda kasedhiyan. Yen simpul Kubernetes gagal, kabeh klompok Kafka bakal gagal. Uga, aja nyebar kluster Kafka ing kabeh pusat data. Semono uga kanggo kluster Kubernetes. Kompromi sing apik ing kasus iki yaiku milih zona kasedhiyan sing beda.

Konfigurasi

Manifesto biasa

Situs web Kubernetes wis guide apik banget babagan carane ngatur ZooKeeper nggunakake manifests. Wiwit ZooKeeper minangka bagéan saka Kafka, iki minangka papan sing apik kanggo miwiti kenal karo konsep Kubernetes sing ditrapake ing kene. Sawise sampeyan ngerti iki, sampeyan bisa nggunakake konsep sing padha karo klompok Kafka.

• Miturut: Pod minangka unit paling cilik sing bisa disebarake ing Kubernetes. Pod ngemot beban kerja sampeyan, lan pod kasebut cocog karo proses ing kluster sampeyan. Pod ngemot siji utawa luwih wadhah. Saben server ZooKeeper ing gamelan lan saben broker ing kluster Kafka bakal mbukak ing pod kapisah.
• StatefulSet: StatefulSet minangka obyek Kubernetes sing nangani macem-macem beban kerja stateful, lan beban kerja kasebut mbutuhake koordinasi. StatefulSets nyedhiyakake jaminan babagan pesenan polong lan keunikane.
• Layanan tanpa sirah: Layanan ngijini sampeyan kanggo copot pods saka klien nggunakake jeneng logis. Kubernetes ing kasus iki tanggung jawab kanggo load balancing. Nanging, nalika ngoperasikake beban kerja stateful, kayata ZooKeeper lan Kafka, klien kudu komunikasi karo conto tartamtu. Iki ngendi layanan tanpa kepala bisa migunani: ing kasus iki, klien isih bakal duwe jeneng logis, nanging sampeyan ora kudu langsung ngubungi pod.
• Volume panyimpenan jangka panjang: Volume iki dibutuhake kanggo ngatur panyimpenan terus-terusan pemblokiran non-lokal kasebut ing ndhuwur.

Ing Yolean Nyedhiyani set lengkap manifests kanggo mbantu sampeyan miwiti karo Kafka ing Kubernetes.

Bagan helm

Helm minangka manajer paket kanggo Kubernetes sing bisa dibandhingake karo manajer paket OS kayata yum, apt, Homebrew utawa Chocolatey. Iku nggampangake nginstal paket piranti lunak sing wis ditemtokake sing diterangake ing grafik Helm. Bagan Helm sing dipilih kanthi apik nggawe tugas sing angel kanggo ngatur kabeh paramèter kanthi bener kanggo nggunakake Kafka ing Kubernetes. Ana sawetara diagram Kafka: sing resmi ana ing kondisi inkubator, ana siji saka konfluen, siji maneh - saka Bitnami.

Operator

Amarga Helm duwe kekurangan tartamtu, alat liyane dadi populer: operator Kubernetes. Operator ora mung paket piranti lunak kanggo Kubernetes, nanging uga ngidini sampeyan masang piranti lunak kasebut lan ngatur.

Ing dhaptar operator apik tenan Loro operator kanggo Kafka kasebut. Salah sijine - Strimzi. Kanthi Strimzi, kluster Kafka sampeyan bisa mlaku sajrone sawetara menit. Sakbenere ora ana konfigurasi sing dibutuhake, Kajaba iku, operator kasebut nyedhiyakake sawetara fitur sing apik, contone, enkripsi TLS point-to-point ing kluster kasebut. Confluent uga nyedhiyakake operator dhewe.

Produktivitas

Penting kanggo nyoba kinerja kanthi benchmarking conto Kafka sampeyan. Tes kasebut bakal mbantu sampeyan nemokake kemungkinan bottlenecks sadurunge ana masalah. Untunge, Kafka wis nyedhiyakake rong alat uji kinerja: kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. Gunakake kanthi aktif. Kanggo referensi, sampeyan bisa ndeleng asil sing diterangake ing kirim iki Jay Kreps, utawa fokus ing review iki Amazon MSK dening Stéphane Maarek.

Operasi

Ngawasi

Transparansi ing sistem kasebut penting banget - yen ora, sampeyan ora bakal ngerti apa sing kedadeyan. Dina iki ana toolkit padhet sing nyedhiyakake pemantauan adhedhasar metrik ing gaya asli awan. Rong alat sing populer kanggo tujuan iki yaiku Prometheus lan Grafana. Prometheus bisa ngumpulake metrik saka kabeh proses Jawa (Kafka, Zookeeper, Kafka Connect) nggunakake eksportir JMX - kanthi cara sing paling gampang. Yen sampeyan nambahake metrik cAdvisor, sampeyan bisa luwih ngerti carane sumber daya digunakake ing Kubernetes.

Strimzi duwe conto sing trep banget saka dashboard Grafana kanggo Kafka. Iku nggambarake metrik kunci, contone, babagan sektor sing ora ditiru utawa sing offline. Kabeh cetha banget ing kono. Metrik kasebut dilengkapi karo panggunaan sumber daya lan informasi kinerja, uga indikator stabilitas. Dadi sampeyan entuk pemantauan kluster Kafka dhasar kanthi gratis!

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

Iku bakal becik kanggo nambah kabeh iki karo ngawasi klien (metrik ing konsumen lan produser), uga ngawasi latensi (kanggo iki ana burrow) lan ngawasi end-to-end - kanggo panggunaan iki Monitor Kab.

logging

Logging minangka tugas kritis liyane. Priksa manawa kabeh kontaner ing instalasi Kafka wis mlebu log stdout и stderr, lan uga mesthekake yen kluster Kubernetes sampeyan nggabungake kabeh log menyang infrastruktur logging pusat, contone. Elasticsearch.

Testing Fungsional

Kubernetes nggunakake probe liveness lan kesiapan kanggo mriksa apa pod sampeyan mlaku kanthi normal. Yen mriksa liveness gagal, Kubernetes bakal mungkasi wadhah kasebut lan kanthi otomatis miwiti maneh yen kabijakan miwiti maneh wis disetel. Yen mriksa kesiapan gagal, Kubernetes ngisolasi pod saka panjalukan layanan. Mangkono, ing kasus kaya mengkono, intervensi manual ora dibutuhake maneh, sing minangka plus gedhe.

Muter nganyari

StatefulSets ndhukung nganyari otomatis: yen sampeyan milih strategi RollingUpdate, saben ing Kafka bakal dianyari bebarengan. Kanthi cara iki, downtime bisa dikurangi dadi nol.

Scaling

Nggawe skala kluster Kafka dudu tugas sing gampang. Nanging, Kubernetes nggampangake ukuran pods menyang sawetara replika, tegese sampeyan bisa nemtokake akeh makelar Kafka sing dikarepake. Wangsulan: Bab ingkang paling angel ing kasus iki reassigning sektor sawise scaling munggah utawa sadurunge scaling mudhun. Maneh, Kubernetes bakal nulungi tugas iki.

Administrasi

Tugas sing ana gandhengane karo ngatur kluster Kafka, kayata nggawe topik lan nyetel maneh sektor, bisa ditindakake nggunakake skrip cangkang sing ana kanthi mbukak antarmuka baris perintah ing pods. Nanging, solusi iki ora apik banget. Strimzi ndhukung ngatur topik nggunakake operator beda. Ana sawetara papan kanggo dandan ing kene.

Резервное копирование lan восстановление

Saiki kasedhiyan Kafka uga bakal gumantung saka kasedhiyan Kubernetes. Yen kluster Kubernetes gagal, banjur ing skenario paling awon, kluster Kafka sampeyan uga bakal gagal. Miturut hukum Murphy, iki mesthi bakal kelakon, lan sampeyan bakal kelangan data. Kanggo nyuda jinis risiko iki, duwe konsep serep apik. Sampeyan bisa nggunakake MirrorMaker, pilihan liyane kanggo nggunakake S3 iki, minangka diterangake ing iki kirim saka Zalando.

kesimpulan

Nalika nggarap klompok Kafka cilik nganti medium, mesthine kudu nggunakake Kubernetes amarga menehi keluwesan tambahan lan nyederhanakake pengalaman operator. Yen sampeyan duwe latensi non-fungsi lan / utawa syarat throughput sing penting banget, mula luwih becik nimbang sawetara opsi panyebaran liyane.

Source: www.habr.com