‫Sejauh ini dengan Kubernetes, kami belum benar-benar membahas penyimpanan
‫atau volume.
‫Anda sudah berurusan dengan itu dengan Docker, dan
‫kemudian dengan Compose, dan Swarm dan sampai batas tertentu, itu adalah hal
‫yang sama di Kubernetes.
‫Anda memiliki wadah, dan kami menganggap bahwa wadah tersebut
‫tidak memiliki kewarganegaraan, artinya ketika Anda membuang wadah itu,
‫semua yang ada di dalamnya hilang.
‫Ketika Anda mengganti sebuah wadah dengan pembaruan, atau Anda
‫mengubah sesuatu dan Anda menerapkannya dengan sebuah kubectl berlaku, Anda kehilangan wadah, Anda kehilangan
‫segalanya di dalamnya.
‫Jelas, Kubernetes, seperti orkestra lainnya,
‫harus memiliki cara agar data
‫tetap ada. Itu bahkan lebih dari volume itu sendiri.
‫Bahkan kontainer dan penyebaran bisa berbeda di Kubernet dengan
‫sesuatu yang disebut StatefulSets.
‫Ini adalah sumber yang berbeda
‫dari penggunaan.
‫Mereka pada dasarnya dirancang di sekitar basis data dan hal-hal yang membutuhkan
‫lebih banyak ketekunan, termasuk nama yang sama, hal-hal
‫IP yang sama seperti itu.
‫Kami tidak mendapatkan itu di luar gerbang dengan Swarm atau
‫dengan Docker tentu saja.
‫Itu tidak benar-benar memiliki cara bagi Anda untuk menjaga
‫atribut yang berbeda di antara kontainer.
‫StatefulSets adalah fitur baru di
‫Kubernetes yang hanya sedikit keluar di sini.
‫Itu yang akan Anda lihat jika Anda
‫akan mempertimbangkan basis data atau sesuatu yang sangat sensitif terhadap perubahan
‫seperti nama, dan alamat IP, dan volume, dan data
‫yang persisten. Kata hati-hati di sini.
‫Alasan kami tidak akan membahas banyak
‫detailnya adalah karena saya tidak merekomendasikan penyebaran Kubernetes
‫pertama Anda melibatkan banyak StatefulSets
‫di dalamnya. Bahkan, idealnya, penyebaran orkestra pertama
‫Anda, orkestra apa saja, baik itu Swarm
‫atau Kubernetes, hanya terlibat dengan stateless dan Anda
‫tahu, tetap sederhana. Mungkin cukup lakukan frontends web
‫Anda atau beberapa API, atau beberapa fitur pekerja, atau sesuatu
‫yang tidak melibatkan database. Bahkan, jika Anda bisa menggunakan basis
‫data cloud, lakukan itu.
‫Saya selalu merekomendasikan untuk mengalihdayakan basis data Anda
‫kecuali Anda memiliki persyaratan khusus yang tidak dapat Anda
‫hindari untuk menjalankan sendiri. Orkestrasi, awalnya, benar-benar dirancang
‫di sekitar wadah agar tidak berubah, dan didistribusikan,
‫dan diganti.
‫Gagasan lengket untuk kewarganegaraan ini akan menambah lebih banyak
‫pekerjaan, dan kompleksitas, dan lebih banyak
‫pengujian untuk Anda. Idealnya, di luar gerbang, Anda tidak
‫perlu khawatir tentang hal ini.
‫Kemudian, begitu Anda jauh lebih nyaman dengan semua hal lain di sekitar
‫Kubernetes, maka Anda dapat kembali dan berkata, sekarang
‫saya ingin mempertimbangkan basis data saya.
‫Bukannya Anda tidak harus menjalankan database dalam kelompok.
‫Itu hanya pekerjaan. Itu lebih sulit.
‫Basis data dan penyimpanan yang persisten selalu lebih sulit dan lebih
‫banyak detail untuk dikerjakan. Ini tip pro saya.
‫Dengan wadah apa pun, Anda dapat menambahkan volume
‫yang sangat mirip dengan yang Anda lakukan di Swarm
‫dan di Docker dan Docker Compose. Anda bisa menambahkan pernyataan volume dalam
‫template di dalam spec. Jika Anda memikirkan file YAML, kami
‫hanya dapat memasukkan volume di sana seperti yang Anda
‫harapkan, dan format dan detail yang tepat
‫ada di sumber daya. Berbeda dengan Docker
‫dan Swarm di mana volumenya dengan wadah, dalam
‫hal ini, secara teknis dengan pod. Ini terhubung ke setiap wadah, atau hanya satu wadah,
‫di pod jika Anda menyuruhnya.
‫Jadi, Anda mengendalikannya di level kontainer, tapi kegigihannya ada pada
‫level pod. Ada fitur
‫yang lebih baru yang merupakan volume persisten.
‫Itu bekerja dengan sesuatu yang lain yang disebut klaim.
‫Ide menarik dengan ini adalah Anda
‫menggunakannya, atau Anda mendefinisikannya, di
‫luar pod. Anda pada dasarnya membuat
‫sumber daya itu sendiri, dan kemudian Anda membuat klaim terhadap
‫sumber daya itu di dalam spesifikasi pod Anda.
‫Alasan ini lebih menarik adalah karena Kubernetes mengambil alih
‫perusahaan, Anda sering memiliki orang yang mengurus penyimpanan,
‫sering kali penyimpanan pihak ketiga, yang bukan tim yang sama yang
‫menjalankan Kubernetes.
‫Mereka akan menjadi orang-orang yang terlibat dalam mengelola dan
‫menciptakan volume persisten ini.
‫Maka itu adalah aplikasi penyebaran yang akan mengatakan,
‫hei saya
‫butuh volume jenis ini. Jadi, saya akan membuat klaim SSD
‫atau kita mungkin perlu penyimpanan RAM, atau mungkin saya perlu NFS, atau
‫apa pun. Penyimpanan itu
‫akan secara otomatis disediakan karena tim penyimpanan
‫sudah mengaturnya di Kubernetes.
‫Itu semacam ide seputar volume persisten.
‫Jika Anda hanya perlu penyimpanan sederhana di
‫satu server sementara untuk pod, maka cukup gunakan atribut
‫volume standar.
‫Satu hal terakhir di
‫sini adalah tentang pembuatan plugin CSI. Dalam sejarah
‫Kubernetes, apa pun yang merupakan penyimpanan pihak ketiga,
‫apakah itu penyimpanan cloud atau penyimpanan vendor pihak
‫ketiga, atau sesuatu yang khusus, semua
‫itu ditambahkan di tree.
‫Itu berarti telah ditambahkan ke biner Kubernet
‫dan dikirim bersama Kubernet.
‫Itu berarti Kubernet datang dengan Amazon dan
‫penyimpanan Azure dibangun langsung.
‫Itu cukup mudah, tetapi menambahkan
‫banyak tantangan.
‫Sebagian besar terkait dengan fakta bahwa vendor penyimpanan
‫sekarang berkontribusi kode ke inti sistem Anda yang bahkan mungkin tidak
‫Anda butuhkan karena Anda hanya dapat menggunakan satu vendor penyimpanan, jadi mengapa
‫semua dari mereka?
‫Juga, vendor penyimpanan kemudian harus mengendalikan siklus rilis mereka di
‫sekitar siklus rilis Kubernetes, dan itu bukan model
‫yang sangat fleksibel.
‫Jadi, industri datang bersama, dan seperti
‫halnya dengan jaringan dan dengan Dockerfiles dan gambar sendiri,
‫itu menciptakan standar. Standar itu adalah CSI.
‫Itu singkatan dari Container Storage Interface.
‫Itu akan menyediakan plugin sekarang sehingga vendor penyimpanan mana
‫pun dapat membuat plugin yang akan Anda instal
‫pada semua node, dan itu akan berbeda berdasarkan
‫pada plugin dan instruksinya.
‫Kemudian, mereka akan beroperasi pada API standar yang disediakan
‫CSI sehingga wadah Anda
‫dapat menggunakan plugin itu untuk sampai ke penyimpanannya.
‫Itu model yang jauh lebih baik, dan lebih fleksibel.
‫Itu semacam masa depan Kubernetes, tapi ini
‫masih sangat baru. Begitu sering dalam contoh,
‫dan bahkan vendor penyimpanan Anda dapat merekomendasikan, tergantung pada
‫jatuh tempo CSI mereka, bahwa Anda menggunakan plugin tradisional mereka, yang
‫dibangun ke dalam Kubernetes dan keluar dari kotak.