Operator dalam Kubernetes untuk mengurus kluster pangkalan data. Vladislav Klimenko (Altinity, 2019)

Laporan ini ditumpukan kepada isu praktikal membangunkan pengendali di Kubernetes, mereka bentuk seni bina dan prinsip operasi asasnya.

Dalam bahagian pertama laporan, kami akan mempertimbangkan:

• apakah operator dalam Kubernetes dan mengapa ia diperlukan;
• bagaimana sebenarnya pengendali memudahkan pengurusan sistem yang kompleks;
• apa yang operator boleh dan apa yang operator tidak boleh.

Seterusnya, kita beralih kepada perbincangan tentang struktur dalaman pengendali. Pertimbangkan seni bina dan operasi pengendali langkah demi langkah. Mari analisa secara terperinci:

• interaksi antara pengendali dan Kubernetes;
• apakah fungsi yang dijalankan oleh pengendali dan apa yang diwakilkan kepada Kubernetes.

Pertimbangkan untuk menguruskan serpihan dan replika pangkalan data dalam Kubernetes.
Seterusnya, kami akan membincangkan isu penyimpanan data:

• cara bekerja dengan Storan Berterusan dari sudut pandangan pengendali;
• perangkap menggunakan Storan Tempatan.

Di bahagian akhir laporan, kami akan mempertimbangkan contoh praktikal aplikasi pengendali clickhouse dengan Amazon atau Perkhidmatan Awan Google. Laporan itu berdasarkan contoh pengalaman pembangunan dan operasi pengendali untuk ClickHouse.

Video:

Nama saya Vladislav Klimenko. Hari ini saya ingin bercakap tentang pengalaman kami dalam membangunkan dan mengendalikan pengendali, dan ini adalah pengendali khusus untuk menguruskan kluster pangkalan data. Sebagai contoh ClickHouse-operator untuk menguruskan kluster ClickHouse.

Mengapa kita mempunyai peluang untuk bercakap tentang pengendali dan ClickHouse?

• Kami menyokong dan membangunkan ClickHouse.
• Pada masa ini, kami cuba perlahan-lahan membuat sumbangan kami kepada pembangunan ClickHouse. Dan kami adalah yang kedua selepas Yandex dari segi jumlah perubahan yang dibuat dalam ClickHouse.
• Kami cuba membuat projek tambahan untuk ekosistem ClickHouse.

Saya ingin bercakap tentang salah satu projek ini. Ini mengenai pengendali ClickHouse untuk Kubernetes.

Dalam laporan saya, saya ingin menyentuh dua topik:

• Topik pertama ialah cara pengendali pangkalan data ClickHouse kami berfungsi di Kubernetes.
• Topik kedua ialah cara mana-mana pengendali berfungsi, iaitu cara ia berinteraksi dengan Kubernetes.

Walau bagaimanapun, kedua-dua soalan ini akan bersilang sepanjang laporan saya.

Siapa yang akan berminat untuk mendengar apa yang saya cuba katakan?

• Yang paling menarik ialah mereka yang mengeksploitasi pengendali.
• Atau bagi mereka yang ingin membuatnya sendiri untuk memahami cara ia berfungsi di dalam, cara pengendali berinteraksi dengan Kubernetes dan apakah perangkap yang mungkin muncul.

Untuk memahami dengan baik perkara yang akan kita bincangkan hari ini, adalah baik untuk mengetahui cara Kubernetes berfungsi dan mempunyai latar belakang asas dalam pengkomputeran awan.

Apa itu ClickHouse? Ini ialah pangkalan data lajur dengan khusus dalam pemprosesan dalam talian pertanyaan analisis. Dan ia adalah sumber terbuka sepenuhnya.

Dan kita hanya perlu tahu dua perkara. Anda perlu tahu bahawa ini adalah pangkalan data, jadi apa yang saya akan beritahu anda akan terpakai kepada hampir mana-mana pangkalan data. Dan hakikat bahawa skala ClickHouse DBMS dengan sangat baik, memberikan skala yang hampir linear. Oleh itu, keadaan kluster adalah keadaan semula jadi untuk ClickHouse. Dan kami paling berminat untuk membincangkan cara menyediakan kluster ClickHouse dalam Kubernetes.

Kenapa dia diperlukan di sana? Mengapa kita tidak boleh terus mengendalikannya sendiri? Dan jawapannya sebahagiannya teknikal dan sebahagian lagi organisasi.

• Dalam amalan, semakin kerap kita menghadapi situasi sedemikian apabila dalam syarikat besar hampir semua komponen sudah berada di Kubernetes. Kekalkan pangkalan data di luar.
• Dan semakin kerap soalan ditanya: "Bolehkah ia diletakkan di dalam?". Oleh itu, syarikat-syarikat besar cuba menghasilkan penyatuan maksimum pengurusan agar dapat mengurus gudang data mereka dengan cepat.
• Dan ini sangat membantu jika anda memerlukan peluang maksimum untuk mengulangi perkara yang sama di tempat baharu, iaitu kemudahalihan maksimum.

Semudah atau sukar? Ini, sudah tentu, boleh dilakukan dengan tangan. Tetapi ini tidak begitu mudah, kerana kami menambah kerumitan mengurus Kubernetes itu sendiri, tetapi pada masa yang sama butiran ClickHouse dikenakan. Dan ternyata pengagregatan sedemikian.

Dan kesemuanya ini memberikan satu set teknologi yang agak besar, yang menjadi agak sukar untuk diuruskan, kerana Kubernetes membawa isu hariannya sendiri untuk beroperasi, dan ClickHouse membawa isunya sendiri kepada operasi harian. Terutama jika kita mempunyai beberapa ClickHouses, dan kita perlu sentiasa melakukan sesuatu dengan mereka.

ClickHouse dengan konfigurasi dinamik mempunyai sejumlah besar isu yang menimbulkan beban berterusan pada DevOps:

• Apabila kita ingin menukar sesuatu dalam ClickHouse, contohnya, tambah replika, serpihan, maka kita perlu menguruskan konfigurasi.
• Kemudian tukar skema data, kerana ClickHouse mempunyai kaedah sharding tertentu. Di sana adalah perlu untuk meletakkan skema data, menyusun konfigurasi.
• Anda perlu menyediakan pemantauan.
• Koleksi log untuk serpihan baharu, untuk replika baharu.
• Jaga pemulihan.
• Dan mulakan semula.

Ini adalah kerja-kerja rutin yang saya sangat ingin memudahkan dalam operasi.

Kubernetes sendiri banyak membantu dalam operasi, tetapi pada perkara sistem asas.

Kubernetes hebat dalam memudahkan dan mengautomasikan perkara seperti:

• Pemulihan.
• Mula semula.
• Pengurusan storan.

Itu bagus, itu arah yang betul, tetapi dia benar-benar tidak berhubung dengan cara mengendalikan kluster pangkalan data.

Saya mahu lebih banyak lagi, saya mahu seluruh pangkalan data berfungsi untuk kami di Kubernetes.

Saya ingin mendapatkan sesuatu seperti butang merah ajaib yang besar yang anda tekan dan anda mempunyai kluster yang digunakan dan diselenggara sepanjang keseluruhan kitaran hayat dengan tugas harian yang perlu diselesaikan. Kelompok ClickHouse dalam Kubernetes.

Dan kami cuba membuat penyelesaian yang akan membantu memudahkan kerja. Ini ialah pengendali ClickHouse untuk Kubernetes dari Altinity.

Operator adalah program yang tugas utamanya adalah untuk mengurus program lain, iaitu, ia adalah pengurus.

Dan ia mengandungi corak tingkah laku. Anda boleh memanggilnya pengetahuan yang dikodkan tentang bidang subjek.

Dan tugas utamanya adalah untuk menjadikan hidup lebih mudah untuk DevOps dan mengurangkan pengurusan mikro supaya dia (DevOps) sudah berfikir dalam istilah peringkat tinggi, iaitu, supaya dia (DevOps) tidak mengurus mikro, supaya dia tidak mengkonfigurasi semua secara manual. butiran.

Dan hanya pengendali ialah pembantu robot yang bergelut dengan tugasan mikro dan membantu DevOps.

Mengapakah operator diperlukan? Beliau cemerlang dalam dua bidang:

• Apabila pakar ClickHouse tidak mempunyai pengalaman yang mencukupi, tetapi ia sudah diperlukan untuk mengendalikan ClickHouse, pengendali memudahkan operasi dan membolehkan anda mengendalikan kluster ClickHouse dengan konfigurasi yang agak kompleks, sambil tidak menerangkan terlalu banyak terperinci tentang cara semuanya berfungsi di dalam. . Anda hanya memberinya tugas peringkat tinggi, dan ia berfungsi.
• Dan tugas kedua di mana ia menunjukkan dirinya dengan paling baik ialah apabila perlu untuk mengautomasikan sejumlah besar tugas biasa. Mengeluarkan microtasks daripada sysadmins.

Ini paling diperlukan sama ada oleh mereka yang baru memulakan perjalanan mereka, atau oleh mereka yang perlu melakukan banyak automasi.

Apakah perbezaan antara pendekatan berasaskan operator dan sistem lain? Terdapat juga Helm. Ia juga membantu untuk memasang ClickHouse, anda boleh melukis carta helm, yang malah akan memasang keseluruhan kluster ClickHouse. Kemudian apakah perbezaan antara pengendali dan dari yang sama, sebagai contoh, Helm?

Perbezaan asas utama ialah Helm adalah mengenai pengurusan pakej, dan pengendali melangkah lebih jauh. Ini adalah sokongan kepada keseluruhan kitaran hayat. Ini bukan sahaja pemasangan, ini adalah tugas harian yang termasuk penskalaan, sharding, iaitu semua yang perlu dilakukan semasa kitaran hayat (jika perlu, kemudian penyingkiran juga) - ini semua diputuskan oleh pengendali. Ia cuba mengautomasikan dan menyediakan keseluruhan kitaran hayat perisian. Ini adalah perbezaan asasnya daripada penyelesaian lain yang dibentangkan.

Itu adalah bahagian pengenalan, mari kita teruskan.

Bagaimanakah kami membina pengendali kami? Kami cuba mendekati isu ini untuk mengurus kelompok ClickHouse sebagai sumber tunggal.

Di sini kita mempunyai data input di sebelah kiri gambar. Ini ialah YAML dengan spesifikasi kluster, yang secara klasik dihantar melalui kubectl ke Kubernetes. Di sana, pengendali kami mengambilnya, melakukan sihirnya. Dan akibatnya, kami mendapat skim sedemikian. Ini ialah pelaksanaan ClickHouse dalam Kubernetes.

Dan kemudian kita perlahan-lahan akan melihat bagaimana pengendali berfungsi, apakah tugas biasa yang boleh diselesaikan. Kami akan mempertimbangkan hanya tugas biasa, kerana kami mempunyai masa yang terhad. Dan ia tidak akan diberitahu tentang semua yang boleh diputuskan oleh pengendali.

Mari kita mulakan dari latihan. Projek kami adalah sumber terbuka sepenuhnya, jadi anda boleh melihat cara ia berfungsi pada GitHub. Dan anda boleh meneruskan dari pertimbangan, jika anda hanya mahu bermula, maka anda boleh mulakan dengan Panduan Mula Pantas.

Jika anda ingin memahami secara terperinci, maka kami cuba mengekalkan dokumentasi dalam bentuk yang lebih kurang baik.

Mari kita mulakan dengan masalah praktikal. Tugas pertama yang kita semua mahu mulakan ialah menjalankan contoh pertama entah bagaimana. Bagaimana untuk melancarkan ClickHouse dengan bantuan pengendali, tanpa mengetahui cara ia berfungsi? Kami sedang menulis manifesto, kerana semua komunikasi dengan k8s adalah komunikasi melalui manifes.

Inilah manifesto yang begitu kompleks. Apa yang telah kami serlahkan dalam warna merah itulah yang perlu kami fokuskan. Kami meminta pengendali untuk membuat kelompok bernama demo.

Buat masa ini, ini adalah contoh asas. Storan belum lagi diterangkan, tetapi kami akan kembali ke storan sedikit kemudian. Buat masa ini, kami akan memerhatikan perkembangan kluster dalam dinamik.

Kami telah mencipta manifesto ini. Kami menyalurkannya kepada pengendali kami. Dia bekerja, dia melakukan sihir.

Kami melihat konsol. Tiga komponen menarik minat - ini ialah Pod, dua Service-a, StatefulSet.

Pengendali telah bekerja, dan kita boleh melihat apa sebenarnya yang dia cipta.

Dia mencipta sesuatu seperti ini. Kami mempunyai StatefulSet, Pod, ConfigMap untuk setiap replika, ConfigMap untuk keseluruhan kluster. Semestinya perkhidmatan sebagai pintu masuk ke kluster.

Perkhidmatan ialah Perkhidmatan Pengimbang Beban pusat dan juga boleh digunakan untuk setiap replika, untuk setiap serpihan.

Inilah kluster asas kami kelihatan seperti ini. Dia berasal dari satu nod.

Mari kita pergi lebih jauh, kita akan merumitkan. Anda perlu memecahkan kluster.

Tugas kami semakin meningkat, dinamik bermula. Kami mahu menambah serpihan. Kita ikuti perkembangan. Kami menukar spesifikasi kami. Kami menunjukkan bahawa kami mahu dua serpihan.

Ini adalah fail yang sama yang kami bangunkan secara dinamik dengan pertumbuhan sistem. Tiada storan, storan akan dibincangkan lebih lanjut, ini adalah isu yang berasingan.

Kami memberi makan kepada pengendali YAML dan melihat apa yang berlaku.

Pengendali berfikir dan membuat entiti berikut. Kami sudah mempunyai dua Pod, tiga Perkhidmatan dan, tiba-tiba, 2 StatefulSets. Mengapa 2 StatefulSets?

Ia seperti ini pada rajah - ini adalah keadaan awal kami, apabila kami mempunyai satu pod.

Ia menjadi seperti ini. Setakat ini, semuanya mudah, ia telah ditiru.

Dan kenapa StatefulSet menjadi dua? Di sini kita perlu menyimpang dan membincangkan persoalan bagaimana Pod diurus dalam Kubernetes.

Terdapat objek sedemikian yang dipanggil StatefulSet, yang membolehkan anda membuat satu set Pod daripada templat. Faktor utama di sini ialah Templat. Dan anda boleh menjalankan banyak Pod dalam satu StatefulSet mengikut satu templat. Dan frasa utama di sini ialah "satu templat banyak Pod".

Dan terdapat godaan hebat untuk membuat keseluruhan kluster, membungkusnya ke dalam satu StatefulSet. Ia akan berfungsi, tidak ada masalah di dalamnya. Tetapi ada satu kaveat. Jika kami ingin memasang kluster heterogen, iaitu daripada beberapa versi ClickHouse, maka soalan kami bermula. Ya, StatefulSet boleh melakukan kemas kini bergulir, tetapi di sana anda boleh melancarkan versi baharu, terangkan bahawa anda perlu mencuba tidak lebih daripada begitu banyak nod pada masa yang sama.

Tetapi jika kita mengekstrapolasi tugas dan mengatakan bahawa kita mahu membuat kluster heterogen sepenuhnya dan tidak mahu menukar daripada versi lama kepada versi baharu menggunakan kemas kini bergulir, tetapi hanya mahu mencipta kluster heterogen kedua-duanya dari segi versi berbeza daripada ClickHouse dan dari segi storan yang berbeza. Kami mahu, sebagai contoh, untuk membuat beberapa replika pada cakera berasingan, pada cakera yang perlahan, secara amnya, untuk membina gugusan heterogen sepenuhnya. Dan disebabkan fakta bahawa StatefulSet membuat penyelesaian piawai daripada satu templat, jadi tidak ada cara untuk melakukan ini.

Selepas beberapa pemikiran, telah diputuskan bahawa kami melakukan seperti ini. Kami mempunyai setiap replika dalam StatefulSet sendiri. Terdapat beberapa kelemahan untuk penyelesaian ini, tetapi dalam praktiknya, semuanya merangkumi pengendali sepenuhnya. Dan terdapat banyak faedah. Kita boleh membina gugusan sepenuhnya seperti yang kita mahu, sebagai contoh, yang benar-benar heterogen. Oleh itu, dalam kelompok di mana kita mempunyai dua serpihan dengan satu replika, kita akan mempunyai 2 StatefulSets dan 2 Pod dengan tepat kerana kami memilih pendekatan ini disebabkan oleh sebab di atas untuk keupayaan untuk membina gugusan heterogen.

Mari kita kembali kepada tugas praktikal. Dalam kelompok kami, kami perlu mengkonfigurasi pengguna, i.e. anda perlu melakukan beberapa konfigurasi ClickHouse dalam Kubernetes. Pengendali menyediakan semua kemungkinan untuk ini.

Kita boleh menulis apa yang kita mahu terus dalam YAML. Semua pilihan konfigurasi dipetakan terus daripada YAML ini ke dalam konfigurasi ClickHouse, yang kemudiannya digunakan di seluruh kluster.

Anda juga boleh menulis seperti ini. Ini bagi contoh. Kata laluan boleh disulitkan. Benar-benar semua pilihan konfigurasi ClickHouse disokong. Ini hanya contoh.

Konfigurasi kluster diedarkan sebagai ConfigMap. Dalam amalan, kemas kini ConfigMap tidak berlaku serta-merta, jadi jika terdapat kelompok besar, maka proses menolak konfigurasi mengambil sedikit masa. Tetapi semua ini sangat mudah digunakan.

Kami merumitkan tugas. Kluster sedang berkembang. Kami mahu meniru data. Iaitu, kami sudah mempunyai dua serpihan, satu replika setiap satu, pengguna dikonfigurasikan. Kami sedang berkembang dan mahu meniru.

Apa yang kita perlukan untuk replikasi?

Kami memerlukan ZooKeeper. Dalam ClickHouse, replikasi dibina menggunakan ZooKeeper. ZooKeeper diperlukan supaya replika ClickHouse yang berbeza mempunyai kata sepakat tentang blok data yang mana ClickHouse.

ZooKeeper boleh digunakan oleh sesiapa sahaja. Jika perusahaan mempunyai ZooKeeper luaran, maka ia boleh digunakan. Jika tidak, maka anda boleh memasang dari repositori kami. Terdapat pemasang yang menjadikan semuanya lebih mudah.

Dan skema interaksi seluruh sistem ternyata seperti ini. Kami mempunyai Kubernetes sebagai platform. Ia melaksanakan pengendali ClickHouse. ZooKeeper yang saya gambarkan di sini. Dan pengendali berinteraksi dengan ClickHouse dan ZooKeeper. Iaitu, interaksi diperolehi.

Dan semua ini diperlukan untuk ClickHouse berjaya mereplikasi data kepada k8s.

Sekarang mari kita lihat tugas itu sendiri, bagaimana rupa manifes untuk replikasi.

Kami menambah dua bahagian pada manifes kami. Yang pertama ialah tempat untuk mendapatkan ZooKeeper, yang boleh berada di dalam Kubernetes atau luaran. Ini hanyalah penerangan. Dan kami menempah replika. Itu. kami mahu dua replika. Secara keseluruhan, kita sepatutnya mempunyai 4 buah pada output. Kami ingat tentang penyimpanan, ia akan kembali lebih jauh. Storan ialah lagu yang berasingan.

Ia adalah seperti ini.

Ia menjadi seperti ini. Replika ditambah. Yang ke-4 tidak sesuai, kami percaya bahawa mungkin terdapat banyak daripada mereka. Dan ZooKeeper ditambah di sebelah. Coraknya semakin kompleks.

Dan sudah tiba masanya untuk menambah tugas seterusnya. Kami akan menambah Storan Berterusan.

Untuk Storan Berterusan, kami mempunyai pelbagai pilihan.

Jika kita berjalan dalam penyedia awan, contohnya, menggunakan Amazon, Google, maka terdapat godaan yang hebat untuk menggunakan storan awan. Ia sangat mudah, ia bagus.

Dan ada pilihan kedua. Ini adalah untuk storan tempatan, apabila kita mempunyai cakera tempatan pada setiap nod. Pilihan ini jauh lebih sukar untuk dilaksanakan, tetapi pada masa yang sama ia lebih produktif.

Mari lihat apa yang kita ada mengenai storan awan.

Ada kebaikan. Ia sangat mudah untuk dikonfigurasikan. Kami hanya memesan daripada pembekal awan yang tolong berikan kami storan kapasiti itu dan ini, kelas itu dan itu. Kelas dilukis oleh pembekal secara bebas.

Dan terdapat kelemahan. Bagi sesetengah orang, ini adalah kelemahan yang tidak kritikal. Sudah tentu, akan ada beberapa tindanan prestasi. Ia sangat mudah digunakan, boleh dipercayai, tetapi terdapat beberapa potensi penurunan dalam prestasi.

Dan sejak ClickHouse memberi tumpuan khusus pada prestasi, anda juga boleh mengatakan bahawa ia memerah semua yang mungkin, begitu banyak pelanggan cuba memerah prestasi maksimum.

Dan untuk memanfaatkannya sepenuhnya, kami memerlukan storan tempatan.

Kubernetes menyediakan tiga abstraksi untuk menggunakan storan tempatan dalam Kubernetes. ini:

• EmptyDir
• HostPath.
• Tempatan

Pertimbangkan bagaimana mereka berbeza, bagaimana mereka serupa.

Pertama, dalam ketiga-tiga pendekatan, kami mempunyai storan - ini adalah cakera tempatan yang terletak pada nod k8s fizikal yang sama. Tetapi mereka mempunyai beberapa perbezaan.

Mari kita mulakan dengan yang paling mudah, iaitu kosongDir. Apakah ia dalam amalan? Kamilah yang meminta sistem kontena (paling kerap Docker) daripada spesifikasi kami untuk memberikan kami akses kepada folder pada cakera tempatan.

Dalam amalan, docker di suatu tempat dalam laluannya sendiri mencipta folder sementara, memanggilnya cincang panjang. Dan menyediakan antara muka untuk mengaksesnya.

Bagaimanakah prestasinya dari segi prestasi? Ini akan berjalan pada kelajuan cakera tempatan, i.e. ini adalah akses penuh kepada skru anda.

Tetapi kes ini mempunyai kelemahannya. Berterusan dalam kes ini agak meragukan. Pada pergerakan pertama docker dengan bekas, Persistent hilang. Jika Kubernetes mahu mengalihkan Pod ini ke cakera lain atas sebab tertentu, maka data akan hilang.

Pendekatan ini bagus untuk ujian, kerana ia sudah menunjukkan kelajuan biasa, tetapi pilihan ini tidak sesuai untuk sesuatu yang serius.

Oleh itu, terdapat pendekatan kedua. Ini adalah hostPath. Jika anda melihat pada slaid sebelumnya dan yang ini, anda boleh melihat hanya satu perbezaan. Folder kami meninggalkan docker terus ke nod Kubernetes. Ia lebih cepat sedikit di sini. Kami terus menulis laluan pada sistem fail tempatan di mana kami ingin menyimpan data kami.

Kaedah ini mempunyai kelebihan. Ini sudah menjadi Persistent sebenar, dan klasik. Pada cakera kami, data akan ditulis ke beberapa alamat.

Terdapat juga keburukan. Inilah kerumitan pengurusan. Kubernetes kami mungkin mahu mengalihkan Pod ke nod fizikal lain. Di sinilah DevOps berperanan. Ia mesti menerangkan dengan betul kepada keseluruhan sistem bahawa anda hanya boleh mengalihkan pod ini ke nod yang mana anda mempunyai sesuatu yang dipasang di sepanjang laluan ini, dan tidak lebih daripada satu nod pada satu masa. Ia cukup sukar.

Terutama untuk tujuan ini, kami telah membuat templat dalam operator kami untuk menyembunyikan semua kerumitan ini. Dan anda hanya boleh berkata: "Saya mahu mempunyai satu contoh ClickHouse setiap nod fizikal dan sepanjang laluan itu dan itu."

Tetapi keperluan ini bukan sahaja untuk kami, jadi tuan-tuan dari Kubernetes sendiri juga memahami bahawa orang ingin mempunyai akses kepada cakera fizikal, jadi mereka menyediakan tahap ketiga.

Ia dipanggil tempatan. Boleh dikatakan tiada perbezaan dari slaid sebelumnya. Hanya sebelum ini adalah perlu untuk melaksanakan dengan tangan bahawa kita tidak boleh memindahkan pod ini dari nod ke nod, kerana ia mesti dilampirkan di sepanjang laluan itu dan itu ke cakera fizikal tempatan, dan kini semua pengetahuan ini terkandung dalam Kubernetes sendiri. Dan ternyata lebih mudah untuk dikonfigurasikan.

Mari kita kembali kepada tugas praktikal kita. Mari kembali kepada templat YAML. Di sini kita mempunyai storan sebenar. Kami kembali kepada ini. Kami menetapkan templat VolumeClaim klasik seperti dalam k8s. Dan kami menerangkan jenis storan yang kami mahukan.

Selepas itu, k8s akan meminta penyimpanan. Peruntukkannya kepada kami dalam StatefulSet. Dan pada akhirnya, ia akan menjadi pada pelupusan ClickHouse.

Kami mempunyai skim sedemikian. Penyimpanan Gigih kami berwarna merah, yang seolah-olah membayangkan bahawa ia harus dilakukan.

Dan ia bertukar menjadi hijau. Kini skim kluster ClickHouse pada k8s telah dimuktamadkan sepenuhnya. Kami mempunyai serpihan, replika, ZooKeeper, kami mempunyai Persistent sebenar, yang dilaksanakan dalam satu cara atau yang lain. Skim ini telah pun beroperasi sepenuhnya.

Kita teruskan hidup. Kelompok kami semakin berkembang. Dan Aleksey sedang mencuba dan mengeluarkan versi baharu ClickHouse.

Satu tugas praktikal timbul - untuk menguji versi baharu ClickHouse pada kluster kami. Dan, sudah tentu, saya tidak mahu melancarkan semuanya, saya mahu meletakkan versi baharu di suatu tempat di sudut jauh dalam satu replika, atau mungkin bukan satu versi baharu, tetapi dua sekaligus, kerana ia sering keluar.

Apa yang boleh kita katakan tentang ini?

Di sini kita mempunyai peluang sedemikian. Ini adalah templat pod. Anda boleh melukis, pengendali kami benar-benar membenarkan anda membina kelompok heterogen. Itu. konfigurasikan, bermula dari semua replika dalam sekumpulan, berakhir dengan setiap replika peribadi, versi mana yang kita mahu ClickHouse, versi mana yang kita mahu storan. Kami boleh mengkonfigurasi kluster sepenuhnya dalam konfigurasi seperti yang kami perlukan.

Mari kita pergi lebih dalam sedikit. Sebelum itu, kami bercakap tentang bagaimana ClickHouse-operator berfungsi berhubung dengan spesifik ClickHouse.

Sekarang saya ingin mengatakan beberapa perkataan tentang cara mana-mana pengendali berfungsi secara umum, serta cara ia berinteraksi dengan K8s.

Pertimbangkan interaksi dengan K8 untuk bermula. Apa yang berlaku apabila kita menggunakan kubectl? Melalui API, objek kami muncul dalam etcd.

Contohnya, objek Kubernetes asas: pod, StatefulSet, perkhidmatan dan sebagainya melalui senarai.

Walau bagaimanapun, tiada apa-apa fizikal yang berlaku. Objek ini mesti diwujudkan dalam kelompok.

Di sinilah pengawal masuk. Pengawal adalah komponen k8s khas yang boleh merealisasikan penerangan ini. Dia tahu bagaimana dan apa yang perlu dilakukan secara fizikal. Dia tahu cara menjalankan kontena, apa yang perlu dikonfigurasikan di sana agar pelayan berfungsi.

Dan ia merealisasikan objek kami dalam K8s.

Tetapi kami mahu beroperasi bukan sahaja dengan pod, StatefulSets, kami mahu mencipta ClickHouseInstallation, iaitu, objek jenis ClickHouse, untuk beroperasi dengannya secara keseluruhan. Setakat ini, tidak ada kemungkinan sedemikian.

Tetapi K8s mempunyai satu lagi perkara yang bagus. Kami mahu kami mempunyai entiti yang begitu kompleks di suatu tempat, di mana kluster kami akan dipasang daripada pod dan StatefulSet.

Dan apa yang perlu dilakukan untuk ini? Pertama, Definisi Sumber Tersuai memasuki tempat kejadian. Apa ini? Ini ialah perihalan untuk K8 yang anda akan mempunyai satu lagi jenis data yang ingin kami tambahkan pada pod, StatefulSet, sumber tersuai yang akan menjadi kompleks di dalamnya. Ini ialah penerangan tentang struktur data.

Kami juga menghantarnya ke sana melalui kubectl apply. Kubernetes dengan gembira menerimanya.

Dan kini dalam storan kami, objek dalam etcd mempunyai peluang untuk merekodkan sumber tersuai yang dipanggil ClickHouseInstallation.

Tetapi buat masa ini, tiada perkara lain yang akan berlaku. Iaitu, jika kita kini mencipta fail YAML yang kita pertimbangkan dengan perihalan serpihan, replika dan sebut "kubectl apply", maka Kubernetes akan menerimanya, memasukkannya ke dalam etcd dan berkata: "Bagus, tetapi saya tidak tahu apa yang perlu dilakukan dengannya. Saya tidak tahu bagaimana untuk mengekalkan ClickHouseInstallation."

Sehubungan itu, kami memerlukan seseorang untuk membantu Kubernetes menyediakan jenis data baharu. Di sebelah kiri, kami mempunyai pengawal Kubernetes stok yang berfungsi dengan jenis data stok. Dan di sebelah kanan, kita harus mempunyai pengawal tersuai yang boleh berfungsi dengan jenis data tersuai.

Dan dengan cara lain ia dipanggil operator. Saya secara khusus mengeluarkannya di sini untuk Kubernetes, kerana ia juga boleh dilaksanakan di luar K8. Selalunya, sudah tentu, semua kenyataan dilaksanakan dalam Kubernetes, tetapi tiada apa yang menghalangnya daripada berdiri di luar, jadi di sini ia dibawa keluar khas.

Dan, pada gilirannya, pengawal tersuai, juga dikenali sebagai pengendali, berinteraksi dengan Kubernetes melalui API. Dia sudah tahu cara berinteraksi dengan API. Dan dia sudah tahu bagaimana untuk merealisasikan skim kompleks yang kita mahu buat daripada sumber tersuai. Inilah yang dilakukan oleh pengendali.

Bagaimanakah pengendali berfungsi? Mari kita lihat di sebelah kanan untuk melihat bagaimana dia melakukannya. Kami akan mengetahui bagaimana pengendali merealisasikan semua ini dan bagaimana interaksi selanjutnya dengan K8s berlaku.

Pengendali adalah program. Dia berorientasikan acara. Operator melanggan acara menggunakan API Kubernetes. API Kubernetes mempunyai pintu masuk tempat anda boleh melanggan acara. Dan jika sesuatu berubah dalam K8, maka Kubernetes menghantar acara kepada semua orang, i.e. yang melanggan mata API ini akan menerima pemberitahuan.

Pengendali melanggan acara, dan mesti melakukan beberapa jenis reaksi. Tugasnya adalah untuk bertindak balas terhadap peristiwa baru muncul.

Acara dijana oleh beberapa kemas kini. Fail YAML kami tiba dengan penerangan ClickHouseInstallation. Dia pergi ke etcd melalui kubectl apply. Satu acara bekerja di sana, sebagai hasilnya, acara ini datang ke ClickHouse-operator. Operator menerima penerangan ini. Dan dia perlu melakukan sesuatu. Jika kemas kini datang ke objek ClickHouseInstallation, maka anda perlu mengemas kini kluster. Dan tugas pengendali adalah untuk mengemas kini kluster.

Apa yang dia buat? Pertama, kami perlu merangka pelan tindakan untuk perkara yang akan kami lakukan dengan kemas kini ini. Kemas kini boleh menjadi sangat kecil, iaitu. kecil dalam pelaksanaan YAML, tetapi boleh membawa kepada perubahan yang sangat besar pada kelompok. Oleh itu, pengendali mencipta rancangan, dan kemudian dia mematuhinya.

Dia mula, mengikut rancangan ini, untuk merebus struktur ini di dalam untuk merealisasikan pod, perkhidmatan, i.e. untuk melakukan apa tugas utamanya. Ia seperti membina kluster ClickHouse dalam Kubernetes.

Sekarang mari kita sentuh perkara yang begitu menarik. Ini adalah pembahagian tanggungjawab antara Kubernetes dan pengendali, i.e. perkara yang Kubernetes lakukan, perkara yang dilakukan oleh pengendali dan cara mereka berinteraksi antara satu sama lain.

Kubernetes bertanggungjawab untuk perkara sistem, i.e. untuk set asas objek yang boleh ditafsirkan sebagai skop sistem. Kubernetes tahu cara memulakan pod, cara memulakan semula bekas, cara melakukan volum pelekap, cara bekerja dengan ConfigMap, i.e. apa sahaja yang boleh dipanggil sistem.

Operator beroperasi dalam bidang subjek. Setiap operator dibuat untuk bidang subjeknya sendiri. Kami melakukannya untuk ClickHouse.

Dan pengendali berinteraksi dengan tepat dari segi kawasan subjek, seperti menambah replika, membuat skema, menyediakan pemantauan. Terdapat perpisahan sedemikian.

Mari kita lihat contoh praktikal bagaimana pembahagian tanggungjawab ini berlaku apabila kita melakukan tindakan replika tambah.

Tugas datang kepada pengendali - untuk menambah replika. Apakah yang sedang dilakukan oleh pengendali? Pengendali akan mengira bahawa adalah perlu untuk membuat StatefulSet baharu, di mana ia perlu untuk menerangkan templat tersebut dan itu, tuntutan volum.

Dia menyediakan semuanya dan menyerahkannya kepada K8. Dia mengatakan bahawa dia memerlukan ConfigMap, StatefulSet, Volume. Kubernetes sedang berfungsi. Dia merealisasikan unit asas yang digunakannya.

Dan kemudian ClickHouse-operator mula bermain semula. Dia sudah mempunyai pod fizikal di mana anda sudah boleh melakukan sesuatu. Dan ClickHouse-operator sekali lagi berfungsi dari segi kawasan subjek. Itu. Khususnya, ClickHouse, untuk memasukkan replika dalam kelompok, anda mesti, pertama sekali, mengkonfigurasi skema data yang wujud dalam kelompok ini. Dan, kedua, teguran ini mesti dimasukkan dalam pemantauan supaya dapat dikesan dengan jelas. Pengendali sudah menyediakannya.

Dan hanya selepas itu ClickHouse sendiri mula bermain, i.e. satu lagi entiti peringkat lebih tinggi. Ia sudah menjadi pangkalan data. Ia mempunyai contoh sendiri, replika yang dikonfigurasikan seterusnya, yang sedia untuk menyertai kluster.

Ternyata rantaian pelaksanaan dan pemisahan tanggungjawab apabila menambah replika cukup panjang.

Kami meneruskan tugas praktikal kami. Jika kluster sudah wujud, maka anda boleh memindahkan konfigurasi.

Kami membuatnya supaya boleh masuk ke dalam xml sedia ada, yang difahami oleh ClickHouse.

Anda boleh memperhalusi ClickHouse. Hanya penempatan zon adalah perkara yang saya bincangkan semasa menerangkan hostPath, storan tempatan. Beginilah cara melakukan penempatan berzon dengan betul.

Tugas praktikal seterusnya ialah pemantauan.

Jika kluster kami berubah, maka kami perlu mengkonfigurasi pemantauan secara berkala.

Mari kita lihat gambar rajah. Kami telah mempertimbangkan anak panah hijau di sini. Sekarang mari kita lihat anak panah merah. Ini adalah cara kami mahu memantau kluster kami. Bagaimana metrik daripada kluster ClickHouse masuk ke Prometheus, dan kemudian ke Grafana.

Apakah masalah dengan pemantauan? Mengapa ini dibentangkan sebagai sejenis pencapaian? Kesukarannya terletak pada dinamik. Apabila kita mempunyai satu kluster dan ia adalah statik, maka anda boleh menyediakan pemantauan sekali dan tidak mengganggu lagi.

Tetapi jika kita mempunyai banyak kluster, atau sesuatu yang sentiasa berubah, maka prosesnya adalah dinamik. Dan sentiasa mengkonfigurasi semula pemantauan adalah pembaziran sumber dan masa; walaupun hanya malas. Ini perlu diautomatikkan. Kesukaran adalah dalam dinamik proses. Dan pengendali mengautomasikan ini dengan baik.

Bagaimanakah kluster kami berkembang? Pada mulanya dia memang begitu.

Lepas tu dia jadi macam ni.

Akhirnya dia jadi macam ni.

Dan pemantauan secara automatik dilakukan oleh pengendali. Satu titik kemasukan.

Dan kami hanya melihat pintu keluar dalam papan pemuka Grafana, bagaimana hayat kluster kami mendidih di dalamnya.

Dengan cara ini, papan pemuka Grafana juga diedarkan dengan pengendali kami terus dalam kod sumber. Anda boleh menyambung dan menggunakan. Tangkapan skrin ini diberikan kepada saya oleh DevOps kami.

Ke mana kita mahu pergi seterusnya? ini:

• Membangunkan automasi ujian. Tugas utama ialah ujian automatik versi baharu.
• Kami juga benar-benar mahu mengautomasikan penyepaduan dengan ZooKeeper. Dan merancang untuk berintegrasi dengan ZooKeeper-operator. Itu. pengendali telah ditulis untuk ZooKeeper, dan adalah logik bahawa kedua-dua operator mula berintegrasi untuk membina penyelesaian yang lebih mudah.
• Kami mahu melakukan pemeriksaan kehidupan yang lebih kompleks.
• Saya menyerlahkan dalam warna hijau bahawa kami mempunyai warisan Templat dalam perjalanan - SELESAI, iaitu dengan keluaran pengendali seterusnya, kami akan mempunyai warisan templat. Ini ialah alat berkuasa yang membolehkan anda membina konfigurasi kompleks daripada kepingan.
• Dan kami mahu mengautomasikan tugas yang kompleks. Yang utama ialah Re-sharding.

Mari kita lakukan beberapa keputusan pertengahan.

Apa yang kita dapat sebagai hasilnya? Dan adakah ia berbaloi atau tidak? Adakah saya perlu cuba menyeret pangkalan data ke dalam Kubernetes dan menggunakan pengendali secara umum dan pengendali Alitnity khususnya.

Pada output kita dapat:

• Permudahkan dan automatikkan konfigurasi, penggunaan dan penyelenggaraan secara dramatik.
• Pemantauan terbina dalam serta-merta.
• Dan templat dikodkan sedia untuk digunakan untuk situasi yang kompleks. Sudah tindakan jenis menambah replika tidak perlu dilakukan dengan tangan. Ini dilakukan oleh pengendali.

Hanya tinggal soalan terakhir. Kami sudah mempunyai pangkalan data dalam Kubernetes, virtualisasi. Bagaimana pula dengan prestasi penyelesaian sedemikian, terutamanya sejak ClickHouse dioptimumkan untuk prestasi?

Jawapannya semuanya baik-baik saja! Saya tidak akan menerangkan secara terperinci, ini adalah topik laporan yang berasingan.

Tetapi terdapat projek seperti TSBS. Apakah tugas utamanya? Ini adalah ujian prestasi pangkalan data. Ini adalah percubaan untuk membandingkan hangat dengan hangat, lembut dengan lembut.

Bagaimana dia bekerja? Satu set data dihasilkan. Kemudian set data ini pada set ujian yang sama dijalankan pada pangkalan data yang berbeza. Dan setiap pangkalan data menyelesaikan satu masalah dengan cara yang boleh. Dan kemudian anda boleh membandingkan hasilnya.

Ia sudah menyokong sekumpulan besar pangkalan data. Saya telah mengenal pasti tiga yang utama. ini:

• berskala masab.
• InfluxDB.
• clickhouse.

Perbandingan juga dibuat dengan penyelesaian lain yang serupa. Perbandingan dengan RedShift. Perbandingan dibuat di Amazon. ClickHouse juga mendahului semua orang dalam hal ini.

Apakah kesimpulan yang boleh dibuat daripada apa yang saya katakan?

• DB dalam Kubernetes adalah mungkin. Mungkin, anda boleh melakukan apa sahaja, tetapi secara umum ia kelihatan seperti anda boleh. ClickHouse dalam Kubernetes pasti boleh dilakukan dengan bantuan pengendali kami.
• Pengendali membantu mengautomasikan proses dan benar-benar memudahkan kehidupan.
• Prestasi adalah perkara biasa.
• Dan, nampaknya kepada kami ia boleh dan harus digunakan.

Sumber terbuka - sertai kami!

Seperti yang saya katakan, pengendali adalah produk sumber terbuka sepenuhnya, jadi ia akan menjadi sangat baik jika bilangan maksimum orang menggunakannya. Sertai sekarang! Kami menunggu anda semua!

Terima kasih kepada semua!

soalan

Terima kasih atas laporan itu! Nama saya Anton. Saya dari SEMrush. Saya tertanya-tanya apa yang berlaku dengan pembalakan. Kami mendengar tentang pemantauan, tetapi tiada apa-apa tentang pembalakan, jika kita bercakap tentang keseluruhan kluster. Sebagai contoh, kami mempunyai kluster pada perkakasan. Dan kami menggunakan pembalakan berpusat, kami mengumpulnya dalam timbunan biasa dengan cara standard. Dan kemudian dari situ kami mendapat data yang menarik kepada kami.

Soalan yang baik, iaitu log masuk senarai tugasan. Pengendali kami belum mengautomasikannya lagi. Ia masih membangun, projek itu masih agak muda. Kami memahami keperluan pembalakan. Ini juga merupakan topik yang sangat penting. Dan ia mungkin tidak kurang penting daripada pemantauan. Tetapi yang pertama dalam senarai untuk pelaksanaan adalah pemantauan. Akan ada pembalakan. Sememangnya, kami cuba mengautomasikan semua aspek kehidupan kluster. Oleh itu, jawapannya ialah pada masa ini pengendali, malangnya, tidak tahu bagaimana untuk melakukan ini, tetapi ia adalah dalam rancangan, kami akan melakukannya. Jika anda ingin menyertai, kemudian tarik permintaan, sila.

hello! Terima kasih atas laporan itu! Saya mempunyai soalan standard yang berkaitan dengan Jilid Berterusan. Apabila kita mencipta konfigurasi dengan pengendali ini, bagaimanakah pengendali menentukan pada nod mana kita mempunyai beberapa cakera atau folder? Kita mesti terlebih dahulu menerangkan kepadanya bahawa, sila, letakkan ClickHouse kami tepat pada nod yang mempunyai cakera ini?

Setakat yang saya faham, soalan ini adalah kesinambungan storan tempatan, terutamanya bahagian hostPath daripadanya. Ia seperti menerangkan kepada keseluruhan sistem bahawa pod itu perlu dilancarkan tepat pada nod ini dan itu, di mana kita mempunyai cakera bersambung fizikal, yang dipasang pada laluan itu dan itu. Ini adalah keseluruhan bahagian yang saya sentuh sangat dangkal, kerana jawapan di sana agak besar.

Secara ringkas, ia kelihatan seperti ini. Sudah tentu, kita perlu membuat peruntukan bagi jilid ini. Pada masa ini, tiada peruntukan dinamik dalam storan tempatan, jadi DevOps mesti memotong cakera itu sendiri, berikut ialah volum ini. Dan mereka mesti menerangkan peruntukan Kubernetes, bahawa anda akan mempunyai volum Gigih kelas ini dan itu, yang terletak pada nod ini dan itu. Kemudian adalah perlu untuk menerangkan kepada Kubernetes bahawa pod yang memerlukan kelas storan tempatan sedemikian dan sedemikian perlu dijadualkan mengikut label hanya untuk nod ini dan itu. Untuk tujuan ini, pengendali mempunyai keupayaan untuk menetapkan beberapa jenis label dan satu bagi setiap contoh hos. Dan ternyata pod akan dihalakan oleh Kubernetes untuk dijalankan hanya pada nod yang memenuhi keperluan, label, secara ringkas. Pentadbir memberikan label, melakukan peruntukan cakera dengan tangan. Dan kemudian ia berskala.

Dan hanya pilihan ketiga tempatan membantu untuk menjadikannya lebih mudah. Seperti yang telah saya tekankan, ini adalah kerja penalaan yang teliti, yang akhirnya membantu untuk mendapatkan prestasi maksimum.

Saya mempunyai soalan kedua berkaitan dengan ini. Kubernetes direka bentuk sedemikian rupa sehingga tidak penting bagi kami sama ada kami kehilangan nod atau tidak. Apakah yang perlu kita lakukan dalam kes ini jika kita telah kehilangan nod tempat serpihan kita digantung?

Ya, Kubernetes pada asalnya meletakkan bahawa hubungan kami dengan pod kami adalah seperti lembu, tetapi di sini setiap cakera menjadi sesuatu seperti haiwan peliharaan. Terdapat masalah sedemikian sehingga kita tidak boleh membuangnya begitu sahaja. Dan pembangunan Kubernetes menuju ke arah yang mustahil untuk memperlakukannya sepenuhnya secara falsafah, sebagai sumber yang dibuang sepenuhnya.

Sekarang soalan praktikal. Apa yang perlu dilakukan jika anda kehilangan nod di mana cakera itu berada? Di sini masalah diselesaikan pada tahap yang lebih tinggi. Dalam kes ClickHouse, kami mempunyai replika yang berfungsi pada tahap yang lebih tinggi, i.e. di peringkat ClickHouse.

Apakah perwatakan? DevOps bertanggungjawab untuk memastikan data tidak hilang. Ia mesti menyediakan replikasi dengan betul dan mesti memastikan replikasi berjalan. Dalam replika di peringkat ClickHouse, data mesti diduplikasi. Ini bukan tugas yang diselesaikan oleh pengendali. Dan bukan tugas yang Kubernetes sendiri selesaikan. Ini di peringkat ClickHouse.

Apa yang perlu dilakukan jika nod besi anda telah jatuh? Dan ternyata perlu meletakkan yang kedua, dengan betul memindahkan cakera di atasnya, menggunakan label. Dan selepas itu, ia akan memenuhi keperluan yang Kubernetes padanya boleh menjalankan contoh pod. Kubernetes akan melancarkannya. Bilangan pod anda tidak mencukupi untuk yang ditentukan. Ia akan melalui kitaran yang saya tunjukkan. Dan pada peringkat tertinggi, ClickHouse akan memahami bahawa kami mempunyai replika yang dimasukkan, ia masih kosong dan kami perlu mula memindahkan data kepadanya. Itu. proses ini masih kurang automatik.

Terima kasih atas laporan itu! Apabila pelbagai perkara buruk berlaku, pengendali ranap dan dimulakan semula, dan pada masa itu peristiwa tiba, adakah anda memproses perkara ini?

Apakah yang berlaku jika pengendali ranap dan dimulakan semula, ya?

ya. Dan pada saat itu peristiwa datang.

Tugas apa yang perlu dilakukan dalam kes ini sebahagiannya dibahagikan antara pengendali dan Kubernetes. Kubernetes mempunyai keupayaan untuk memainkan semula peristiwa yang telah berlaku. Dia ulang tayang. Dan tugas pengendali adalah untuk memastikan bahawa apabila log peristiwa dimainkan semula padanya, peristiwa ini adalah idempoten. Dan supaya kejadian yang sama berlaku semula tidak memecahkan sistem kami untuk kami. Dan pengendali kami mengatasi tugas ini.

hello! Terima kasih atas laporan itu! Dmitry Zavialov, syarikat Smedov. Adakah ia merancang untuk menambah pilihan penyesuaian dengan haproxy kepada pengendali? Beberapa pengimbang lain adalah menarik selain yang standard, supaya ia bijak dan memahami bahawa ClickHouse adalah nyata di sana.

Adakah anda bercakap tentang Ingress?

Ya, gantikan Ingress dengan haproxy. Dalam haproxy, anda boleh menentukan topologi kluster di mana ia mempunyai replika.

Setakat ini, kami tidak memikirkannya. Jika anda memerlukannya dan boleh menjelaskan mengapa ia diperlukan, maka ia akan menjadi mungkin untuk melaksanakannya, terutamanya jika anda ingin mengambil bahagian. Kami berbesar hati untuk mempertimbangkan pilihan. Jawapan ringkasnya ialah tidak, pada masa ini kami tidak mempunyai fungsi sedemikian. Terima kasih atas petua, kami akan lihat ini. Dan jika anda juga menerangkan kes penggunaan dan mengapa ia perlu dalam amalan, sebagai contoh, mencipta isu pada GitHub, maka ia akan menjadi hebat.

Sudah.

baik. Kami terbuka kepada sebarang cadangan. Dan haproxy diletakkan dalam senarai tugasan. Senarai todo semakin berkembang, belum mengecut lagi. Tetapi ini bagus, ini bermakna produk itu mendapat permintaan.

Sumber: www.habr.com