Salam, Habr!
Dina hiji waktos, kami anu munggaran ngenalkeun topik ka pasar Rusia
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
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
- 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
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
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
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
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:
Éta hadé pikeun nambihan sadayana ieu kalayan ngawaskeun klien (métrik dina konsumen sareng produser), ogé ngawaskeun latency (kanggo ieu aya
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.
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
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