Phenquestions
Mari kita mulakan dengan definisi naif 'tanpa kewarganegaraan' dan kemudian perlahan-lahan menuju ke pandangan dunia yang lebih ketat dan nyata.
Aplikasi tanpa status adalah aplikasi yang tidak bergantung pada penyimpanan berterusan. Satu-satunya perkara yang menjadi tanggungjawab kluster anda adalah kod dan kandungan statik lain yang dihoskan di dalamnya. Itu sahaja, tidak ada pangkalan data yang berubah, tidak ada penulisan dan tidak ada fail yang tersisa ketika pod dihapuskan.
Aplikasi bernegara, sebaliknya, mempunyai beberapa parameter lain yang seharusnya dijaga dalam kluster. Terdapat pangkalan data dinamik yang, walaupun aplikasi di luar talian atau dihapus, tetap ada di cakera. Pada sistem yang diedarkan, seperti Kubernetes, ini menimbulkan beberapa masalah. Kami akan melihatnya secara terperinci, tetapi pertama-tama mari kita jelaskan beberapa kesalahpahaman.
Perkhidmatan tanpa kenegaraan sebenarnya tidak 'stateless'
Apa maksudnya apabila kita mengatakan keadaan sistem? Baiklah, mari kita pertimbangkan contoh ringkas pintu automatik berikut.
Pintu terbuka apabila sensor mengesan seseorang menghampiri, dan ia ditutup setelah sensor tidak mendapat input yang relevan.
Dalam praktiknya, aplikasi tanpa status anda serupa dengan mekanisme di atas. Ia boleh mempunyai lebih banyak keadaan daripada hanya ditutup atau terbuka, dan pelbagai jenis input juga menjadikannya lebih kompleks tetapi pada dasarnya sama.
Ini dapat menyelesaikan masalah yang rumit dengan hanya menerima input dan melakukan tindakan yang bergantung pada kedua input, dan 'menyatakan' di dalamnya. Bilangan keadaan yang mungkin telah ditentukan.
Jadi kenegaraan adalah salah nama.
Aplikasi tanpa kewarganegaraan, dalam praktiknya, dapat menipu sedikit dengan menyimpan perincian tentang, katakanlah, sesi klien pada klien itu sendiri (kuki HTTP adalah contoh yang bagus) dan masih mempunyai status tanpa kewarasan yang bagus yang akan menjadikannya dapat berjalan lancar di kluster.
Sebagai contoh, butir-butir sesi pelanggan seperti produk apa yang disimpan di dalam troli dan tidak diperiksa semuanya boleh disimpan pada pelanggan dan pada masa berikutnya sesi bermula butiran yang relevan ini juga dikenang.
Pada kluster Kubernetes, aplikasi tanpa status tidak mempunyai simpanan atau jumlah berterusan yang berkaitan dengannya. Dari perspektif operasi, ini adalah berita baik. Pod yang berlainan di seluruh kluster dapat berfungsi secara bebas dengan banyak permintaan datang kepada mereka secara serentak. Sekiranya ada masalah, anda boleh memulakan semula aplikasi dan aplikasi akan kembali ke keadaan awal dengan sedikit waktu henti.
Perkhidmatan bernas dan teorema CAP
Perkhidmatan bernegara, sebaliknya, perlu bimbang tentang banyak kes dan masalah pelik. Pod disertai dengan sekurang-kurangnya satu jilid dan jika data dalam jilid itu rosak maka itu tetap berlaku walaupun seluruh kluster dihidupkan semula.
Sebagai contoh, jika anda menjalankan pangkalan data pada kluster Kubernetes, semua pod mesti mempunyai volume tempatan untuk menyimpan pangkalan data. Semua data mesti diselaraskan dengan sempurna.
Oleh itu, jika seseorang mengubah entri ke pangkalan data, dan itu dilakukan pada pod A, dan permintaan baca datang pada pod B untuk melihat data yang diubah itu, maka pod B mesti menunjukkan data terbaru itu atau memberi anda pesan kesalahan. Ini dikenali sebagai ketekalan.
Ketekalan, dalam konteks kluster Kubernetes, bermaksud setiap bacaan menerima tulisan atau mesej ralat terkini.
Tetapi ini tidak sesuai ketersediaan, salah satu sebab terpenting untuk mempunyai sistem yang diedarkan. Ketersediaan menunjukkan bahawa aplikasi anda berfungsi sedekat mungkin dengan kesempurnaan, sepanjang masa, dengan sedikit kesalahan.
Seseorang mungkin berpendapat bahawa anda dapat mengelakkan semua ini jika anda hanya mempunyai satu pangkalan data terpusat yang bertanggungjawab untuk menangani semua keperluan penyimpanan berterusan. Sekarang kita kembali mempunyai satu titik kegagalan, yang merupakan masalah lain yang semestinya diselesaikan oleh kumpulan Kubernetes.
Anda perlu mempunyai cara terdesentralisasi untuk menyimpan data berterusan dalam kluster. Biasa disebut sebagai partition network. Lebih-lebih lagi, kluster anda mesti dapat bertahan daripada kegagalan nod yang menjalankan aplikasi bernegara. Ini dikenali sebagai toleransi partition.
Sebarang perkhidmatan (atau aplikasi) bernegara, yang dijalankan pada kelompok Kubernetes, perlu mempunyai keseimbangan antara ketiga parameter ini. Dalam industri, ia dikenal sebagai teorema CAP di mana pertukaran antara Konsistensi dan Ketersediaan dipertimbangkan dengan adanya Partitioning rangkaian.
Rujukan Lanjut
Untuk gambaran lebih lanjut mengenai teorema CAP, anda mungkin ingin melihat ceramah yang sangat baik ini yang diberikan oleh Bryan Cantrill, yang melihat lebih dekat dalam menjalankan sistem yang diedarkan dalam pengeluaran.
