Phenquestions
Mari kita mulai dengan definisi naif tentang 'ketidakbernegaraan' dan kemudian perlahan-lahan berkembang ke pandangan dunia nyata yang lebih ketat.
Aplikasi stateless adalah aplikasi yang tidak bergantung pada penyimpanan persisten. Satu-satunya hal yang menjadi tanggung jawab cluster Anda adalah kode, dan konten statis lainnya, yang dihosting di dalamnya. Itu saja, tidak ada database yang berubah, tidak ada penulisan dan tidak ada file yang tersisa saat pod dihapus.
Aplikasi stateful, di sisi lain, memiliki beberapa parameter lain yang seharusnya dijaga di cluster. Ada database dinamis yang, bahkan saat aplikasi offline atau dihapus, tetap ada di disk. Pada sistem terdistribusi, seperti Kubernetes, ini menimbulkan beberapa masalah. Kami akan melihatnya secara detail, tetapi pertama-tama mari kita perjelas beberapa kesalahpahaman.
Layanan tanpa kewarganegaraan sebenarnya bukan 'tanpa kewarganegaraan'
Apa artinya ketika kita mengatakan keadaan suatu sistem?? Nah, mari kita simak contoh sederhana pintu otomatis berikut ini:.
Pintu terbuka ketika sensor mendeteksi seseorang mendekat, dan menutup setelah sensor tidak mendapatkan masukan yang relevan.
Dalam praktiknya, aplikasi stateless Anda mirip dengan mekanisme di atas. Itu dapat memiliki lebih banyak status daripada hanya tertutup atau terbuka, dan berbagai jenis input juga membuatnya lebih kompleks tetapi pada dasarnya sama.
Itu dapat memecahkan masalah rumit dengan hanya menerima input dan melakukan tindakan yang bergantung pada input, dan 'menyatakan' itu di. Jumlah kemungkinan keadaan sudah ditentukan sebelumnya.
Jadi keadaan tanpa kewarganegaraan adalah keliru.
Aplikasi stateless, dalam praktiknya, juga dapat sedikit curang dengan menyimpan detail tentang, katakanlah, sesi klien pada klien itu sendiri (cookie HTTP adalah contoh yang bagus) dan masih memiliki statelessness yang bagus yang akan membuatnya berjalan dengan sempurna di cluster.
Misalnya, detail sesi klien seperti produk apa yang disimpan di keranjang dan tidak diperiksa semuanya dapat disimpan di klien dan saat sesi berikutnya dimulai, detail yang relevan ini juga diingat.
Pada kluster Kubernetes, aplikasi stateless tidak memiliki penyimpanan atau volume persisten yang terkait dengannya. Dari perspektif operasi, ini adalah berita bagus great. Pod yang berbeda di seluruh cluster dapat bekerja secara independen dengan beberapa permintaan yang datang kepada mereka secara bersamaan. Jika terjadi kesalahan, Anda dapat memulai ulang aplikasi dan aplikasi akan kembali ke keadaan awal dengan sedikit waktu henti.
Layanan stateful dan teorema CAP
Layanan stateful, di sisi lain, harus khawatir tentang banyak kasus tepi dan masalah aneh. Pod disertai dengan setidaknya satu volume dan jika data dalam volume tersebut rusak maka itu akan tetap ada meskipun seluruh cluster di-boot ulang.
Misalnya, jika Anda menjalankan database di cluster Kubernetes, semua pod harus memiliki volume lokal untuk menyimpan database. Semua data harus sinkron sempurna.
Jadi, jika seseorang memodifikasi entri ke database, dan itu dilakukan pada Pod A, dan permintaan baca datang pada Pod B untuk melihat data yang dimodifikasi itu, maka Pod B harus menunjukkan data terbaru itu atau memberi Anda pesan kesalahan. Ini dikenal sebagai konsistensi.
Konsistensi, dalam konteks cluster Kubernetes, berarti, setiap pembacaan menerima tulisan terbaru atau pesan kesalahan.
Tapi ini melawan ketersediaan, salah satu alasan terpenting untuk memiliki sistem terdistribusi. Ketersediaan menyiratkan bahwa aplikasi Anda berfungsi sedekat mungkin dengan kesempurnaan, sepanjang waktu, dengan kesalahan sesedikit mungkin.
Orang mungkin berpendapat bahwa Anda dapat menghindari semua ini jika Anda hanya memiliki satu database terpusat yang bertanggung jawab untuk menangani semua kebutuhan penyimpanan persisten. Sekarang kita kembali ke satu titik kegagalan, yang merupakan masalah lain yang seharusnya diselesaikan oleh kluster Kubernetes.
Anda harus memiliki cara terdesentralisasi untuk menyimpan data persisten dalam sebuah cluster. Biasanya disebut sebagai partisi jaringan. Selain itu, cluster Anda harus mampu bertahan dari kegagalan node yang menjalankan aplikasi stateful. Ini dikenal sebagai toleransi partisi.
Layanan (atau aplikasi) stateful apa pun, yang dijalankan pada kluster Kubernetes, harus memiliki keseimbangan antara ketiga parameter ini. Di industri, ini dikenal sebagai teorema CAP di mana kompromi antara Konsistensi dan Ketersediaan dipertimbangkan dengan adanya Partisi jaringan.
Referensi Lebih Lanjut
Untuk wawasan lebih lanjut tentang teorema CAP, Anda mungkin ingin melihat ceramah luar biasa yang diberikan oleh Bryan Cantrill, yang melihat lebih dekat dalam menjalankan sistem terdistribusi dalam produksi.
