Apakah Kafka di Kubernetes bagus?

Salam, Habr!

Pada suatu waktu, kami adalah orang pertama yang memperkenalkan topik tersebut ke pasar Rusia Kafka dan lanjutkan melacak untuk pengembangannya. Secara khusus, kami menemukan topik interaksi antara Kafka dan Kubernetes. Dapat diamati (dan cukup hati-hati) artikel topik ini diterbitkan di blog Confluent pada bulan Oktober tahun lalu di bawah penulis Gwen Shapira. Hari ini kami ingin menarik perhatian Anda ke artikel terbaru bulan April oleh Johann Gyger, yang, meskipun bukan tanpa tanda tanya di judulnya, mengkaji topik tersebut dengan cara yang lebih substantif, disertai teks dengan tautan yang menarik. Mohon maafkan kami atas terjemahan gratis “chaos monkey” jika Anda bisa!

pengenalan

Kubernetes dirancang untuk menangani beban kerja tanpa kewarganegaraan. Biasanya, beban kerja seperti itu disajikan dalam bentuk arsitektur layanan mikro, ringan, dapat diskalakan dengan baik secara horizontal, mengikuti prinsip aplikasi 12 faktor, dan dapat bekerja dengan pemutus sirkuit dan monyet chaos.

Kafka, di sisi lain, pada dasarnya bertindak sebagai database terdistribusi. Jadi, saat bekerja, Anda harus berurusan dengan negara, dan ini jauh lebih berat daripada layanan mikro. Kubernetes mendukung muatan stateful, namun seperti yang ditunjukkan oleh Kelsey Hightower dalam dua tweetnya, muatan tersebut harus ditangani dengan hati-hati:

Beberapa orang merasa bahwa jika Anda memasukkan Kubernetes ke dalam beban kerja stateful, maka Kubernetes akan menjadi database yang terkelola sepenuhnya dan menyaingi RDS. Ini salah. Mungkin, jika Anda bekerja cukup keras, menambahkan komponen tambahan, dan menarik tim insinyur SRE, Anda akan mampu membangun RDS di atas Kubernetes.

Saya selalu menyarankan agar semua orang sangat berhati-hati saat menjalankan beban kerja stateful di Kubernetes. Kebanyakan orang yang bertanya “bisakah saya menjalankan beban kerja stateful di Kubernetes” tidak memiliki cukup pengalaman dengan Kubernetes, dan sering kali mereka menanyakan beban kerja tersebut.

Jadi, haruskah Anda menjalankan Kafka di Kubernetes? Pertanyaan balasan: apakah Kafka akan bekerja lebih baik tanpa Kubernetes? Itu sebabnya saya ingin menyoroti dalam artikel ini bagaimana Kafka dan Kubernetes saling melengkapi, dan kendala apa yang mungkin timbul jika menggabungkan keduanya.

Waktu penyelesaian

Mari kita bicara tentang hal mendasar - lingkungan runtime itu sendiri

proses

Broker Kafka ramah terhadap CPU. TLS mungkin menimbulkan beberapa overhead. Namun, klien Kafka mungkin lebih intensif CPU jika mereka menggunakan enkripsi, namun hal ini tidak memengaruhi broker.

ingatan

Broker Kafka memakan memori. Ukuran heap JVM biasanya dibatasi hingga 4-5 GB, namun Anda juga memerlukan banyak memori sistem karena Kafka menggunakan cache halaman dengan sangat banyak. Di Kubernetes, tetapkan sumber daya container dan batas permintaan yang sesuai.

Penyimpanan data

Penyimpanan data dalam container bersifat sementara - data hilang saat dimulai ulang. Untuk data Kafka Anda bisa menggunakan volume emptyDir, dan efeknya akan serupa: data broker Anda akan hilang setelah selesai. Pesan Anda masih dapat disimpan di broker lain sebagai replika. Oleh karena itu, setelah restart, broker yang gagal harus mereplikasi semua data terlebih dahulu, dan proses ini bisa memakan banyak waktu.

Inilah sebabnya mengapa Anda harus menggunakan penyimpanan data jangka panjang. Biarlah penyimpanan jangka panjang non-lokal dengan sistem file XFS atau, lebih tepatnya, ext4. Jangan gunakan NFS. Aku sudah memperingatkanmu. NFS versi v3 atau v4 tidak akan berfungsi. Singkatnya, broker Kafka akan crash jika tidak dapat menghapus direktori data karena masalah "ganti nama yang bodoh" di NFS. Jika saya belum meyakinkan Anda, berhati-hatilah membaca artikel ini. Penyimpanan data harus bersifat non-lokal sehingga Kubernetes dapat lebih fleksibel memilih node baru setelah restart atau relokasi.

Сеть

Seperti kebanyakan sistem terdistribusi, kinerja Kafka sangat bergantung pada menjaga latensi jaringan seminimal mungkin dan bandwidth maksimal. Jangan mencoba menghosting semua broker di node yang sama, karena ini akan mengurangi ketersediaan. Jika node Kubernetes gagal, seluruh cluster Kafka akan gagal. Selain itu, jangan menyebarkan cluster Kafka ke seluruh pusat data. Hal yang sama berlaku untuk cluster Kubernetes. Kompromi yang baik dalam hal ini adalah memilih zona ketersediaan yang berbeda.

Konfigurasi

Manifesto reguler

Situs web Kubernetes memiliki panduan yang sangat bagus tentang cara mengonfigurasi ZooKeeper menggunakan manifes. Karena ZooKeeper adalah bagian dari Kafka, ini adalah tempat yang baik untuk mulai memahami konsep Kubernetes yang diterapkan di sini. Setelah Anda memahami hal ini, Anda dapat menggunakan konsep yang sama dengan cluster Kafka.

• Bawah: Pod adalah unit terkecil yang dapat di-deploy di Kubernetes. Sebuah pod berisi beban kerja Anda, dan pod itu sendiri berhubungan dengan proses di klaster Anda. Sebuah pod berisi satu atau lebih container. Setiap server ZooKeeper dalam ansambel dan setiap broker di cluster Kafka akan berjalan di pod terpisah.
• StatefulSet: StatefulSet adalah objek Kubernetes yang menangani beberapa beban kerja stateful, dan beban kerja tersebut memerlukan koordinasi. StatefulSets memberikan jaminan mengenai pemesanan pod dan keunikannya.
• Layanan tanpa kepala: Layanan memungkinkan Anda melepaskan pod dari klien menggunakan nama logis. Kubernetes dalam hal ini bertanggung jawab atas penyeimbangan beban. Namun, saat mengoperasikan beban kerja stateful, seperti ZooKeeper dan Kafka, klien perlu berkomunikasi dengan instans tertentu. Di sinilah layanan tanpa kepala berguna: dalam hal ini, klien masih memiliki nama logis, tetapi Anda tidak perlu menghubungi pod secara langsung.
• Volume penyimpanan jangka panjang: Volume ini diperlukan untuk mengonfigurasi penyimpanan persisten blok non-lokal yang disebutkan di atas.

Pada Yolean Menyediakan serangkaian manifes yang komprehensif untuk membantu Anda memulai Kafka di Kubernetes.

Grafik helm

Helm adalah pengelola paket untuk Kubernetes yang dapat dibandingkan dengan pengelola paket OS seperti yum, apt, Homebrew, atau Chocolatey. Ini memudahkan untuk menginstal paket perangkat lunak yang telah ditentukan sebelumnya yang dijelaskan dalam bagan Helm. Bagan Helm yang dipilih dengan baik memudahkan tugas sulit tentang cara mengonfigurasi semua parameter dengan benar untuk menggunakan Kafka di Kubernetes. Ada beberapa diagram Kafka: diagram resmi berada dalam kondisi inkubator, ada satu dari Anak sungai, satu lagi - dari Bitnami.

Operator

Karena Helm memiliki kekurangan tertentu, alat lain yang mendapatkan popularitas besar: operator Kubernetes. Operator tidak hanya mengemas perangkat lunak untuk Kubernetes, tetapi juga mengizinkan Anda untuk menerapkan perangkat lunak tersebut dan mengelolanya.

Dalam daftar operator yang luar biasa Dua operator untuk Kafka disebutkan. Salah satu diantara mereka - Strimzi. Dengan Strimzi, Anda dapat dengan mudah mengaktifkan dan menjalankan kluster Kafka dalam hitungan menit. Praktis tidak diperlukan konfigurasi, selain itu, operator itu sendiri menyediakan beberapa fitur bagus, misalnya enkripsi TLS point-to-point dalam cluster. Confluent juga menyediakan operator sendiri.

Performa

Penting untuk menguji kinerja dengan melakukan tolok ukur pada instans Kafka Anda. Tes semacam itu akan membantu Anda menemukan potensi hambatan sebelum masalah muncul. Untungnya, Kafka sudah menyediakan dua alat pengujian kinerja: kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. Manfaatkan mereka secara aktif. Sebagai referensi, Anda dapat merujuk pada hasil yang dijelaskan dalam postingan ini Jay Kreps, atau fokus pada ulasan ini Amazon MSK oleh Stéphane Maarek.

Operasi

Pemantauan

Transparansi dalam sistem sangat penting - jika tidak, Anda tidak akan mengerti apa yang terjadi di dalamnya. Saat ini terdapat toolkit solid yang menyediakan pemantauan berbasis metrik dalam gaya cloud native. Dua alat populer untuk tujuan ini adalah Prometheus dan Grafana. Prometheus dapat mengumpulkan metrik dari semua proses Java (Kafka, Zookeeper, Kafka Connect) menggunakan eksportir JMX - dengan cara yang paling sederhana. Jika Anda menambahkan metrik cAdvisor, Anda dapat lebih memahami bagaimana sumber daya digunakan di Kubernetes.

Strimzi memiliki contoh dasbor Grafana yang sangat nyaman untuk Kafka. Ini memvisualisasikan metrik utama, misalnya, tentang sektor yang kurang direplikasi atau sektor yang sedang offline. Semuanya sangat jelas di sana. Metrik ini dilengkapi dengan pemanfaatan sumber daya dan informasi kinerja, serta indikator stabilitas. Jadi, Anda mendapatkan pemantauan klaster Kafka dasar secara gratis!

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

Akan lebih baik jika melengkapi semua ini dengan pemantauan klien (metrik pada konsumen dan produsen), serta pemantauan latensi (untuk ini ada Liang) dan pemantauan ujung ke ujung - untuk penggunaan ini Pemantau Kafka.

Penebangan

Pencatatan log adalah tugas penting lainnya. Pastikan semua kontainer di instalasi Kafka Anda masuk stdout и stderr, dan juga memastikan bahwa klaster Kubernetes Anda mengumpulkan semua log ke dalam infrastruktur logging pusat, misalnya. Elasticsearch.

Pengujian Fungsional

Kubernetes menggunakan pemeriksaan keaktifan dan kesiapan untuk memeriksa apakah pod Anda berjalan normal. Jika pemeriksaan keaktifan gagal, Kubernetes akan menghentikan container tersebut dan kemudian memulai ulang secara otomatis jika kebijakan mulai ulang diatur dengan tepat. Jika pemeriksaan kesiapan gagal, Kubernetes akan mengisolasi pod dari permintaan layanan. Oleh karena itu, dalam kasus seperti ini, intervensi manual tidak lagi diperlukan sama sekali, dan ini merupakan nilai tambah yang besar.

Meluncurkan pembaruan

StatefulSets mendukung pembaruan otomatis: jika Anda memilih strategi RollingUpdate, setiap pembaruan di bawah Kafka akan diperbarui secara bergantian. Dengan cara ini, downtime dapat dikurangi menjadi nol.

penskalaan

Menskalakan klaster Kafka bukanlah tugas yang mudah. Namun, Kubernetes mempermudah penskalaan pod ke sejumlah replika tertentu, yang berarti Anda dapat secara deklaratif menentukan broker Kafka sebanyak yang Anda inginkan. Hal tersulit dalam hal ini adalah menugaskan kembali sektor-sektor setelah peningkatan atau sebelum penurunan. Sekali lagi, Kubernetes akan membantu Anda dalam tugas ini.

administrasi

Tugas yang terkait dengan pengelolaan klaster Kafka Anda, seperti membuat topik dan menetapkan ulang sektor, dapat dilakukan menggunakan skrip shell yang ada dengan membuka antarmuka baris perintah di pod Anda. Namun, solusi ini tidak terlalu bagus. Strimzi mendukung pengelolaan topik menggunakan operator berbeda. Ada beberapa ruang untuk perbaikan di sini.

Cadangkan dan pulihkan

Kini ketersediaan Kafka juga akan bergantung pada ketersediaan Kubernetes. Jika klaster Kubernetes Anda gagal, dalam skenario terburuk, klaster Kafka Anda juga akan gagal. Menurut hukum Murphy, ini pasti akan terjadi dan Anda akan kehilangan data. Untuk mengurangi risiko jenis ini, milikilah konsep cadangan yang baik. Anda dapat menggunakan MirrorMaker, opsi lainnya adalah menggunakan S3 untuk ini, seperti yang dijelaskan di sini Pos dari Zalando.

Kesimpulan

Saat bekerja dengan cluster Kafka berukuran kecil hingga menengah, penggunaan Kubernetes sangat bermanfaat karena memberikan fleksibilitas tambahan dan menyederhanakan pengalaman operator. Jika Anda memiliki latensi non-fungsional dan/atau persyaratan throughput yang sangat signifikan, mungkin lebih baik mempertimbangkan beberapa opsi penerapan lainnya.

Sumber: www.habr.com