Hai Habr!
Kami mengingatkan anda bahawa kami telah mengeluarkan satu lagi yang sangat menarik dan berguna tentang corak Kubernetes. Semuanya bermula dengan "" Brendan Burns, dan, dengan cara itu, kami mempunyai kerja dalam segmen ini . Hari ini kami menjemput anda untuk membaca artikel dari blog MiniIO yang menggariskan secara ringkas arah aliran dan spesifikasi corak storan data dalam Kubernetes.
Kubernetes secara asasnya telah mengubah pembangunan aplikasi tradisional dan corak penggunaan. Kini pasukan boleh membangunkan, menguji dan menggunakan aplikasi dalam masa beberapa hariβmerentas berbilang persekitaran, semuanya dalam kelompok Kubernetes. Kerja sedemikian dengan teknologi generasi terdahulu biasanya mengambil masa berminggu-minggu, jika tidak berbulan-bulan.
Pecutan ini dimungkinkan oleh abstraksi yang disediakan oleh Kubernetes - iaitu, kerana Kubernetes sendiri berinteraksi dengan butiran peringkat rendah mesin fizikal atau maya, membolehkan pengguna mengisytiharkan pemproses yang dikehendaki, jumlah memori yang dikehendaki dan bilangan bekas contoh, antara parameter lain. Dengan komuniti besar yang menyokong Kubernetes dan penggunaannya terus berkembang, Kubernetes ialah peneraju di antara semua platform orkestrasi kontena dengan margin yang luas.
Apabila penggunaan Kubernetes berkembang, begitu juga kekeliruan tentang corak penyimpanannya..
Dengan semua orang bersaing untuk mendapatkan sekeping pai Kubernetes (iaitu, storan data), apabila bercakap tentang storan data, isyarat itu tenggelam dalam banyak bunyi.
Kubernetes merangkumi model moden untuk pembangunan aplikasi, penggunaan dan pengurusan. Model moden ini memisahkan storan data daripada pengiraan. Untuk memahami sepenuhnya detasmen dalam konteks Kubernetes, anda juga perlu memahami apa itu aplikasi stateful dan stateless, dan cara penyimpanan data sesuai dengannya. Di sinilah pendekatan REST API yang digunakan oleh S3 mempunyai kelebihan yang jelas berbanding pendekatan POSIX/CSI bagi penyelesaian lain.
Dalam artikel ini, kita akan bercakap tentang corak penyimpanan data dalam Kubernetes dan secara khusus menyentuh perbahasan antara aplikasi stateful dan stateless untuk memahami dengan lebih baik apakah perbezaan antara mereka dan mengapa ia penting. Teks selebihnya akan melihat aplikasi dan corak storan datanya berdasarkan amalan terbaik untuk bekerja dengan bekas dan Kubernetes.
Bekas Tanpa Kewarganegaraan
Bekas adalah secara semula jadi ringan dan tidak lama. Mereka boleh dengan mudah dihentikan, dialih keluar atau digunakan ke nod lain - semuanya dalam beberapa saat. Dalam sistem orkestrasi kontena yang besar, operasi sedemikian berlaku sepanjang masa, dan pengguna tidak menyedari perubahan tersebut. Walau bagaimanapun, pergerakan hanya boleh dilakukan jika bekas tidak mempunyai sebarang kebergantungan pada nod di mana ia berada. Bekas sedemikian dikatakan berfungsi tidak bernegara.
Kontena Stateful
Jika bekas menyimpan data pada peranti yang dilampirkan secara setempat (atau pada peranti blok), maka stor data di mana ia berada perlu dialihkan ke nod baharu, bersama bekas itu sendiri, sekiranya berlaku kegagalan. Ini penting kerana jika tidak, aplikasi yang berjalan di dalam bekas tidak akan dapat berfungsi dengan baik kerana ia perlu mengakses data yang disimpan pada media tempatan. Bekas sedemikian dikatakan berfungsi bernegara.
Dari sudut pandangan teknikal semata-mata, bekas stateful juga boleh dialihkan ke nod lain. Ini biasanya dicapai menggunakan sistem fail teragih atau storan rangkaian blok yang dilampirkan pada semua nod yang menjalankan bekas. Dengan cara ini, kontena mengakses volum untuk penyimpanan data yang berterusan, dan maklumat disimpan pada cakera yang terletak di seluruh rangkaian. Saya akan memanggil kaedah ini "pendekatan kontena stateful", dan dalam artikel yang lain saya akan memanggilnya demi keseragaman.
Dalam pendekatan bekas stateful yang tipikal, semua pod aplikasi dilampirkan pada sistem fail teragih tunggalβsejenis storan kongsi tempat semua data aplikasi berada. Walaupun beberapa variasi mungkin, ini adalah pendekatan peringkat tinggi.
Sekarang mari kita lihat mengapa pendekatan kontena stateful adalah anti-corak dalam dunia yang berpusatkan awan.
Reka bentuk aplikasi asli awan
Secara tradisinya, aplikasi menggunakan pangkalan data untuk penyimpanan berstruktur maklumat dan cakera tempatan atau sistem fail teragih di mana semua data tidak berstruktur atau separa berstruktur telah dibuang. Apabila volum data tidak berstruktur bertambah, pembangun menyedari bahawa POSIX terlalu cerewet, mempunyai overhed yang ketara dan akhirnya menghalang prestasi aplikasi apabila beralih ke skala yang benar-benar besar.
Ini terutamanya menyumbang kepada kemunculan standard baharu untuk storan data, iaitu storan berasaskan awan, yang berfungsi terutamanya berdasarkan API REST dan membebaskan aplikasi daripada penyelenggaraan yang membebankan storan data tempatan. Dalam kes ini, aplikasi secara berkesan masuk ke mod tanpa kewarganegaraan (memandangkan keadaan berada dalam storan jauh). Aplikasi moden dibina dari awal dengan mengambil kira faktor ini. Sebagai peraturan, sebarang aplikasi moden yang memproses data dari satu jenis atau yang lain (log, metadata, gumpalan, dll.) dibina mengikut paradigma berorientasikan awan, di mana keadaan dipindahkan ke sistem perisian yang didedikasikan khas untuk penyimpanannya.
Pendekatan kontena stateful memaksa seluruh paradigma ini kembali tepat di mana ia bermula!
Dengan menggunakan antara muka POSIX untuk menyimpan data, aplikasi beroperasi seolah-olah ia adalah stateful, dan kerana ini, ia bertolak daripada prinsip terpenting reka bentuk berpusatkan awan, iaitu, keupayaan untuk mengubah saiz benang pekerja aplikasi bergantung pada masuk. masukkan, muatkan, pindah ke nod baharu sebaik sahaja nod semasa gagal, dan seterusnya.
Melihat lebih dekat pada situasi ini, kami mendapati bahawa apabila memilih stor data, kami berulang kali berhadapan dengan dilema POSIX lwn. REST API, TETAPI dengan penambahan masalah POSIX disebabkan sifat pengedaran persekitaran Kubernetes. khususnya,
- POSIX cerewet: Semantik POSIX memerlukan setiap operasi dikaitkan dengan metadata dan deskriptor fail yang membantu mengekalkan keadaan operasi. Ini mengakibatkan kos ketara yang tidak mempunyai nilai sebenar. API storan objek, terutamanya API S3, menyingkirkan keperluan ini, membenarkan aplikasi menyala dan kemudian "melupakan" panggilan. Respons sistem storan menunjukkan sama ada tindakan itu berjaya atau tidak. Jika gagal, aplikasi boleh mencuba lagi.
- Sekatan rangkaian: Dalam sistem teragih, tersirat bahawa mungkin terdapat banyak aplikasi yang cuba menulis data ke media yang dilampirkan yang sama. Oleh itu, bukan sahaja aplikasi akan bersaing antara satu sama lain untuk jalur lebar pemindahan data (untuk menghantar data kepada media), tetapi sistem storan itu sendiri akan bersaing untuk jalur lebar ini dengan menghantar data merentasi cakera fizikal. Disebabkan oleh POSIX yang loquaciousness, bilangan panggilan rangkaian meningkat beberapa kali. Sebaliknya, API S3 memberikan perbezaan yang jelas antara panggilan rangkaian antara panggilan yang berasal dari klien ke pelayan dan yang berlaku dalam pelayan.
- keselamatan: Model keselamatan POSIX direka untuk penyertaan manusia yang aktif: pentadbir mengkonfigurasi tahap akses khusus untuk setiap pengguna atau kumpulan. Paradigma ini sukar untuk disesuaikan dengan dunia yang berpusatkan awan. Aplikasi moden bergantung pada model keselamatan berasaskan API, di mana hak akses ditakrifkan sebagai satu set dasar, akaun perkhidmatan, bukti kelayakan sementara, dsb. diperuntukkan.
- Pengendalian: Bekas stateful mempunyai beberapa overhed pengurusan. Kita bercakap tentang menyegerakkan akses selari kepada data, memastikan ketekalan data, semua ini memerlukan pertimbangan yang teliti tentang corak capaian data yang hendak digunakan. Perisian tambahan mesti dipasang, dipantau dan dikonfigurasikan, apatah lagi usaha pembangunan tambahan.
Antara Muka Penyimpanan Data Bekas
Walaupun Antara Muka Penyimpanan Kontena (CSI) telah banyak membantu dengan percambahan lapisan volum Kubernetes, sebahagiannya menyumber luarnya kepada vendor storan pihak ketiga, ia juga secara tidak sengaja menyumbang kepada kepercayaan bahawa pendekatan kontena stateful adalah kaedah yang disyorkan untuk menyimpan data dalam Kubernetes.
CSI telah dibangunkan sebagai standard untuk menyediakan blok sewenang-wenangnya dan sistem storan fail kepada aplikasi warisan apabila dijalankan pada Kubernetes. Dan, seperti yang ditunjukkan oleh artikel ini, satu-satunya situasi di mana pendekatan kontena stateful (dan CSI dalam bentuk semasanya) masuk akal ialah apabila aplikasi itu sendiri ialah sistem warisan yang tidak mungkin untuk menambah sokongan untuk API penyimpanan objek .
Adalah penting untuk memahami bahawa menggunakan CSI dalam bentuk semasanya, iaitu, memasang volum apabila bekerja dengan aplikasi moden, kita akan menghadapi kira-kira masalah yang sama yang timbul dalam sistem di mana penyimpanan data disusun dalam gaya POSIX.
Pendekatan yang Lebih Baik
Dalam kes ini, adalah penting untuk memahami bahawa kebanyakan aplikasi tidak direka bentuk secara semula jadi khusus untuk kerja stateful atau stateless. Tingkah laku ini bergantung pada keseluruhan seni bina sistem dan pilihan reka bentuk khusus yang dibuat. Mari kita bercakap sedikit tentang permohonan berstatus.
Pada dasarnya, semua data aplikasi boleh dibahagikan kepada beberapa jenis yang luas:
- Log data
- Data cap masa
- Data transaksi
- Metadata
- Imej bekas
- Data gumpalan (objek besar binari).
Semua jenis data ini disokong dengan sangat baik pada platform storan moden, dan terdapat beberapa platform asli awan yang disesuaikan untuk menyampaikan data dalam setiap format khusus ini. Sebagai contoh, data transaksi dan metadata mungkin berada dalam pangkalan data asli awan moden seperti CockroachDB, YugaByte, dsb. Imej bekas atau data gumpalan boleh disimpan dalam pendaftaran docker berdasarkan MinIO. Data cap waktu boleh disimpan dalam pangkalan data siri masa seperti InfluxDB, dsb. Kami tidak akan menerangkan secara terperinci tentang setiap jenis data dan aplikasinya di sini, tetapi idea umum adalah untuk mengelakkan penyimpanan data berterusan yang bergantung pada pelekap cakera tempatan.
Selain itu, ia selalunya berkesan untuk menyediakan lapisan caching sementara yang berfungsi sebagai stor fail sementara untuk aplikasi, tetapi aplikasi tidak harus bergantung pada lapisan ini sebagai sumber kebenaran.
Storan aplikasi stateful
Walaupun dalam kebanyakan kes adalah berguna untuk mengekalkan aplikasi tanpa status, aplikasi yang direka bentuk untuk menyimpan data - seperti pangkalan data, stor objek, stor nilai kunci - mestilah stateful. Mari lihat sebab aplikasi ini digunakan pada Kubernetes. Mari kita ambil MiniIO sebagai contoh, tetapi prinsip yang sama digunakan untuk mana-mana sistem storan asli awan besar yang lain.
Aplikasi asli awan direka bentuk untuk memanfaatkan sepenuhnya fleksibiliti yang wujud dalam bekas. Ini bermakna mereka tidak membuat andaian tentang persekitaran di mana mereka akan digunakan. Sebagai contoh, MiniIO menggunakan mekanisme pengekodan pemadaman dalaman untuk menyediakan sistem dengan daya tahan yang mencukupi untuk kekal beroperasi walaupun separuh cakera gagal. MiniIO juga menguruskan integriti dan keselamatan data menggunakan pencincangan dan penyulitan sebelah pelayan proprietari.
Untuk aplikasi berpusatkan awan sedemikian, volum berterusan setempat (PV) adalah paling mudah sebagai storan sandaran. PV tempatan menyediakan keupayaan untuk menyimpan data mentah, manakala aplikasi yang berjalan di atas PV ini secara bebas mengumpul maklumat untuk menskala data dan mengurus permintaan data yang semakin meningkat.
Pendekatan ini jauh lebih mudah dan jauh lebih berskala daripada PV berasaskan CSI, yang memperkenalkan lapisan pengurusan data dan redundansi mereka sendiri ke dalam sistem; intinya ialah lapisan ini biasanya bercanggah dengan aplikasi yang direka bentuk untuk menjadi stateful.
Pergerakan yang kuat ke arah memisahkan data daripada pengiraan
Dalam artikel ini, kita bercakap tentang cara aplikasi diorientasikan semula untuk berfungsi tanpa menyimpan keadaan, atau, dengan kata lain, menyimpan data dipisahkan daripada pengkomputeran padanya. Kesimpulannya, mari kita lihat beberapa contoh sebenar trend ini.
, platform analitik data yang terkenal, secara tradisinya telah dinyatakan dan digunakan pada HDFS. Walau bagaimanapun, apabila Spark bergerak ke dunia berpusatkan awan, platform ini semakin digunakan tanpa kewarganegaraan menggunakan `s3a`. Spark menggunakan s3a untuk memindahkan keadaan kepada sistem lain, manakala bekas Spark sendiri beroperasi sepenuhnya tanpa kewarganegaraan. Pemain perusahaan utama lain dalam bidang analisis data besar, khususnya, , , Mereka juga bergerak untuk bekerja dengan pengasingan penyimpanan data dan pengiraan pada mereka.
Corak serupa juga boleh dilihat pada platform analitik besar lain, termasuk Presto, Tensorflow to R, Jupyter. Dengan memunggah keadaan ke sistem storan awan jauh, ia menjadi lebih mudah untuk mengurus dan menskalakan aplikasi anda. Di samping itu, ia memudahkan kemudahalihan aplikasi kepada pelbagai persekitaran.
Sumber: www.habr.com