Adakah Kafka di Kubernetes bagus?

Salam, Habr!

Pada satu masa, kami adalah yang pertama memperkenalkan topik ini kepada pasaran Rusia Kafka dan teruskan trek untuk perkembangannya. Khususnya, kami menemui topik interaksi antara Kafka dan Kubernetes. Boleh diperhatikan (dan agak berhati-hati) artikel topik ini telah diterbitkan di blog Confluent pada Oktober tahun lalu di bawah kepengarangan Gwen Shapira. Hari ini kami ingin menarik perhatian anda kepada artikel yang lebih baru dari April oleh Johann Gyger, yang, walaupun bukan tanpa tanda tanya dalam tajuk, meneliti topik dengan cara yang lebih substantif, mengiringi teks dengan pautan yang menarik. Harap maafkan kami terjemahan percuma "chaos monkey" jika anda boleh!

Pengenalan

Kubernetes direka bentuk untuk mengendalikan beban kerja tanpa kewarganegaraan. Biasanya, beban kerja sedemikian dibentangkan dalam bentuk seni bina perkhidmatan mikro, ia ringan, skala mendatar dengan baik, mengikut prinsip aplikasi 12 faktor, dan boleh berfungsi dengan pemutus litar dan monyet huru-hara.

Kafka, sebaliknya, pada dasarnya bertindak sebagai pangkalan data yang diedarkan. Oleh itu, apabila bekerja, anda perlu berurusan dengan keadaan, dan ia jauh lebih berat daripada perkhidmatan mikro. Kubernetes menyokong beban stateful, tetapi seperti yang ditunjukkan oleh Kelsey Hightower dalam dua tweet, mereka harus dikendalikan dengan berhati-hati:

Sesetengah orang merasakan bahawa jika anda melancarkan Kubernetes ke dalam beban kerja stateful, ia menjadi pangkalan data terurus sepenuhnya yang menyaingi RDS. Ini adalah salah. Mungkin, jika anda bekerja keras, menambah komponen tambahan dan menarik pasukan jurutera SRE, anda akan dapat membina RDS di atas Kubernetes.

Saya sentiasa mengesyorkan agar semua orang sentiasa berhati-hati apabila menjalankan beban kerja stateful pada Kubernetes. Kebanyakan orang yang bertanya "bolehkah saya menjalankan beban kerja stateful di Kubernetes" tidak mempunyai pengalaman yang mencukupi dengan Kubernetes, dan selalunya dengan beban kerja yang mereka tanyakan.

Jadi, patutkah anda menjalankan Kafka di Kubernetes? Soalan balas: adakah Kafka akan berfungsi dengan lebih baik tanpa Kubernetes? Itulah sebabnya saya ingin menyerlahkan dalam artikel ini bagaimana Kafka dan Kubernetes saling melengkapi, dan apakah perangkap yang boleh datang dengan menggabungkan mereka.

Masa siap

Mari kita bercakap tentang perkara asas - persekitaran masa jalan itu sendiri

proses

Broker Kafka mesra CPU. TLS mungkin memperkenalkan beberapa overhed. Walau bagaimanapun, pelanggan Kafka mungkin lebih intensif CPU jika mereka menggunakan penyulitan, tetapi ini tidak menjejaskan broker.

memori

Broker Kafka memakan memori. Saiz timbunan JVM biasanya terhad kepada 4-5 GB, tetapi anda juga memerlukan banyak memori sistem kerana Kafka menggunakan cache halaman dengan sangat banyak. Dalam Kubernetes, tetapkan sumber kontena dan had permintaan dengan sewajarnya.

Simpanan data

Penyimpanan data dalam bekas adalah tidak lama - data hilang apabila dimulakan semula. Untuk data Kafka anda boleh menggunakan volum emptyDir, dan kesannya akan serupa: data broker anda akan hilang selepas selesai. Mesej anda masih boleh disimpan di broker lain sebagai replika. Oleh itu, selepas dimulakan semula, broker yang gagal mesti terlebih dahulu meniru semua data, dan proses ini boleh mengambil banyak masa.

Inilah sebabnya mengapa anda harus menggunakan storan data jangka panjang. Biarkan ia menjadi storan jangka panjang bukan tempatan dengan sistem fail XFS atau, lebih tepat lagi, ext4. Jangan gunakan NFS. Saya memberi amaran kepada awak. NFS versi v3 atau v4 tidak akan berfungsi. Pendek kata, broker Kafka akan ranap jika ia tidak dapat memadamkan direktori data kerana masalah "menamakan semula bodoh" dalam NFS. Jika saya belum meyakinkan anda, berhati-hati baca artikel ini. Stor data hendaklah bukan setempat supaya Kubernetes boleh memilih nod baharu dengan lebih fleksibel selepas dimulakan semula atau penempatan semula.

Сеть

Seperti kebanyakan sistem yang diedarkan, prestasi Kafka sangat bergantung pada mengekalkan kependaman rangkaian pada tahap minimum dan lebar jalur maksimum. Jangan cuba untuk menjadi hos semua broker pada nod yang sama, kerana ini akan mengurangkan ketersediaan. Jika nod Kubernetes gagal, keseluruhan gugusan Kafka akan gagal. Juga, jangan menyebarkan gugusan Kafka di seluruh pusat data. Begitu juga dengan kluster Kubernetes. Kompromi yang baik dalam kes ini ialah memilih zon ketersediaan yang berbeza.

Konfigurasi

Manifesto biasa

Laman web Kubernetes mempunyai panduan yang sangat baik tentang cara mengkonfigurasi ZooKeeper menggunakan manifes. Memandangkan ZooKeeper adalah sebahagian daripada Kafka, ini adalah tempat yang baik untuk mula membiasakan diri dengan konsep Kubernetes yang digunakan di sini. Sebaik sahaja anda memahami perkara ini, anda boleh menggunakan konsep yang sama dengan gugusan Kafka.

• Di bawah: Pod ialah unit terkecil yang boleh digunakan dalam Kubernetes. Pod mengandungi beban kerja anda dan pod itu sendiri sepadan dengan proses dalam kelompok anda. Satu pod mengandungi satu atau lebih bekas. Setiap pelayan ZooKeeper dalam ensemble dan setiap broker dalam kelompok Kafka akan berjalan dalam pod yang berasingan.
• StatefulSet: StatefulSet ialah objek Kubernetes yang mengendalikan berbilang beban kerja stateful, dan beban kerja tersebut memerlukan penyelarasan. StatefulSets memberikan jaminan mengenai pesanan pod dan keunikannya.
• Perkhidmatan tanpa kepala: Perkhidmatan membolehkan anda menanggalkan pod daripada pelanggan menggunakan nama logik. Kubernetes dalam kes ini bertanggungjawab untuk mengimbangi beban. Walau bagaimanapun, apabila mengendalikan beban kerja stateful, seperti ZooKeeper dan Kafka, pelanggan perlu berkomunikasi dengan contoh tertentu. Di sinilah perkhidmatan tanpa kepala berguna: dalam kes ini, pelanggan masih akan mempunyai nama logik, tetapi anda tidak perlu menghubungi pod secara langsung.
• Jumlah simpanan jangka panjang: Jumlah ini diperlukan untuk mengkonfigurasi storan berterusan blok bukan tempatan yang disebutkan di atas.

Pada Yolean Menyediakan set manifes yang komprehensif untuk membantu anda bermula dengan Kafka di Kubernetes.

Carta helm

Helm ialah pengurus pakej untuk Kubernetes yang boleh dibandingkan dengan pengurus pakej OS seperti yum, apt, Homebrew atau Chocolatey. Ia memudahkan untuk memasang pakej perisian pratakrif yang diterangkan dalam carta Helm. Carta Helm yang dipilih dengan baik menjadikan tugas sukar untuk mengkonfigurasi semua parameter untuk menggunakan Kafka pada Kubernetes dengan betul. Terdapat beberapa gambar rajah Kafka: yang rasmi terletak dalam keadaan inkubator, ada satu dari persimpangan, satu lagi - daripada Bitnami.

Operator

Oleh kerana Helm mempunyai kelemahan tertentu, alat lain semakin popular: pengendali Kubernetes. Pengendali bukan sahaja membungkus perisian untuk Kubernetes, tetapi juga membenarkan anda menggunakan perisian tersebut dan mengurusnya.

Dalam senarai pengendali yang menakjubkan Dua operator untuk Kafka disebut. Salah seorang daripada mereka - Strimzi. Dengan Strimzi, mudah untuk mendapatkan kluster Kafka anda dan berjalan dalam beberapa minit. Hampir tiada konfigurasi diperlukan, di samping itu, pengendali itu sendiri menyediakan beberapa ciri yang bagus, contohnya, penyulitan TLS titik ke titik dalam kelompok. Confluent juga menyediakan pengendali sendiri.

Produktiviti

Adalah penting untuk menguji prestasi dengan menanda aras contoh Kafka anda. Ujian sedemikian akan membantu anda mencari kemungkinan kesesakan sebelum masalah timbul. Nasib baik, Kafka sudah menyediakan dua alat ujian prestasi: kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. Gunakan secara aktif mereka. Untuk rujukan, anda boleh merujuk kepada keputusan yang diterangkan dalam jawatan ini Jay Kreps, atau fokus pada ulasan ini Amazon MSK oleh Stéphane Maarek.

Operasi

Pemantauan

Ketelusan dalam sistem adalah sangat penting - jika tidak, anda tidak akan memahami apa yang berlaku di dalamnya. Hari ini terdapat kit alat kukuh yang menyediakan pemantauan berasaskan metrik dalam gaya asli awan. Dua alat popular untuk tujuan ini ialah Prometheus dan Grafana. Prometheus boleh mengumpul metrik daripada semua proses Java (Kafka, Zookeeper, Kafka Connect) menggunakan pengeksport JMX - dengan cara yang paling mudah. Jika anda menambah metrik cAdvisor, anda boleh memahami dengan lebih lengkap cara sumber digunakan dalam Kubernetes.

Strimzi mempunyai contoh papan pemuka Grafana yang sangat mudah untuk Kafka. Ia menggambarkan metrik utama, contohnya, mengenai sektor yang kurang direplikasi atau yang berada di luar talian. Semuanya sangat jelas di sana. Metrik ini dilengkapi dengan penggunaan sumber dan maklumat prestasi, serta penunjuk kestabilan. Jadi anda mendapat pemantauan gugusan Kafka asas secara percuma!

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

Adalah baik untuk menambah semua ini dengan pemantauan pelanggan (metrik pada pengguna dan pengeluar), serta pemantauan kependaman (untuk ini terdapat Burrow) dan pemantauan hujung ke hujung - untuk kegunaan ini Pemantau Kafka.

Pembalakan

Pembalakan adalah satu lagi tugas kritikal. Pastikan semua bekas dalam pemasangan Kafka anda dilog masuk stdout и stderr, dan juga memastikan bahawa kluster Kubernetes anda mengagregatkan semua log masuk ke dalam infrastruktur pembalakan pusat, mis. Elasticsearch.

Pemeriksaan kesihatan

Kubernetes menggunakan probe keaktifan dan kesediaan untuk memeriksa sama ada pod anda berjalan seperti biasa. Jika semakan keaktifan gagal, Kubernetes akan menghentikan bekas itu dan kemudian memulakan semula secara automatik jika dasar mula semula ditetapkan dengan sewajarnya. Jika semakan kesediaan gagal, Kubernetes mengasingkan pod daripada permintaan servis. Oleh itu, dalam kes sedemikian, campur tangan manual tidak lagi diperlukan sama sekali, yang merupakan tambahan besar.

Melancarkan kemas kini

StatefulSets menyokong kemas kini automatik: jika anda memilih strategi RollingUpdate, setiap satu di bawah Kafka akan dikemas kini secara bergilir. Dengan cara ini, masa henti boleh dikurangkan kepada sifar.

Penskalaan

Menskala gugusan Kafka bukanlah tugas yang mudah. Walau bagaimanapun, Kubernetes menjadikannya sangat mudah untuk menskalakan pod kepada bilangan replika tertentu, yang bermaksud anda boleh mentakrifkan seberapa banyak broker Kafka yang anda suka. Perkara yang paling sukar dalam kes ini ialah menugaskan semula sektor selepas meningkat atau sebelum mengecilkan. Sekali lagi, Kubernetes akan membantu anda dengan tugas ini.

Pentadbiran

Tugas yang berkaitan dengan mentadbir gugusan Kafka anda, seperti mencipta topik dan menetapkan semula sektor, boleh dilakukan menggunakan skrip shell sedia ada dengan membuka antara muka baris arahan dalam pod anda. Walau bagaimanapun, penyelesaian ini tidak begitu cantik. Strimzi menyokong pengurusan topik menggunakan pengendali yang berbeza. Terdapat sedikit ruang untuk penambahbaikan di sini.

Sandarkan dan pulihkan

Kini ketersediaan Kafka juga bergantung pada ketersediaan Kubernetes. Jika gugusan Kubernetes anda gagal, maka dalam senario kes terburuk, gugusan Kafka anda juga akan gagal. Mengikut undang-undang Murphy, ini pasti akan berlaku, dan anda akan kehilangan data. Untuk mengurangkan jenis risiko ini, miliki konsep sandaran yang baik. Anda boleh menggunakan MirrorMaker, pilihan lain ialah menggunakan S3 untuk ini, seperti yang diterangkan dalam ini jawatan dari Zalando.

Kesimpulan

Apabila bekerja dengan gugusan Kafka bersaiz kecil hingga sederhana, ia pasti berbaloi menggunakan Kubernetes kerana ia memberikan fleksibiliti tambahan dan memudahkan pengalaman pengendali. Jika anda mempunyai kependaman tidak berfungsi dan/atau keperluan pemprosesan yang sangat ketara, maka mungkin lebih baik untuk mempertimbangkan beberapa pilihan penggunaan lain.

Sumber: www.habr.com