Operator di Kubernetes untuk mengelola cluster database. Vladislav Klimenko (Altinity, 2019)

Laporan ini dikhususkan untuk isu-isu praktis dalam mengembangkan operator di Kubernetes, merancang arsitektur dan prinsip-prinsip operasi dasar.

Pada bagian pertama laporan ini kami akan mempertimbangkan:

• apa itu operator di Kubernetes dan mengapa diperlukan;
• bagaimana tepatnya operator menyederhanakan pengelolaan sistem yang kompleks;
• apa yang bisa dan tidak bisa dilakukan oleh operator.

Selanjutnya, mari kita beralih ke pembahasan struktur internal operator. Mari kita lihat arsitektur dan pengoperasian operator langkah demi langkah. Mari kita lihat secara detail:

• interaksi antara operator dan Kubernetes;
• fungsi apa yang diambil oleh operator dan fungsi apa yang didelegasikannya ke Kubernetes.

Mari kita lihat pengelolaan shard dan replika database di Kubernetes.
Selanjutnya kita akan membahas masalah penyimpanan data:

• cara bekerja dengan Penyimpanan Persisten dari sudut pandang operator;
• kendala dalam menggunakan Penyimpanan Lokal.

Di bagian akhir laporan ini, kita akan membahas contoh-contoh praktis penerapannya operator clickhouse dari Amazon atau Layanan Google Cloud. Laporan ini didasarkan pada contoh pengalaman pengembangan dan pengoperasian operator ClickHouse.

Video:

Nama saya Vladislav Klimenko. Hari ini saya ingin berbicara tentang pengalaman kami dalam mengembangkan dan mengoperasikan operator, dan ini adalah operator khusus untuk mengelola cluster database. Misalnya Operator ClickHouse untuk mengelola cluster ClickHouse.

Mengapa kita mempunyai kesempatan untuk berbicara tentang operator dan ClickHouse?

• Kami mendukung dan mengembangkan ClickHouse.
• Saat ini, kami mencoba memberikan kontribusi secara perlahan terhadap pengembangan ClickHouse. Dan kami berada di urutan kedua setelah Yandex dalam hal volume perubahan yang dilakukan pada ClickHouse.
• Kami mencoba melakukan proyek tambahan untuk ekosistem ClickHouse.

Saya ingin memberi tahu Anda tentang salah satu proyek ini. Ini tentang operator ClickHouse untuk Kubernetes.

Dalam laporan saya, saya ingin menyentuh dua topik:

• Topik pertama adalah cara kerja operator manajemen database ClickHouse di Kubernetes.
• Topik kedua adalah cara kerja operator, yaitu cara operator berinteraksi dengan Kubernetes.

Namun, kedua pertanyaan ini akan bersinggungan di seluruh laporan saya.

Siapa yang tertarik mendengarkan apa yang ingin saya sampaikan?

• Ini akan sangat menarik bagi mereka yang mengoperasikan operator.
• Atau bagi yang ingin membuatnya sendiri agar dapat memahami cara kerjanya secara internal, bagaimana operator berinteraksi dengan Kubernetes, dan kendala apa saja yang mungkin muncul.

Untuk memahami dengan baik apa yang akan kita diskusikan hari ini, ada baiknya Anda mengetahui cara kerja Kubernetes dan mendapatkan beberapa pelatihan cloud dasar.

Apa itu ClickHouse? Ini adalah database kolom dengan fitur khusus untuk pemrosesan kueri analitis online. Dan ini sepenuhnya open source.

Dan penting bagi kita untuk mengetahui dua hal saja. Perlu Anda ketahui bahwa ini adalah database, jadi apa yang akan saya sampaikan kepada Anda akan berlaku untuk hampir semua database. Dan fakta bahwa DBMS ClickHouse berskala sangat baik, memberikan skalabilitas yang hampir linier. Oleh karena itu, keadaan cluster adalah keadaan alami untuk ClickHouse. Dan kami sangat tertarik membahas cara melayani cluster ClickHouse di Kubernetes.

Mengapa dia dibutuhkan di sana? Mengapa kita tidak bisa terus mengoperasikannya sendiri? Dan jawabannya sebagian bersifat teknis dan sebagian bersifat organisasional.

• Dalam praktiknya, kita semakin sering menghadapi situasi dimana di perusahaan besar hampir semua komponen sudah ada di Kubernetes. Basis data tetap berada di luar.
• Dan pertanyaan yang semakin banyak ditanyakan: “Bisakah ini ditempatkan di dalam?” Oleh karena itu, perusahaan-perusahaan besar berusaha mencapai kesatuan manajemen yang maksimal agar dapat dengan cepat mengelola data warehouse mereka.
• Dan ini sangat membantu jika Anda membutuhkan kesempatan maksimal untuk mengulangi hal yang sama di tempat baru, yaitu portabilitas maksimal.

Seberapa mudah atau sulitnya? Tentu saja ini bisa dilakukan dengan tangan. Namun hal ini tidak sesederhana itu, karena kami memiliki kerumitan tambahan dalam mengelola Kubernetes itu sendiri, namun pada saat yang sama, spesifikasi ClickHouse juga ditumpangkan. Dan hasil agregasi seperti itu.

Dan secara keseluruhan hal ini memberikan serangkaian teknologi yang cukup besar, yang menjadi sangat sulit untuk dikelola, karena Kubernetes menjalankan permasalahan sehari-harinya, dan ClickHouse membawa permasalahannya sendiri ke dalam pengoperasian sehari-hari. Terutama jika kita memiliki beberapa ClickHouse, dan kita harus terus-menerus melakukan sesuatu dengan mereka.

Dengan konfigurasi dinamis, ClickHouse memiliki sejumlah masalah yang cukup besar yang menyebabkan beban konstan pada DevOps:

• Ketika kita ingin mengubah sesuatu di ClickHouse, misalnya menambahkan replika atau shard, maka kita perlu mengatur konfigurasinya.
• Kemudian ubah skema datanya, karena ClickHouse memiliki metode sharding tertentu. Di sana Anda perlu membuat diagram data, membuat konfigurasi.
• Anda perlu mengatur pemantauan.
• Mengumpulkan log untuk pecahan baru, untuk replika baru.
• Jaga restorasi.
• Dan mulai ulang.

Ini adalah tugas rutin yang saya ingin membuatnya lebih mudah digunakan.

Kubernetes sendiri membantu dengan baik dalam pengoperasiannya, tetapi pada hal-hal sistem dasar.

Kubernetes pandai memfasilitasi dan mengotomatiskan hal-hal seperti:

• Pemulihan.
• Mengulang kembali.
• Manajemen sistem penyimpanan.

Itu bagus, itu arah yang benar, tapi dia sama sekali tidak mengerti cara mengoperasikan cluster database.

Kami menginginkan lebih, kami ingin seluruh database berfungsi di Kubernetes.

Saya ingin mendapatkan sesuatu seperti tombol merah ajaib besar yang Anda tekan dan sebuah cluster dengan tugas sehari-hari yang perlu diselesaikan disebarkan dan dipelihara sepanjang siklus hidupnya. Kluster ClickHouse di Kubernetes.

Dan kami mencoba membuat solusi yang akan membantu mempermudah pekerjaan. Ini adalah operator ClickHouse untuk Kubernetes dari Altinity.

Operator adalah suatu program yang tugas utamanya mengelola program lain, yaitu sebagai pengelola.

Dan itu berisi pola perilaku. Anda dapat menyebutnya sebagai pengetahuan terkodifikasi tentang bidang studi.

Dan tugas utamanya adalah membuat kehidupan DevOps lebih mudah dan mengurangi manajemen mikro, sehingga dia (DevOps) sudah berpikir dalam istilah tingkat tinggi, yaitu agar dia (DevOps) tidak terlibat dalam manajemen mikro, sehingga dia tidak melakukan konfigurasi. semua detail secara manual.

Dan hanya operatornya yang merupakan asisten robotik yang menangani tugas mikro dan membantu DevOps.

Mengapa Anda membutuhkan operator? Dia berkinerja sangat baik di dua bidang:

• Ketika spesialis yang menangani ClickHouse tidak memiliki cukup pengalaman, tetapi sudah perlu mengoperasikan ClickHouse, operator memfasilitasi pengoperasian dan memungkinkan Anda mengoperasikan cluster ClickHouse dengan konfigurasi yang agak rumit, tanpa menjelaskan terlalu banyak detail tentang cara kerjanya. di dalam. Anda cukup memberinya tugas tingkat tinggi, dan itu berhasil.
• Dan tugas kedua yang kinerjanya paling baik adalah ketika diperlukan untuk mengotomatisasi sejumlah besar tugas umum. Menghapus tugas mikro dari administrator sistem.

Hal ini paling dibutuhkan baik oleh mereka yang baru memulai perjalanannya, atau oleh mereka yang perlu melakukan banyak otomatisasi.

Apa perbedaan pendekatan berbasis operator dengan sistem lain? Ada Helm. Menginstal ClickHouse juga membantu; Anda dapat menggambar diagram kemudi, yang bahkan akan menginstal seluruh cluster ClickHouse. Lalu apa perbedaan antara operator dan sejenisnya, misalnya Helm?

Perbedaan mendasar utama adalah Helm adalah manajemen paket dan Operator melangkah lebih jauh. Ini adalah dukungan untuk seluruh siklus hidup. Ini bukan hanya instalasi, ini adalah tugas sehari-hari yang mencakup penskalaan, sharding, mis. segala sesuatu yang perlu dilakukan selama siklus hidup (jika perlu, maka penghapusan juga) - semuanya diputuskan oleh operator. Ia mencoba untuk mengotomatisasi dan memelihara seluruh siklus hidup perangkat lunak. Inilah perbedaan mendasarnya dari solusi lain yang disajikan.

Itu tadi bagian perkenalannya, mari kita lanjutkan.

Bagaimana kami membangun operator kami? Kami mencoba mengatasi masalah ini untuk mengelola cluster ClickHouse sebagai sumber daya tunggal.

Di sini kita memiliki input data di sisi kiri gambar. Ini adalah YAML dengan spesifikasi cluster, yang diteruskan ke Kubernetes dengan cara klasik melalui kubectl. Di sana operator kami mengambilnya dan melakukan keajaibannya. Dan pada output kita mendapatkan skema berikut. Ini adalah implementasi ClickHouse di Kubernetes.

Dan kemudian kita akan perlahan-lahan melihat bagaimana sebenarnya operator itu bekerja, tugas-tugas umum apa yang bisa diselesaikan. Kami hanya akan mempertimbangkan tugas-tugas biasa karena waktu kami terbatas. Dan tidak semua hal yang dapat diputuskan oleh operator akan dibahas.

Mari kita mulai dari latihan. Proyek kami sepenuhnya open source, sehingga Anda dapat melihat cara kerjanya di GitHub. Dan Anda dapat melanjutkan dari pertimbangan bahwa jika Anda baru ingin meluncurkannya, Anda dapat memulai dengan Panduan Memulai Cepat.

Jika ingin memahami secara detail, maka kami berusaha menjaga dokumentasinya dalam bentuk yang kurang lebih layak.

Mari kita mulai dengan masalah praktis. Tugas pertama, yang ingin kita semua mulai, adalah menjalankan contoh pertama. Bagaimana cara meluncurkan ClickHouse menggunakan operator, meskipun saya tidak begitu tahu cara kerjanya? Kami menulis manifesto, karena... Semua komunikasi dengan k8s adalah komunikasi melalui manifes.

Ini adalah sebuah manifesto yang rumit. Apa yang kami soroti dengan warna merah adalah apa yang perlu kami fokuskan. Kami meminta operator untuk membuat cluster bernama demo.

Ini adalah contoh dasar untuk saat ini. Penyimpanan belum dijelaskan, tetapi kami akan kembali ke penyimpanan nanti. Untuk saat ini kita akan mengamati dinamika perkembangan klaster tersebut.

Kami membuat manifesto ini. Kami memberikannya ke operator kami. Dia bekerja, dia membuat keajaiban.

Kami melihat konsol. Ada tiga komponen yang menarik: sebuah Pod, dua Layanan, dan sebuah StatefulSet.

Operatornya telah bekerja, dan kita dapat melihat apa sebenarnya yang dia buat.

Dia menciptakan sesuatu seperti ini. Kami memiliki StatefulSet, Pod, ConfigMap untuk setiap replika, ConfigMap untuk keseluruhan cluster. Layanan diperlukan sebagai titik masuk ke dalam cluster.

Layanan adalah Layanan Load Balancer pusat dan juga dapat digunakan untuk setiap replika, untuk setiap shard.

Cluster dasar kami terlihat seperti ini. Itu berasal dari satu node.

Mari melangkah lebih jauh dan memperumit masalah. Kita perlu memecah cluster.

Tugas kita bertambah, dinamika dimulai. Kami ingin menambahkan pecahan. Kami mengikuti perkembangannya. Kami mengubah spesifikasi kami. Kami menunjukkan bahwa kami menginginkan dua pecahan.

Ini adalah file yang sama yang berkembang secara dinamis seiring pertumbuhan sistem. Penyimpanan tidak, penyimpanan akan dibahas lebih lanjut, ini topik tersendiri.

Kami memberi makan operator YAML dan melihat apa yang terjadi.

Operator memikirkan dan membuat entitas berikut. Kita sudah memiliki dua Pod, tiga Layanan dan, tiba-tiba, 2 StatefulSet. Mengapa 2 StatefulSet?

Pada diagramnya seperti ini - ini adalah keadaan awal kami, ketika kami memiliki satu pod.

Ini menjadi seperti ini. Sejauh ini semuanya sederhana, sudah diduplikasi.

Dan mengapa ada dua StatefulSets? Di sini kita perlu menyimpang dan mendiskusikan pertanyaan tentang bagaimana Pod dikelola di Kubernetes.

Ada sebuah objek bernama StatefulSet yang memungkinkan Anda membuat sekumpulan Pod dari sebuah template. Faktor kuncinya di sini adalah Template. Dan Anda dapat meluncurkan banyak Pod menggunakan satu template dalam satu StatefulSet. Dan frase kuncinya di sini adalah “banyak Pod untuk satu template.”

Dan ada godaan besar untuk membuat keseluruhan cluster, mengemasnya menjadi satu StatefulSet. Ini akan berhasil, tidak ada masalah dengan itu. Tapi ada satu peringatan. Jika kita ingin merakit cluster yang heterogen, yaitu dari beberapa versi ClickHouse, maka pertanyaan mulai muncul. Ya, StatefulSet dapat melakukan pembaruan berkelanjutan, dan di sana Anda dapat meluncurkan versi baru, jelaskan bahwa Anda tidak perlu mencoba lebih dari banyak node pada saat yang bersamaan.

Namun jika kita mengekstrapolasi tugas dan mengatakan bahwa kita ingin membuat klaster yang benar-benar heterogen dan kita tidak ingin mengubah dari versi lama ke versi baru menggunakan pembaruan berkelanjutan, namun kita hanya ingin membuat klaster heterogen baik dari segi dari versi ClickHouse yang berbeda dan dalam hal penyimpanan yang berbeda. Kami ingin, misalnya, membuat beberapa replika pada disk terpisah, pada disk yang lambat, secara umum, untuk membangun cluster yang heterogen sepenuhnya. Dan karena StatefulSet membuat solusi standar dari satu template, tidak ada cara untuk melakukan ini.

Setelah beberapa pemikiran, diputuskan bahwa kami akan melakukannya dengan cara ini. Kami memiliki setiap replika di StatefulSetnya sendiri. Ada beberapa kelemahan pada solusi ini, namun dalam praktiknya semuanya dienkapsulasi sepenuhnya oleh operator. Dan masih banyak lagi keuntungannya. Kita dapat membangun cluster yang kita inginkan, misalnya cluster yang benar-benar heterogen. Oleh karena itu, dalam sebuah cluster di mana kita memiliki dua shard dengan satu replika, kita akan memiliki 2 StatefulSet dan 2 Pod justru karena kita memilih pendekatan ini karena alasan yang disebutkan di atas untuk dapat membangun cluster yang heterogen.

Mari kita kembali ke masalah praktis. Di cluster kami, kami perlu mengkonfigurasi pengguna, mis. Anda perlu melakukan beberapa konfigurasi ClickHouse di Kubernetes. Operator menyediakan semua kemungkinan untuk ini.

Kita bisa menulis apa yang kita inginkan langsung di YAML. Semua opsi konfigurasi dipetakan langsung dari YAML ini ke dalam konfigurasi ClickHouse, yang kemudian didistribusikan ke seluruh cluster.

Anda bisa menulisnya seperti ini. Ini misalnya. Kata sandi dapat dienkripsi. Benar-benar semua opsi konfigurasi ClickHouse didukung. Ini hanya sebuah contoh.

Konfigurasi cluster didistribusikan sebagai ConfigMap. Pada praktiknya, pembaruan ConfigMap tidak terjadi secara instan, sehingga jika clusternya besar, maka proses mendorong konfigurasi memerlukan waktu. Tapi semua ini sangat nyaman digunakan.

Mari kita mempersulit tugas ini. Cluster ini sedang berkembang. Kami ingin mereplikasi data. Artinya, kami sudah memiliki dua shard, masing-masing satu replika, dan pengguna sudah dikonfigurasi. Kami sedang berkembang dan ingin melakukan replikasi.

Apa yang kita perlukan untuk replikasi?

Kami membutuhkan Penjaga Kebun Binatang. Di ClickHouse, replikasi dibangun menggunakan ZooKeeper. ZooKeeper diperlukan agar replika ClickHouse yang berbeda memiliki konsensus mengenai blok data mana yang berada di ClickHouse mana.

ZooKeeper dapat digunakan oleh siapa saja. Jika perusahaan memiliki Zookeeper eksternal, maka Zookeeper tersebut dapat digunakan. Jika tidak, Anda dapat menginstalnya dari repositori kami. Ada penginstal yang membuat semuanya lebih mudah.

Dan diagram interaksi keseluruhan sistem menjadi seperti ini. Kami memiliki Kubernetes sebagai platform. Ini mengeksekusi operator ClickHouse. Saya membayangkan ZooKeeper di sini. Dan operator berinteraksi dengan ClickHouse dan ZooKeeper. Artinya, hasil interaksi.

Dan semua ini diperlukan agar ClickHouse berhasil mereplikasi data di k8s.

Sekarang mari kita lihat tugas itu sendiri, seperti apa tampilan manifes untuk replikasi.

Kami menambahkan dua bagian ke manifes kami. Yang pertama adalah tempat untuk mendapatkan ZooKeeper, yang bisa berada di dalam Kubernetes atau eksternal. Ini hanya deskripsi. Dan kami memesan replika. Itu. kami ingin dua replika. Secara total, kita harus memiliki 4 pod pada keluarannya. Kami ingat tentang penyimpanan, itu akan kembali lagi nanti. Penyimpanan adalah cerita yang terpisah.

Seperti ini.

Ini menjadi seperti ini. Replika ditambahkan. Yang ke-4 tidak cocok, kami yakin mungkin ada banyak di sana. Dan ZooKeeper ditambahkan ke samping. Skema ini menjadi lebih kompleks.

Dan saatnya menambahkan tugas berikutnya. Kami akan menambahkan Penyimpanan Persisten.

Untuk Penyimpanan Persisten kami memiliki berbagai opsi.

Jika kita menjalankan di penyedia cloud, misalnya menggunakan Amazon, Google, maka ada godaan besar untuk menggunakan penyimpanan cloud. Sangat nyaman, itu bagus.

Dan ada pilihan kedua. Ini untuk penyimpanan lokal, ketika kita memiliki disk lokal di setiap node. Opsi ini jauh lebih sulit untuk diterapkan, namun pada saat yang sama lebih produktif.

Mari kita lihat apa yang kita miliki mengenai penyimpanan cloud.

Ada keuntungannya. Sangat mudah untuk mengkonfigurasinya. Kami cukup memesan dari penyedia cloud yang tolong memberi kami penyimpanan dengan kapasitas ini dan itu, kelas ini dan itu. Kelas dijadwalkan oleh penyedia secara mandiri.

Dan ada kelemahannya. Bagi sebagian orang, ini adalah kelemahan yang tidak kritis. Tentu saja, akan ada beberapa masalah kinerja. Sangat mudah digunakan dan dapat diandalkan, namun ada beberapa potensi kelemahan kinerja.

Dan karena ClickHouse berfokus secara khusus pada produktivitas, bahkan dapat dikatakan bahwa ia memeras segala sesuatu yang dapat dilakukannya, itulah sebabnya banyak klien mencoba untuk memaksimalkan produktivitas.

Dan untuk memaksimalkannya, kita memerlukan penyimpanan lokal.

Kubernetes menyediakan tiga abstraksi untuk menggunakan penyimpanan lokal di Kubernetes. Ini:

• KosongDir
• Jalur Host.
• Bahan Makanan Lokal

Mari kita lihat perbedaannya dan persamaannya.

Pertama, dalam ketiga pendekatan kami memiliki penyimpanan - ini adalah disk lokal yang terletak di node fisik k8s yang sama. Tapi mereka memiliki beberapa perbedaan.

Mari kita mulai dengan yang paling sederhana, yaitu blankDir. Apa praktiknya? Dalam spesifikasi kami, kami meminta sistem containerisasi (paling sering Docker) untuk memberi kami akses ke folder di disk lokal.

Dalam praktiknya, Docker membuat folder sementara di suatu tempat di sepanjang jalurnya sendiri dan menyebutnya sebagai hash yang panjang. Dan menyediakan antarmuka untuk mengaksesnya.

Bagaimana cara kerjanya dari segi kinerja? Ini akan bekerja pada kecepatan disk lokal, mis. Ini adalah akses penuh ke sekrup Anda.

Namun kasus ini memiliki kekurangannya. Persistent cukup meragukan dalam hal ini. Pertama kali Docker berpindah dengan container, Persistent hilang. Jika Kubernetes ingin memindahkan Pod ini ke disk lain karena alasan tertentu, datanya akan hilang.

Pendekatan ini bagus untuk pengujian karena sudah menunjukkan kecepatan normal, tetapi untuk sesuatu yang serius opsi ini tidak cocok.

Oleh karena itu ada pendekatan kedua. Ini adalah jalur host. Jika Anda melihat slide sebelumnya dan slide ini, Anda hanya melihat satu perbedaan. Folder kami dipindahkan dari Docker langsung ke node Kubernetes. Ini sedikit lebih sederhana di sini. Kami langsung menentukan jalur pada sistem file lokal tempat kami ingin menyimpan data kami.

Cara ini mempunyai kelebihan. Ini sudah benar-benar Persisten, dan klasik. Kami akan memiliki data yang direkam pada disk di beberapa alamat.

Ada juga kelemahannya. Inilah kompleksitas manajemen. Kubernetes kami mungkin ingin memindahkan Pod ke node fisik lain. Dan di sinilah DevOps berperan. Dia harus menjelaskan dengan benar kepada seluruh sistem bahwa pod ini hanya dapat dipindahkan ke node di mana Anda memasang sesuatu di sepanjang jalur ini, dan tidak lebih dari satu node dalam satu waktu. Ini cukup sulit.

Khusus untuk tujuan ini, kami membuat template di operator kami untuk menyembunyikan semua kerumitan ini. Dan Anda cukup mengatakan: “Saya ingin memiliki satu instance ClickHouse untuk setiap node fisik dan di sepanjang jalur ini dan itu.”

Namun bukan hanya kami saja yang membutuhkan kebutuhan tersebut, sehingga bapak-bapak dari Kubernetes sendiri juga paham bahwa masyarakat ingin memiliki akses ke disk fisik, sehingga mereka menyediakan lapisan ketiga.

Ini disebut lokal. Praktis tidak ada perbedaan dengan slide sebelumnya. Sebelumnya perlu dikonfirmasi secara manual bahwa kami tidak dapat mentransfer pod ini dari satu node ke node lainnya, karena pod tersebut harus dipasang di sepanjang jalur tertentu ke disk fisik lokal, tetapi sekarang semua pengetahuan ini dirangkum dalam Kubernetes itu sendiri. Dan ternyata lebih mudah untuk dikonfigurasi.

Mari kita kembali ke masalah praktis kita. Mari kembali ke template YAML. Di sini kita memiliki penyimpanan nyata. Kami kembali melakukannya. Kami mengatur template VolumeClaim klasik seperti di k8s. Dan kami menjelaskan jenis penyimpanan apa yang kami inginkan.

Setelah ini, k8s akan meminta penyimpanan. Akan mengalokasikannya kepada kami di StatefulSet. Dan pada akhirnya itu akan menjadi milik ClickHouse.

Kami punya skema ini. Penyimpanan Persisten kami berwarna merah, yang sepertinya mengisyaratkan bahwa hal itu perlu dilakukan.

Dan warnanya berubah menjadi hijau. Sekarang skema cluster ClickHouse di k8s telah selesai sepenuhnya. Kami memiliki pecahan, replika, Penjaga Kebun Binatang, kami memiliki Persisten nyata, yang diimplementasikan dengan satu atau lain cara. Skema ini sudah beroperasi penuh.

Kami terus hidup. Cluster kami sedang berkembang. Dan Alexei mencobanya, dan merilis versi baru ClickHouse.

Sebuah tugas praktis muncul - untuk menguji versi baru ClickHouse di cluster kami. Dan, tentu saja, Anda tidak ingin meluncurkan semuanya; Anda ingin meletakkan versi baru dalam satu replika di suatu tempat di sudut jauh, dan mungkin bukan satu versi baru, tetapi dua versi sekaligus, karena sering kali dirilis.

Apa yang dapat kami katakan mengenai hal ini?

Di sini kita mempunyai kesempatan seperti itu. Ini adalah templat pod. Anda dapat menulis bahwa operator kami sepenuhnya mengizinkan Anda membangun cluster heterogen. Itu. konfigurasikan, mulai dari semua replika dalam satu kelompok, diakhiri dengan setiap replika pribadi, versi mana yang kita inginkan ClickHouse, versi mana yang kita inginkan penyimpanannya. Kita dapat mengkonfigurasi cluster sepenuhnya dengan konfigurasi yang kita butuhkan.

Mari kita masuk lebih dalam ke dalam. Sebelumnya, kita telah membahas tentang cara kerja operator ClickHouse sehubungan dengan spesifikasi ClickHouse.

Sekarang saya ingin menyampaikan beberapa patah kata tentang cara kerja operator secara umum, serta cara berinteraksi dengan K8.

Mari kita lihat interaksi dengan K8 terlebih dahulu. Apa yang terjadi jika kita menerapkan kubectl? Objek kita muncul di etcd melalui API.

Misalnya, objek dasar Kubernetes: pod, StatefulSet, service, dan sebagainya.

Pada saat yang sama, belum ada yang terjadi secara fisik. Objek-objek ini harus diwujudkan dalam cluster.

Untuk tujuan ini, sebuah pengontrol muncul. Pengontrol adalah komponen k8s khusus yang dapat mewujudkan deskripsi ini. Dia tahu bagaimana dan apa yang harus dilakukan secara fisik. Dia tahu cara menjalankan container, apa yang perlu dikonfigurasi di sana agar server dapat berfungsi.

Dan itu mewujudkan objek kita di K8.

Tapi kami ingin beroperasi tidak hanya dengan pod dan StatefulSets, kami ingin membuat ClickHouseInstallation, yaitu sebuah objek bertipe ClickHouse, untuk beroperasi dengannya secara keseluruhan. Sejauh ini tidak ada kemungkinan seperti itu.

Tapi K8s memiliki hal menyenangkan berikut ini. Kami ingin kami memiliki entitas kompleks seperti ini di mana cluster kami akan dirakit dari pod dan StatefulSet.

Dan apa yang perlu dilakukan untuk ini? Pertama, Definisi Sumber Daya Kustom muncul. Apa itu? Ini adalah deskripsi untuk K8, bahwa Anda akan memiliki satu tipe data lagi, bahwa kami ingin menambahkan sumber daya khusus ke pod, StatefulSet, yang di dalamnya akan menjadi kompleks. Ini adalah deskripsi struktur data.

Kami juga mengirimkannya ke sana melalui kubectl apply. Kubernetes dengan senang hati menerimanya.

Dan sekarang di penyimpanan kami, objek di etcd memiliki kesempatan untuk merekam sumber daya khusus yang disebut ClickHouseInstallation.

Namun untuk saat ini, tidak ada hal lebih lanjut yang akan terjadi. Artinya, jika sekarang kita membuat file YAML yang kita lihat mendeskripsikan pecahan dan replika dan mengatakan “kubectl apply,” maka Kubernetes akan menerimanya, memasukkannya ke dalam etcd dan berkata: “Bagus, tapi saya tidak tahu harus berbuat apa dengan itu. Saya tidak tahu cara memelihara ClickHouseInstallation.”

Oleh karena itu, kami memerlukan seseorang untuk membantu Kubernetes menyajikan tipe data baru. Di sebelah kiri kami memiliki pengontrol Kubernetes asli yang bekerja dengan tipe data asli. Dan di sebelah kanan kita harus memiliki pengontrol khusus yang dapat bekerja dengan tipe data khusus.

Dan dengan cara lain disebut operator. Saya secara khusus memasukkannya di sini sebagai Kubernetes, karena bisa juga dijalankan di luar K8. Paling sering, tentu saja, semua operator dieksekusi di Kubernetes, tetapi tidak ada yang menghalanginya untuk berdiri di luar, jadi di sini ia dipindahkan secara khusus ke luar.

Dan pada gilirannya, pengontrol khusus, juga dikenal sebagai operator, berinteraksi dengan Kubernetes melalui API. Ia sudah mengetahui cara berinteraksi dengan API. Dan dia sudah tahu bagaimana mewujudkan rangkaian kompleks yang ingin kita buat dari sumber daya khusus. Inilah yang dilakukan operator.

Bagaimana cara kerja operatornya? Mari kita lihat sisi kanan untuk melihat bagaimana dia melakukannya. Mari kita cari tahu bagaimana operator mewujudkan semua ini dan bagaimana interaksi lebih lanjut dengan K8 terjadi.

Operator adalah sebuah program. Dia berorientasi pada peristiwa. Operator berlangganan acara menggunakan API Kubernetes. Kubernetes API memiliki titik masuk di mana Anda dapat berlangganan acara. Dan jika ada perubahan di K8, maka Kubernetes mengirimkan event ke semua orang, mis. siapa pun yang berlangganan titik API ini akan menerima pemberitahuan.

Operator berlangganan acara dan harus membuat semacam reaksi. Tugasnya adalah merespons peristiwa-peristiwa yang muncul.

Acara dihasilkan oleh pembaruan tertentu. File YAML kami dengan deskripsi ClickHouseInstallation telah tiba. Dia pergi ke dll melalui kubectl apply. Suatu peristiwa dipicu di sana, dan sebagai hasilnya peristiwa ini sampai ke operator ClickHouse. Operator menerima penjelasan ini. Dan dia harus melakukan sesuatu. Jika pembaruan telah tiba untuk objek ClickHouseInstallation, maka Anda perlu memperbarui cluster. Dan tugas operator adalah memperbarui cluster.

Apa yang dia lakukan? Pertama, kita perlu menyusun rencana tindakan tentang apa yang akan kita lakukan dengan pembaruan ini. Pembaruan bisa sangat kecil, mis. kecil dalam eksekusi YAML, namun dapat menyebabkan perubahan yang sangat besar pada cluster. Oleh karena itu, operator membuat rencana, dan kemudian menaatinya.

Menurut rencana ini, dia mulai memasak struktur ini di dalam untuk mewujudkan pod, layanan, mis. melakukan apa tugas utamanya. Berikut cara membangun cluster ClickHouse di Kubernetes.

Sekarang mari kita bahas hal yang menarik. Ini adalah pembagian tanggung jawab antara Kubernetes dan operator, yaitu. apa yang dilakukan Kubernetes, apa yang dilakukan operator, dan bagaimana mereka berinteraksi satu sama lain.

Kubernetes bertanggung jawab atas hal-hal sistem, mis. untuk sekumpulan objek dasar yang dapat diartikan sebagai cakupan sistem. Kubernetes mengetahui cara meluncurkan pod, cara memulai ulang container, cara memasang volume, cara bekerja dengan ConfigMap, yaitu. segala sesuatu yang bisa disebut sistem.

Operator beroperasi di domain. Setiap operator dibuat untuk bidang studinya sendiri. Kami melakukannya untuk ClickHouse.

Dan operator berinteraksi secara tepat dalam bidang subjek, seperti menambahkan replika, membuat diagram, mengatur pemantauan. Hal ini mengakibatkan terjadinya perpecahan.

Mari kita lihat contoh praktis bagaimana pembagian tanggung jawab ini terjadi ketika kita melakukan tindakan penambahan replika.

Operator menerima tugas - untuk menambahkan replika. Apa yang dilakukan operator? Operator akan menghitung bahwa StatefulSet baru perlu dibuat, di mana template ini dan itu, klaim volume, harus dijelaskan.

Dia menyiapkan semuanya dan meneruskannya ke K8s. Dia mengatakan bahwa dia membutuhkan ConfigMap, StatefulSet, Volume. Kubernetes berfungsi. Dia mewujudkan unit dasar yang dia operasikan.

Dan kemudian operator ClickHouse kembali berperan. Dia sudah memiliki pod fisik di mana dia sudah bisa melakukan sesuatu. Dan operator ClickHouse kembali berfungsi dalam istilah domain. Itu. Khususnya ClickHouse, untuk menyertakan replika dalam sebuah cluster, Anda harus terlebih dahulu mengkonfigurasi skema data yang ada di cluster ini. Dan yang kedua, replika ini harus diikutsertakan dalam pemantauan agar dapat ditelusuri dengan jelas. Operator sudah mengonfigurasi ini.

Dan hanya setelah itu ClickHouse sendiri mulai berperan, yaitu. entitas lain yang tingkatnya lebih tinggi. Ini sudah menjadi database. Ia memiliki instansnya sendiri, replika terkonfigurasi lain yang siap bergabung dengan klaster.

Ternyata rantai pelaksanaan dan pembagian tanggung jawab saat menambah replika cukup panjang.

Kami melanjutkan tugas praktis kami. Jika Anda sudah memiliki cluster, Anda dapat memigrasikan konfigurasinya.

Kami membuatnya agar Anda dapat menempelkannya langsung ke xml yang ada, yang dipahami oleh ClickHouse.

Anda dapat menyempurnakan ClickHouse. Penerapan yang dikategorikan saja adalah apa yang saya bicarakan ketika menjelaskan hostPath, penyimpanan lokal. Ini adalah cara melakukan penerapan yang dikategorikan dengan benar.

Tugas praktek selanjutnya adalah monitoring.

Jika cluster kita berubah, maka kita perlu mengkonfigurasi pemantauan secara berkala.

Mari kita lihat diagramnya. Kita telah melihat panah hijau di sini. Sekarang mari kita lihat panah merah. Beginilah cara kami ingin memantau cluster kami. Bagaimana metrik dari cluster ClickHouse masuk ke Prometheus, lalu ke Grafana.

Apa kesulitan dalam pemantauan? Mengapa hal ini dianggap sebagai suatu pencapaian? Kesulitannya terletak pada dinamikanya. Ketika kita memiliki satu cluster dan bersifat statis, maka kita dapat mengatur pemantauan satu kali dan tidak perlu repot lagi.

Namun jika kita mempunyai banyak cluster, atau ada sesuatu yang terus berubah, maka prosesnya bersifat dinamis. Dan terus-menerus mengkonfigurasi ulang pemantauan hanya membuang-buang sumber daya dan waktu, yaitu membuang-buang waktu. bahkan hanya kemalasan. Ini perlu diotomatisasi. Kesulitannya terletak pada dinamika prosesnya. Dan operator mengotomatiskannya dengan sangat baik.

Bagaimana cluster kami berkembang? Awalnya dia seperti itu.

Lalu dia seperti ini.

Pada akhirnya, dia menjadi seperti ini.

Dan monitoring dilakukan secara otomatis oleh operator. Satu titik masuk.

Dan tepat di pintu keluar, kami melihat dasbor Grafana untuk melihat bagaimana kehidupan cluster kami berjalan lancar di dalamnya.

Omong-omong, dasbor Grafana juga didistribusikan langsung ke operator kami dalam kode sumber. Anda dapat terhubung dan menggunakan. DevOps kami memberi saya tangkapan layar ini.

Ke mana kita ingin pergi selanjutnya? Ini:

• Mengembangkan otomatisasi pengujian. Tugas utamanya adalah pengujian otomatis versi baru.
• Kami juga sangat ingin mengotomatiskan integrasi dengan ZooKeeper. Dan ada rencana untuk berintegrasi dengan operator ZooKeeper. Itu. Sebuah operator telah ditulis untuk ZooKeeper dan masuk akal jika kedua operator mulai berintegrasi untuk membangun solusi yang lebih nyaman.
• Kami ingin melakukan pemeriksaan tanda-tanda vital yang lebih kompleks.
• Saya menyorot dengan warna hijau bahwa kita mendekati pewarisan Templat - SELESAI, yaitu dengan rilis operator berikutnya kita sudah memiliki warisan templat. Ini adalah alat canggih yang memungkinkan Anda membuat konfigurasi kompleks dari beberapa bagian.
• Dan kami menginginkan otomatisasi tugas-tugas kompleks. Yang utama adalah Re-sharding.

Mari kita ambil beberapa hasil antara.

Apa yang kita dapatkan sebagai hasilnya? Dan apakah itu layak dilakukan atau tidak? Apakah perlu mencoba menyeret database ke Kubernetes dan menggunakan operator pada umumnya dan operator Alitnity pada khususnya?

Pada output kita mendapatkan:

• Penyederhanaan dan otomatisasi konfigurasi, penerapan, dan pemeliharaan yang signifikan.
• Pemantauan bawaan segera.
• Dan templat terkodifikasi yang siap digunakan untuk situasi kompleks. Tindakan seperti menambahkan replika tidak perlu dilakukan secara manual. Operator melakukan ini.

Hanya ada satu pertanyaan terakhir yang tersisa. Kami sudah memiliki database di Kubernetes, virtualisasi. Bagaimana dengan kinerja solusi seperti itu, terutama karena ClickHouse dioptimalkan untuk kinerja?

Jawabannya adalah semuanya baik-baik saja! Saya tidak akan menjelaskan secara rinci; ini adalah topik laporan terpisah.

Tapi ada proyek seperti TSBS. Apa tugas utamanya? Ini adalah tes kinerja basis data. Ini adalah upaya untuk membandingkan hangat dengan hangat, lembut dengan lembut.

Bagaimana cara kerjanya? Satu kumpulan data dihasilkan. Kemudian kumpulan data ini dijalankan pada database berbeda menggunakan kumpulan pengujian yang sama. Dan setiap database memecahkan satu masalah dengan cara yang diketahuinya. Dan kemudian Anda bisa membandingkan hasilnya.

Ini sudah mendukung banyak database. Saya telah mengidentifikasi tiga yang utama. Ini:

• Skala waktuDB.
• masuknyaDB.
• Klik Rumah.

Perbandingan juga dilakukan dengan solusi serupa lainnya. Perbandingan dengan RedShift. Perbandingan dilakukan di Amazon. ClickHouse juga jauh di depan semua orang dalam hal ini.

Kesimpulan apa yang dapat diambil dari apa yang saya katakan?

• DB di Kubernetes dimungkinkan. Mungkin saja semuanya mungkin, tapi secara keseluruhan sepertinya itu mungkin. ClickHouse di Kubernetes pasti dapat dilakukan dengan bantuan operator kami.
• Operator membantu mengotomatiskan proses dan membuat hidup lebih mudah.
• Performanya biasa saja.
• Dan menurut kami hal ini dapat dan harus digunakan.

Sumber terbuka - bergabunglah dengan kami!

Seperti yang sudah saya katakan, operator adalah produk yang sepenuhnya open source, jadi akan sangat baik jika sebanyak mungkin orang yang menggunakannya. Bergabunglah dengan kami! Kami menunggu kalian semua!

Terima kasih semuanya!

pertanyaan

Terima kasih atas laporannya! Nama saya Anton. Saya dari SEMrush. Saya bertanya-tanya ada apa dengan logging. Kita mendengar tentang pemantauan, tetapi tidak mendengar apa pun tentang logging, jika kita berbicara tentang keseluruhan cluster. Misalnya, kami telah membuat cluster pada perangkat keras. Dan kami menggunakan logging terpusat, mengumpulkannya ke dalam tumpukan umum menggunakan cara standar. Dan dari sana kami mendapatkan data yang menarik minat kami.

Pertanyaan bagus, yaitu masuk ke daftar tugas. Operator kami belum mengotomatiskannya. Masih berkembang, proyeknya masih cukup muda. Kami memahami perlunya pencatatan. Ini juga merupakan topik yang sangat penting. Dan ini mungkin tidak kalah pentingnya dengan pemantauan. Namun yang pertama dalam daftar implementasi adalah pemantauan. Akan ada pencatatan. Tentu saja, kami mencoba mengotomatiskan semua aspek kehidupan cluster. Oleh karena itu, jawabannya adalah saat ini operator, sayangnya, tidak tahu bagaimana melakukan hal tersebut, tetapi sudah dalam rencana, kami akan melakukannya. Kalau mau gabung silahkan tarik requestnya.

Halo! Terima kasih atas laporannya! Saya memiliki pertanyaan standar terkait Volume Persisten. Ketika kita membuat konfigurasi dengan operator ini, bagaimana operator menentukan pada node mana kita memasang disk atau folder tertentu? Pertama-tama kita harus menjelaskan kepadanya bahwa tolong tempatkan ClickHouse kita pada node yang memiliki disk ini?

Sejauh yang saya mengerti, pertanyaan ini merupakan kelanjutan dari penyimpanan lokal, terutama bagian hostPath-nya. Ini seperti menjelaskan kepada seluruh sistem bahwa pod perlu diluncurkan pada node ini dan itu, di mana kita memiliki disk yang terhubung secara fisik, yang dipasang di sepanjang jalur ini dan itu. Ini adalah keseluruhan bagian yang saya singgung secara dangkal karena jawabannya cukup besar.

Secara singkat tampilannya seperti ini. Tentu saja, kita perlu menyediakan volume ini. Saat ini, tidak ada penyediaan dinamis dalam penyimpanan lokal, sehingga DevOps harus memotong disk itu sendiri, volume-volume ini. Dan mereka harus menjelaskan ketentuan Kubernetes bahwa Anda akan memiliki volume Persisten dari kelas ini dan itu, yang terletak di node ini dan itu. Kemudian Anda perlu menjelaskan kepada Kubernetes bahwa pod yang memerlukan kelas penyimpanan lokal ini dan itu perlu diarahkan hanya ke node ini dan itu dengan menggunakan label. Untuk tujuan ini, operator memiliki kemampuan untuk menetapkan beberapa jenis label dan satu label per instance host. Dan ternyata pod akan dirutekan oleh Kubernetes untuk berjalan hanya pada node yang memenuhi persyaratan, label, secara sederhana. Administrator menetapkan label dan menyediakan disk secara manual. Dan kemudian berskala.

Dan opsi ketiga, lokal, yang membantu mempermudah hal ini. Seperti yang telah saya tekankan, ini adalah pekerjaan penyetelan yang melelahkan, yang pada akhirnya membantu mendapatkan performa maksimal.

Saya punya pertanyaan kedua terkait dengan ini. Kubernetes dirancang sedemikian rupa sehingga tidak menjadi masalah bagi kita apakah kita kehilangan sebuah node atau tidak. Apa yang harus kita lakukan dalam kasus ini jika kita kehilangan node tempat pecahan kita digantung?

Ya, Kubernetes awalnya diposisikan bahwa hubungan kita dengan pod kita seperti ternak, tetapi di sini bersama kita, setiap disk menjadi seperti hewan peliharaan. Ada masalah yang tidak bisa kita buang begitu saja. Dan perkembangan Kubernetes sedang menuju ke arah yang tidak mungkin untuk sepenuhnya diperlakukan secara filosofis, seolah-olah Kubernetes adalah sumber daya yang sepenuhnya dibuang.

Sekarang untuk pertanyaan praktis. Apa yang harus dilakukan jika Anda kehilangan node tempat disk berada? Di sini masalahnya diselesaikan pada tingkat yang lebih tinggi. Dalam kasus ClickHouse, kami memiliki replika yang bekerja pada tingkat yang lebih tinggi, yaitu. di tingkat ClickHouse.

Apa disposisi yang dihasilkan? DevOps bertanggung jawab untuk memastikan bahwa data tidak hilang. Dia harus menyiapkan replikasi dengan benar dan harus memastikan bahwa replikasi berjalan. Replika di tingkat ClickHouse harus memiliki data duplikat. Ini bukan tugas yang diselesaikan oleh operator. Dan bukan masalah yang diselesaikan oleh Kubernetes sendiri. Ini ada di tingkat ClickHouse.

Apa yang harus dilakukan jika simpul besi Anda terlepas? Dan ternyata Anda perlu menginstal yang kedua, menyediakan disk dengan benar di dalamnya, dan memberi label. Dan setelah itu, ia akan memenuhi persyaratan agar Kubernetes dapat meluncurkan pod instance di dalamnya. Kubernetes akan meluncurkannya. Jumlah pod Anda tidak cukup untuk memenuhi jumlah yang ditentukan. Ini akan melalui siklus yang saya tunjukkan. Dan pada level tertinggi, ClickHouse akan memahami bahwa kita telah memasukkan replika, masih kosong dan kita harus mulai mentransfer data ke dalamnya. Itu. Proses ini belum terotomatisasi dengan baik.

Terima kasih atas laporannya! Ketika segala macam hal buruk terjadi, operator mogok dan restart, dan pada saat itu tiba, apakah Anda dapat menanganinya?

Apa jadinya kalau operatornya crash dan restart ya?

Ya. Dan pada saat itulah peristiwa tiba.

Tugas yang harus dilakukan dalam kasus ini sebagian dibagi antara operator dan Kubernetes. Kubernetes mempunyai kemampuan untuk memutar ulang peristiwa yang telah terjadi. Dia memutar ulang. Dan tugas operator adalah memastikan bahwa ketika log peristiwa diputar ulang, peristiwa ini adalah idempoten. Dan agar kejadian yang sama tidak terulang kembali, tidak merusak sistem kita. Dan operator kami mengatasi tugas ini.

Halo! Terima kasih atas laporannya! Dmitry Zavyalov, perusahaan Smedova. Apakah ada rencana untuk menambahkan kemampuan konfigurasi dengan haproxy ke operator? Saya akan tertarik pada beberapa penyeimbang lain selain yang standar, sehingga cerdas dan memahami bahwa ClickHouse benar-benar ada.

Apakah Anda berbicara tentang Ingress?

Ya, ganti Ingress dengan haproxy. Di haproxy Anda dapat menentukan topologi cluster yang memiliki replika.

Kami belum memikirkannya. Jika Anda memerlukannya dan dapat menjelaskan mengapa diperlukan, maka akan memungkinkan untuk dilaksanakan, terutama jika Anda ingin berpartisipasi. Kami akan dengan senang hati mempertimbangkan opsi tersebut. Jawaban singkatnya adalah tidak, saat ini kami tidak memiliki fungsi seperti itu. Terima kasih atas tipnya, kami akan menyelidiki masalah ini. Dan jika Anda juga menjelaskan kasus penggunaan dan mengapa hal itu diperlukan dalam praktik, misalnya, membuat masalah di GitHub, itu akan bagus.

Telah.

Bagus. Kami terbuka untuk saran apa pun. Dan haproxy ditambahkan ke daftar tugas. Daftar tugas terus bertambah, belum menyusut. Tapi ini bagus, artinya produknya laris.

Sumber: www.habr.com