🧙🏽 🚻 ⛩️ Operator kubernet Tarantool 👏🏾 👏🏾 🙇🏿

Kubernetes telah menjadi standar de-facto untuk menjalankan aplikasi stateless, terutama karena dapat mengurangi waktu ke pasar untuk fitur baru. Meluncurkan aplikasi stateful, seperti database atau microservices stateful, masih merupakan tugas yang kompleks, tetapi perusahaan harus memenuhi kompetisi dan mempertahankan tingkat pengiriman yang tinggi. Jadi mereka menciptakan permintaan untuk solusi semacam itu.

Kami ingin memperkenalkan solusi kami untuk meluncurkan kluster Tarantool Cartridge stateful state : Tarantool Kubernetes Operator , lebih di bawah potongan.

Tarantool adalah DBMS open-source dan server aplikasi all-in-one. Sebagai basis data, ia memiliki banyak karakteristik unik: efisiensi tinggi pemanfaatan perangkat keras, skema data yang fleksibel, dukungan untuk memori dan penyimpanan disk, dan kemungkinan ekstensi menggunakan bahasa Lua. Sebagai server aplikasi, ini memungkinkan Anda untuk memindahkan kode aplikasi sedekat mungkin dengan data dengan waktu respons minimum dan throughput maksimum. Selain itu, Tarantool memiliki ekosistem yang luas yang menyediakan modul yang siap digunakan untuk menyelesaikan masalah aplikasi: sharding , antrian , modul untuk pengembangan mudah ( cartridge , luatest ), solusi untuk operasi ( metrik , mungkin ), hanya untuk beberapa nama.

Untuk semua kelebihannya, kemampuan turunan Tarantool tunggal selalu terbatas. Anda harus membuat puluhan dan ratusan instance untuk menyimpan terabyte data dan memproses jutaan permintaan, yang sudah menyiratkan sistem terdistribusi dengan semua masalah khasnya. Untuk mengatasinya, kami memiliki Tarantool Cartridge , yang merupakan kerangka kerja yang dirancang untuk menyembunyikan segala macam kesulitan saat menulis aplikasi terdistribusi. Ini memungkinkan pengembang untuk berkonsentrasi pada nilai bisnis aplikasi. Cartridge menyediakan serangkaian komponen yang kuat untuk orkestrasi klaster otomatis, distribusi data otomatis, WebUI untuk operasi, dan alat pengembang.

Tarantool tidak hanya tentang teknologi, tetapi juga tentang tim insinyur yang bekerja pada pengembangan sistem turnkey enterprise, solusi out-of-the-box, dan dukungan untuk komponen open-source.

Secara global, semua tugas kita dapat dibagi menjadi dua area: pengembangan sistem baru dan peningkatan solusi yang ada. Misalnya, ada basis data yang luas dari vendor terkenal. Untuk skala untuk membaca, cache konsisten akhirnya berbasis Tarantool ditempatkan di belakangnya. Atau sebaliknya: untuk skala penulisan, Tarantool diinstal dalam konfigurasi panas / dingin: saat data “dingin”, data itu dibuang ke penyimpanan dingin dan pada saat yang sama masuk ke antrian analitik. Atau versi ringan dari sistem yang ada ditulis (cadangan fungsional) untuk membuat cadangan data "panas" dengan menggunakan replikasi data dari sistem utama. Pelajari lebih lanjut dari laporan konferensi T + 2019 .

Semua sistem ini memiliki satu kesamaan: mereka agak sulit dioperasikan. Nah, ada banyak hal yang menarik: untuk dengan cepat membuat sekelompok 100+ contoh yang didukung di 3 pusat data; untuk memperbarui aplikasi yang menyimpan data tanpa downtime atau drawdown pemeliharaan; untuk membuat cadangan dan memulihkan untuk mempersiapkan kemungkinan kecelakaan atau kesalahan manusia; untuk memastikan kegagalan komponen yang tersembunyi; untuk mengatur manajemen konfigurasi ...

Tarantool Cartridge yang baru saja dirilis ke open source secara signifikan menyederhanakan pengembangan sistem terdistribusi: ia mendukung pengelompokan komponen, penemuan layanan, manajemen konfigurasi, deteksi kegagalan instance dan failover otomatis, manajemen topologi replikasi, dan komponen sharding.
Akan sangat bagus jika kita bisa mengoperasikan semua ini secepat mengembangkannya. Kubernet memungkinkan, tetapi operator khusus akan membuat hidup lebih nyaman.

Hari ini kami memperkenalkan versi alpha Operator Tarantool Kubernetes.

Alih-alih Seribu Kata

Kami telah menyiapkan contoh kecil berdasarkan Tarantool Cartridge, dan kami akan bekerja dengannya. Ini adalah aplikasi sederhana yang disebut penyimpanan nilai kunci terdistribusi dengan antarmuka HTTP. Setelah start-up, kami memiliki yang berikut:

Dimana

Router adalah bagian dari gugus yang bertanggung jawab untuk menerima dan memproses permintaan HTTP yang masuk;
Penyimpanan adalah bagian dari cluster yang bertanggung jawab untuk menyimpan dan memproses data; tiga pecahan dipasang di luar kotak, masing-masing memiliki master dan replika.

Untuk menyeimbangkan lalu lintas HTTP yang masuk pada router, Kubernetes Ingress digunakan. Data didistribusikan dalam penyimpanan di tingkat Tarantool sendiri menggunakan komponen vshard .

Kita membutuhkan Kubernet 1.14+, tetapi minikube akan melakukannya. Sangat menyenangkan memiliki kubectl . Untuk memulai operator, buat ServiceAccount, Role, dan RoleBinding:

$ kubectl create -f https://raw.githubusercontent.com/tarantool/tarantool-operator/0.0.1/deploy/service_account.yaml $ kubectl create -f https://raw.githubusercontent.com/tarantool/tarantool-operator/0.0.1/deploy/role.yaml $ kubectl create -f https://raw.githubusercontent.com/tarantool/tarantool-operator/0.0.1/deploy/role_binding.yaml

Operator Tarantool memperluas API Kubernetes dengan definisi sumber dayanya, jadi mari kita buat mereka:

 $ kubectl create -f https://raw.githubusercontent.com/tarantool/tarantool-operator/0.0.1/deploy/crds/tarantool_v1alpha1_cluster_crd.yaml $ kubectl create -f https://raw.githubusercontent.com/tarantool/tarantool-operator/0.0.1/deploy/crds/tarantool_v1alpha1_role_crd.yaml $ kubectl create -f https://raw.githubusercontent.com/tarantool/tarantool-operator/0.0.1/deploy/crds/tarantool_v1alpha1_replicasettemplate_crd.yaml

Semuanya siap untuk memulai operator, jadi begini:

 $ kubectl create -f https://raw.githubusercontent.com/tarantool/tarantool-operator/0.0.1/deploy/operator.yaml

Kami menunggu operator untuk memulai, dan kemudian kami dapat melanjutkan dengan memulai aplikasi:

 $ kubectl create -f https://raw.githubusercontent.com/tarantool/tarantool-operator/0.0.1/examples/kv/deployment.yaml

Ingress dideklarasikan pada UI web dalam file YAML dengan contoh; ini tersedia di cluster_ip/admin/cluster . Ketika setidaknya satu Ingress Pod siap dan berjalan, Anda dapat pergi ke sana untuk melihat bagaimana instance baru ditambahkan ke cluster dan bagaimana topologi berubah.
Kami menunggu cluster untuk digunakan:

 $ kubectl describe clusters.tarantool.io examples-kv-cluster

Kami sedang menunggu Status klaster berikut:

 … Status: State: Ready …

Itu saja, dan aplikasi siap digunakan!

Apakah Anda memerlukan lebih banyak ruang penyimpanan? Lalu, mari kita tambahkan beberapa pecahan:

 $ kubectl scale roles.tarantool.io storage --replicas=3

Jika pecahan tidak dapat menangani beban, maka mari kita tambahkan jumlah instance dalam pecahan dengan mengedit templat set replika:

 $ kubectl edit replicasettemplates.tarantool.io storage-template

Mari kita atur nilai .spec.replicas menjadi dua untuk meningkatkan jumlah instance dalam setiap replika yang disetel menjadi dua.

Jika sebuah cluster tidak lagi diperlukan, hapus saja bersama dengan semua sumber daya:

 $ kubectl delete clusters.tarantool.io examples-kv-cluster

Apakah ada yang salah? Buat tiket , dan kami akan segera mengerjakannya.

Apa yang Sebenarnya Dilakukan oleh Operator

Start-up dan pengoperasian cluster Tarantool Cartridge adalah kisah melakukan tindakan spesifik dalam urutan tertentu pada waktu tertentu.

Cluster itu sendiri dikelola terutama melalui API admin: GraphQL melalui HTTP. Anda tidak diragukan lagi dapat naik level lebih rendah dan memberikan perintah langsung melalui konsol, tetapi ini tidak sering terjadi.
Sebagai contoh, ini adalah bagaimana cluster dimulai:

Kami menggunakan jumlah instance Tarantool yang diperlukan, misalnya, menggunakan systemd.

Kemudian kami menghubungkan instance ke keanggotaan:

 mutation { probe_instance: probe_server(uri: "storage:3301") }

Kemudian kami menetapkan peran ke instance dan menentukan instance dan replika set pengidentifikasi. API GraphQL digunakan untuk tujuan ini:

 mutation { join_server( uri:"storage:3301", instance_uuid: "cccccccc-cccc-4000-b000-000000000001", replicaset_uuid: "cccccccc-0000-4000-b000-000000000000", roles: ["storage"], timeout: 5 ) }

secara internal, kami mem-bootstrap komponen yang bertanggung jawab untuk sharding menggunakan API:
```
 mutation { bootstrap_vshard cluster { failover(enabled:true) } } 
```

Mudah kan?

Semuanya lebih menarik ketika datang ke ekspansi cluster. Peran Router dari skala contoh dengan mudah: membuat lebih banyak contoh, bergabung dengan mereka ke cluster yang ada, dan Anda selesai! Peran Storages agak rumit. Penyimpanan itu terbengkalai, jadi ketika menambahkan / menghapus instance, perlu menyeimbangkan kembali data dengan memindahkannya ke / dari instance baru / yang dihapus masing-masing. Gagal melakukan hal itu akan menghasilkan instance yang kurang beban, atau kehilangan data. Bagaimana jika tidak hanya satu, tetapi selusin cluster dengan topologi yang berbeda?

Secara umum, ini semua yang ditangani oleh Operator Tarantool. Pengguna menggambarkan keadaan yang diperlukan dari kluster Tarantool Cartridge, dan operator menerjemahkannya ke dalam serangkaian tindakan yang diterapkan pada sumber daya K8s dan ke panggilan tertentu ke API administrator klaster Tarantool dalam urutan tertentu pada waktu tertentu. Itu juga mencoba untuk menyembunyikan semua detail dari pengguna.

Sedikit Tentang Perincian

Saat bekerja dengan administrator API cluster Tarantool Cartridge, urutan panggilan dan tujuannya sangat penting. Kenapa begitu?

Tarantool Cartridge berisi penyimpanan topologi, komponen penemuan layanan, dan komponen konfigurasi. Setiap instance dari cluster menyimpan salinan topologi dan konfigurasi dalam file YAML.

 servers: d8a9ce19-a880-5757-9ae0-6a0959525842: uri: storage-2-0.examples-kv-cluster:3301 replicaset_uuid: 8cf044f2-cae0-519b-8d08-00a2f1173fcb 497762e2-02a1-583e-8f51-5610375ebae9: uri: storage-0-0.examples-kv-cluster:3301 replicaset_uuid: 05e42b64-fa81-59e6-beb2-95d84c22a435 … vshard: bucket_count: 30000 ...

Pembaruan diterapkan secara konsisten menggunakan mekanisme komitmen dua fase . Pembaruan yang berhasil membutuhkan kuorum 100%: setiap contoh harus merespons. Kalau tidak, ia akan berputar kembali. Apa artinya ini dalam hal operasi? Dalam hal keandalan, semua permintaan ke API administrator yang mengubah keadaan kluster harus dikirim ke satu instance, atau leader, karena jika tidak, kita berisiko mendapatkan konfigurasi yang berbeda pada instance yang berbeda. Tarantool Cartridge tidak tahu bagaimana melakukan pemilihan pemimpin (belum dulu), tetapi Operator Tarantool dapat, dan bagi Anda, ini hanya fakta yang menyenangkan, karena operator melakukan segalanya.

Setiap instance juga harus memiliki identitas tetap, yaitu serangkaian instance_uuid dan replicaset_uuid , serta advertise_uri . Jika tiba-tiba sebuah penyimpanan dinyalakan kembali, dan salah satu dari parameter ini berubah, maka Anda berisiko melanggar kuorum, dan operator bertanggung jawab untuk ini.

Cara operator bekerja

Tujuan operator adalah untuk membawa sistem ke status yang ditentukan pengguna dan mempertahankan sistem dalam keadaan ini sampai petunjuk baru diberikan. Agar operator dapat bekerja, perlu:

Deskripsi status sistem.
Kode yang akan membawa sistem ke keadaan ini.
Mekanisme untuk mengintegrasikan kode ini ke k8s (misalnya, untuk menerima pemberitahuan perubahan status).

Cluster Tarantool Cartridge dijelaskan dalam istilah k8s menggunakan Custom Resource Definition (CRD) . Operator akan membutuhkan tiga sumber daya khusus yang disatukan di bawah grup tarantool.io/v1alpha:

Cluster adalah sumber daya tingkat atas yang sesuai dengan satu kluster Tarantool Cartridge.
Peran adalah peran pengguna dalam hal Tarantool Cartridge.
Template Replicaset adalah template untuk membuat StatefulSets (saya akan memberitahu Anda sedikit kemudian mengapa mereka stateful; jangan dikacaukan dengan ReplicaSet K8s).

Semua sumber daya ini secara langsung mencerminkan model deskripsi klaster Tarantool Cartridge. Memiliki kamus umum memudahkan berkomunikasi dengan pengembang dan memahami apa yang ingin mereka lihat dalam produksi.

Kode yang membawa sistem ke status yang diberikan adalah Controller dalam hal K8s. Dalam hal Operator Tarantool, ada beberapa pengontrol:

Cluster Controller bertanggung jawab untuk berinteraksi dengan cluster Cartridge Tarantool; itu menghubungkan instance ke cluster dan memutus instance dari cluster.
Pengontrol Peran adalah pengontrol peran pengguna yang bertanggung jawab untuk membuat StatefulSets dari template dan mempertahankan jumlah yang telah ditentukan sebelumnya.

Seperti apa pengontrolnya? Ini adalah seperangkat kode yang secara bertahap menempatkan dunia di sekitar dirinya sendiri. Pengontrol Cluster secara skematis akan terlihat seperti:

Titik masuk adalah tes untuk melihat apakah ada sumber daya Cluster yang sesuai untuk suatu acara. Apakah itu ada "Tidak" berarti berhenti. "Ya" berarti pindah ke blok berikutnya dan mengambil Kepemilikan peran pengguna. Ketika Kepemilikan suatu peran diambil, ia berhenti dan pergi untuk yang kedua kalinya. Terus dan terus sampai dibutuhkan Kepemilikan semua peran. Ketika kepemilikan diambil, saatnya untuk pindah ke blok operasi berikutnya. Dan prosesnya berlangsung sampai blok terakhir. Setelah itu, kita dapat mengasumsikan bahwa sistem yang dikendalikan dalam keadaan yang ditentukan.

Secara umum, semuanya cukup sederhana. Namun, penting untuk menentukan kriteria keberhasilan untuk melewati setiap tahap. Misalnya, operasi penggabungan kluster tidak dianggap berhasil ketika mengembalikan hipotetis sukses = benar, tetapi ketika mengembalikan kesalahan seperti "sudah bergabung".

Dan bagian terakhir dari mekanisme ini adalah integrasi controller dengan K8s. Dari pandangan mata burung, seluruh K8 terdiri dari satu set pengontrol yang menghasilkan peristiwa dan meresponsnya. Acara-acara ini disusun dalam antrian yang dapat kami langgani. Secara skematis akan terlihat seperti:

Pengguna memanggil kubectl create -f tarantool_cluster.yaml , dan sumber daya Cluster yang sesuai dibuat. Pengontrol Cluster diberitahu tentang penciptaan sumber daya Cluster. Dan hal pertama yang coba dilakukan adalah menemukan semua sumber daya Peran yang seharusnya menjadi bagian dari klaster ini. Jika ya, maka menetapkan Cluster sebagai Pemilik untuk Peran dan memperbarui sumber daya Peran. Pengendali Peran menerima pemberitahuan pembaruan Peran, memahami bahwa sumber daya memiliki Pemiliknya, dan mulai membuat StatefulSets. Begini caranya: peristiwa pertama memicu yang kedua, peristiwa kedua memicu yang ketiga, dan seterusnya sampai salah satu dari mereka berhenti. Anda juga dapat mengatur pemicu waktu, misalnya, setiap 5 detik.

Beginilah cara operator mengatur: kami membuat sumber daya khusus dan menulis kode yang merespons peristiwa yang terkait dengan sumber daya.

Apa yang Diciptakan Operator

Tindakan operator pada akhirnya menghasilkan pembuatan K8s Pods dan wadah. Di Tarantool Cartridge cluster yang digunakan pada K8, semua Pod terhubung ke StatefulSets.

Mengapa StatefulSet? Seperti yang saya sebutkan sebelumnya, setiap instance Tarantool Cluster menyimpan salinan topologi dan konfigurasi cluster. Dan sesekali server aplikasi memiliki beberapa ruang khusus, misalnya, untuk antrian atau data referensi, dan ini sudah merupakan keadaan penuh. StatefulSet juga menjamin bahwa identitas Pod dipertahankan, yang penting ketika mengelompokkan instance: instance harus memiliki identitas tetap, jika tidak kita berisiko kehilangan kuorum saat dimulai ulang.

Ketika semua sumber daya cluster siap dan dalam keadaan yang diinginkan, mereka mencerminkan hierarki berikut:

Tanda panah menunjukkan hubungan Pemilik-Tanggungan antara sumber daya. Perlu, misalnya, untuk Pengumpul Sampah untuk membersihkan setelah penghapusan Cluster.

Selain StatefulSets, Operator Tarantool menciptakan Layanan Tanpa Kepala untuk pemilihan pemimpin, dan mesin virtual berkomunikasi satu sama lain melalui layanan ini.

Operator Tarantool didasarkan pada Kerangka Operator , dan kode operator ditulis dalam Golang, jadi tidak ada yang istimewa di sini.

Ringkasan

Cukup banyak yang ada untuk itu. Kami menunggu tanggapan dan tiket Anda. Kita tidak bisa melakukannya tanpa mereka - itu adalah versi alfa. Apa selanjutnya? Langkah selanjutnya adalah banyak pemolesan:

Unit, tes E2E;
Tes Chaos Monkey;
tes stres;
backup / restore;
penyedia topologi eksternal.

Masing-masing topik ini bersifat luas sendiri dan layak mendapatkan artikel terpisah, jadi harap tunggu pembaruan!