Naha Kafka dina Kubernetes saé?

Salam, Habr!

Dina hiji waktos, kami anu munggaran ngenalkeun topik ka pasar Rusia Kafka sarta nuluykeun lagu pikeun pangwangunanana. Khususna, urang mendakan topik interaksi antara Kafka sareng Kubernetes. Bisa ditingali (sareng rada ati-ati) artikel topik ieu diterbitkeun dina blog Confluent deui dina Oktober taun ka tukang dina pangarang Gwen Shapira. Dinten ieu kami hoyong ngagambar perhatian anjeun ka artikel nu leuwih anyar ti April ku Johann Gyger, anu, sanajan teu tanpa tanda tanya dina judulna, examines topik dina ragam leuwih substantive, marengan téks kalawan tumbu metot. Punten ngahampura tarjamahan gratis tina "huru-hara monyet" upami anjeun tiasa!

perkenalan

Kubernetes dirancang pikeun nanganan beban kerja stateless. Ilaharna, workloads misalna dibere dina bentuk arsitéktur microservice, aranjeunna lightweight, skala ogé horisontal, turutan prinsip aplikasi 12-faktor, sarta bisa digawekeun ku breakers circuit sarta rusuh monyét.

Kafka, di sisi séjén, dasarna tindakan salaku database disebarkeun. Janten, nalika damel, anjeun kedah ngurus kaayaan, sareng éta langkung beurat tibatan microservice. Kubernetes ngadukung beban stateful, tapi sakumaha anu ditunjukkeun ku Kelsey Hightower dina dua tweets, aranjeunna kedah diurus kalayan ati-ati:

Sababaraha urang ngarasa yén lamun gulung Kubernetes kana workload stateful, eta jadi database junun pinuh nu saingan RDS. Ieu salah. Panginten, upami anjeun kerja keras, tambahkeun komponén tambahan sareng narik tim insinyur SRE, anjeun bakal tiasa ngawangun RDS di luhur Kubernetes.

Kuring salawasna nyarankeun yén dulur kudu ati-ati pisan nalika ngajalankeun beban kerja stateful dina Kubernetes. Seuseueurna jalma anu naroskeun "Naha kuring tiasa ngajalankeun beban kerja dina Kubernetes" teu gaduh pangalaman anu cekap sareng Kubernetes, sareng sering sareng beban kerja anu aranjeunna naroskeun.

Janten, naha anjeun kedah ngajalankeun Kafka dina Kubernetes? Patarosan counter: bakal Kafka tiasa dianggo langkung saé tanpa Kubernetes? Éta sababna kuring hoyong nyorot dina tulisan ieu kumaha Kafka sareng Kubernetes saling ngalengkepan, sareng pitfalls naon anu tiasa sumping nalika ngagabungkeun aranjeunna.

Waktos réngsé

Hayu urang ngobrol ngeunaan hal dasar - lingkungan runtime sorangan

proses

calo Kafka anu CPU friendly. TLS tiasa ngenalkeun sababaraha overhead. Sanajan kitu, klien Kafka bisa jadi leuwih CPU intensif lamun aranjeunna ngagunakeun enkripsi, tapi ieu teu mangaruhan calo.

ingetan

calo Kafka dahar nepi memori. Ukuran tumpukan JVM biasana dugi ka 4-5 GB, tapi anjeun ogé peryogi seueur mémori sistem saprak Kafka ngagunakeun cache halaman pisan. Dina Kubernetes, setel sumberdaya wadahna sareng pamenta wates sasuai.

Nyimpen data

Panyimpenan data dina wadahna sakedap - data leungit nalika di-restart. Pikeun data Kafka anjeun tiasa nganggo volume emptyDir, sarta pangaruh bakal sarupa: data calo anjeun bakal leungit sanggeus parantosan. Pesen anjeun masih tiasa disimpen dina calo sanés salaku réplika. Ku alatan éta, sanggeus balikan deui, calo gagal mimitina kudu ngayakeun réplikasi sadaya data, sarta prosés ieu tiasa nyandak loba waktu.

Ieu naha anjeun kedah nganggo neundeun data jangka panjang. Hayu janten panyimpenan jangka panjang non-lokal sareng sistem file XFS atanapi, langkung tepatna, ext4. Ulah make NFS. Kuring ngingetkeun anjeun. Versi NFS v3 atanapi v4 moal jalan. Pondokna, calo Kafka bakal ngadat upami teu tiasa ngahapus diréktori data kusabab masalah "ngaganti ngaran bodo" dina NFS. Upami kuring henteu acan ngayakinkeun anjeun, taliti pisan maca artikel ieu. Panyimpen data kedah non-lokal supados Kubernetes tiasa langkung fleksibel milih titik énggal saatos ngamimitian deui atanapi relokasi.

jaringan

Sapertos seueur sistem anu disebarkeun, kinerja Kafka gumantung pisan kana ngajaga latency jaringan ka minimum sareng bandwidth maksimal. Entong nyobian janten host sadayana calo dina titik anu sami, sabab ieu bakal ngirangan kasadiaan. Lamun titik Kubernetes gagal, sakabéh klaster Kafka bakal gagal. Ogé, ulah ngabubarkeun klaster Kafka di sakumna pusat data. Sami lumaku pikeun klaster Kubernetes. Kompromi anu hadé dina hal ieu nyaéta milih zona kasadiaan anu béda.

Konfigurasi

Manifesto biasa

Website Kubernetes boga pituduh pohara alus ngeunaan kumaha carana ngonpigurasikeun ZooKeeper ngagunakeun manifests. Kusabab ZooKeeper mangrupikeun bagian tina Kafka, ieu mangrupikeun tempat anu saé pikeun ngamimitian akrab sareng konsép Kubernetes anu dilarapkeun di dieu. Sakali anjeun ngartos ieu, anjeun tiasa nganggo konsép anu sami sareng klaster Kafka.

• odoh: Pod nyaéta unit deployable pangleutikna di Kubernetes. A pod ngandung workload Anjeun, jeung pod sorangan pakait jeung prosés dina klaster Anjeun. A pod ngandung hiji atawa leuwih peti. Unggal server ZooKeeper di ensemble jeung unggal calo di klaster Kafka bakal ngajalankeun dina pod misah.
• StatefulSet: A StatefulSet mangrupakeun obyék Kubernetes nu handles sababaraha workloads stateful, sarta workloads sapertos merlukeun koordinasi. StatefulSets nyadiakeun jaminan ngeunaan mesen pods sareng keunikanana.
• Jasa tanpa sirah: Jasa ngidinan Anjeun pikeun coplokkeun pods ti klien maké ngaran logis. Kubernetes dina hal ieu tanggung jawab pikeun kasaimbangan beban. Nanging, nalika ngajalankeun beban kerja stateful, sapertos ZooKeeper sareng Kafka, klien kedah komunikasi sareng conto khusus. Ieu dimana jasa headless datang dina gunana: dina hal ieu, klien masih bakal boga ngaran logis, tapi anjeun teu kudu ngahubungan pod langsung.
• Volume gudang jangka panjang: Jilid ieu diperlukeun pikeun ngonpigurasikeun blok non-lokal gudang pengkuh disebutkeun di luhur.

on Yolean Nyayogikeun sakumpulan manifes komprehensif pikeun ngabantosan anjeun ngamimitian nganggo Kafka dina Kubernetes.

Bagan helm

Helm mangrupikeun manajer pakét pikeun Kubernetes anu tiasa dibandingkeun sareng manajer pakét OS sapertos yum, apt, Homebrew atanapi Chocolatey. Ngagampangkeun masang bungkusan parangkat lunak anu tos siap dijelaskeun dina bagan Helm. Bagan Helm anu dipilih saé ngajantenkeun tugas anu sesah kumaha leres ngonpigurasikeun sadaya parameter pikeun ngagunakeun Kafka dina Kubernetes gampang. Aya sababaraha diagram Kafka: anu resmi aya dina kaayaan inkubator, aya hiji ti Confluent, hiji deui - ti Bitnami.

operator

Kusabab Helm ngagaduhan kalemahan anu tangtu, alat anu sanés janten popularitas anu ageung: operator Kubernetes. Operator henteu ngan ukur ngarangkep parangkat lunak pikeun Kubernetes, tapi ogé ngamungkinkeun anjeun nyebarkeun parangkat lunak sapertos kitu sareng ngatur éta.

Dina daptar operator endah pisan Dua operator pikeun Kafka disebutkeun. Salah sahijina - Strimzi. Kalawan Strimzi, éta gampang pikeun meunangkeun klaster Kafka anjeun sarta ngajalankeun dina sababaraha menit. Ampir henteu aya konfigurasi anu diperyogikeun, salian ti éta, operator sorangan nyayogikeun sababaraha fitur anu saé, contona, enkripsi TLS titik-ka-titik dina kluster. Confluent ogé nyadiakeun operator sorangan.

kakuwatan keur ngasilkeun

Penting pikeun nguji kinerja ku cara tolok ukur conto Kafka anjeun. Tés sapertos kitu bakal ngabantosan anjeun mendakan poténsi bottlenecks sateuacan aya masalah. Kabeneran, Kafka parantos nyayogikeun dua alat uji kinerja: kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. Jieun pamakéan aktip aranjeunna. Pikeun rujukan, anjeun tiasa ningali hasil anu dijelaskeun dina pos ieu Jay Kreps, atawa fokus kana ulasan ieu Amazon MSK ku Stéphane Maarek.

Operasi

Ngawaskeun

Transparansi dina sistem penting pisan - upami henteu, anjeun moal ngartos naon anu kajantenan di jerona. Dinten ieu aya toolkit padet nu nyadiakeun ngawaskeun dumasar metrics dina gaya pituin awan. Dua alat anu populér pikeun tujuan ieu nyaéta Prometheus sareng Grafana. Prometheus tiasa ngumpulkeun métrik tina sadaya prosés Java (Kafka, Zookeeper, Kafka Connect) nganggo eksportir JMX - ku cara anu paling sederhana. Upami anjeun nambihan métrik cAdvisor, anjeun tiasa langkung ngartos kumaha sumber daya dianggo dina Kubernetes.

Strimzi gaduh conto anu saé pisan tina dasbor Grafana pikeun Kafka. Ieu visualizes metrics konci, contona, ngeunaan séktor under-replicated atawa maranéhanana anu offline. Sagalana jelas pisan di dinya. Métrik ieu dilengkepan ku pamakean sumberdaya sareng inpormasi kinerja, ogé indikator stabilitas. Janten anjeun kéngingkeun ngawaskeun klaster Kafka dasar pikeun nanaon!

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

Éta hadé pikeun nambihan sadayana ieu kalayan ngawaskeun klien (métrik dina konsumen sareng produser), ogé ngawaskeun latency (kanggo ieu aya Burrow) jeung ngawaskeun tungtung-to-tungtung - pikeun pamakéan ieu Kafka Monitor.

logging

Logging mangrupikeun tugas kritis anu sanés. Pastikeun sadaya wadah dina pamasangan Kafka anjeun parantos log in stdout и stderr, sarta ogé mastikeun yén klaster Kubernetes Anjeun aggregates sadaya log kana infrastruktur logging sentral, misalna. Elasticsearch.

Pariksa Kaséhatan

Kubernetes nganggo usik liveness sareng kesiapan pikeun mariksa naha pod anjeun jalan normal. Upami pamariksaan liveness gagal, Kubernetes bakal ngeureunkeun wadahna teras otomatis balikan deui upami kawijakan balikan deui diatur sasuai. Upami pamariksaan kesiapan gagal, Kubernetes ngasingkeun pod tina pamenta ngalayanan. Janten, dina kasus sapertos kitu, campur tangan manual henteu diperyogikeun deui, anu mangrupikeun tambah ageung.

Ngaluncurkeun apdet

StatefulSets ngadukung apdet otomatis: upami anjeun milih strategi RollingUpdate, masing-masing di handapeun Kafka bakal diénggalan dina gilirannana. Ku cara kieu, downtime bisa diréduksi jadi nol.

Skala

Skala klaster Kafka sanés tugas anu gampang. Sanajan kitu, Kubernetes ngajadikeun eta pisan gampang pikeun skala pods ka sababaraha réplika, nu hartina anjeun declaratively bisa nangtukeun saloba calo Kafka sakumaha anjeun resep. Hal paling hese dina hal ieu reassigning séktor sanggeus scaling up atawa saméméh skala handap. Sakali deui, Kubernetes bakal ngabantosan anjeun dina tugas ieu.

Administrasi

Tugas nu patali jeung administering klaster Kafka Anjeun, kayaning nyieun jejer jeung reassigning séktor, bisa dipigawé maké skrip cangkang aya ku muka panganteur garis paréntah dina pods Anjeun. Sanajan kitu, leyuran ieu teu geulis pisan. Strimzi ngadukung ngatur topik nganggo operator anu béda. Aya sababaraha kamar pikeun perbaikan di dieu.

Nyadangkeun tur malikkeun

Ayeuna kasadiaan Kafka ogé bakal gumantung kana kasadiaan Kubernetes. Upami klaster Kubernetes anjeun gagal, teras dina skenario anu paling parah, klaster Kafka anjeun ogé bakal gagal. Numutkeun hukum Murphy, ieu pasti bakal kajadian, sareng anjeun bakal kaleungitan data. Pikeun ngurangan tipe ieu resiko, boga konsep cadangan alus. Anjeun tiasa make MirrorMaker, pilihan séjén nyaéta ngagunakeun S3 pikeun ieu, sakumaha dijelaskeun dina ieu tulisan ti Zalando.

kacindekan

Nalika damel sareng klaster Kafka leutik dugi ka sedeng, éta leres-leres nganggo Kubernetes sabab nyayogikeun kalenturan tambahan sareng nyederhanakeun pangalaman operator. Upami anjeun gaduh latency non-fungsi anu penting pisan sareng / atanapi syarat throughput, panginten langkung saé mertimbangkeun sababaraha pilihan panyebaran anu sanés.

sumber: www.habr.com