Ketika orkestra kontainer seperti Kubernetes tiba, pendekatan untuk mengembangkan dan menggunakan aplikasi berubah secara dramatis. Layanan Microsoft telah muncul, dan untuk pengembang, logika aplikasi tidak lagi terhubung dengan infrastruktur: buat aplikasi untuk Anda sendiri dan tawarkan fungsi baru.
Kubernet abstrak dari komputer fisik yang dikontrolnya. Katakan saja berapa banyak memori dan kekuatan pemrosesan yang Anda butuhkan - dan Anda akan mendapatkan segalanya. Infrastruktur? Tidak, tidak terdengar.
Mengelola gambar Docker, Kubernetes, dan aplikasi membuatnya portabel. Setelah mengembangkan aplikasi kontainer dengan Kubernetes, Anda dapat menyebarkannya di mana saja: ke cloud terbuka, secara lokal atau ke lingkungan hybrid - tanpa mengubah kode.
Kami menyukai Kubernet untuk skalabilitas, portabilitas, dan pengelolaan, tetapi tidak menyimpan keadaan. Tetapi kami memiliki hampir semua aplikasi stateful, yaitu, mereka membutuhkan penyimpanan eksternal.
Kubernetes memiliki arsitektur yang sangat dinamis. Wadah dibuat dan dihancurkan tergantung pada beban dan instruksi dari pengembang. Polong dan wadah adalah penyembuhan dan replikasi diri. Mereka pada dasarnya fana.
Penyimpanan eksternal terlalu sulit untuk variabilitas seperti itu. Itu tidak mematuhi aturan penciptaan dan penghancuran yang dinamis.
Hanya perlu menggunakan aplikasi stateful di infrastruktur lain: di cloud lain di sana, secara lokal atau dalam model hybrid - bagaimana ia memiliki masalah portabilitas. Penyimpanan eksternal dapat diikat ke cloud tertentu.
Tetapi hanya di penyimpanan ini untuk aplikasi cloud iblis sendiri akan mematahkan kakinya. Dan pahami makna fiktif dan makna terminologi penyimpanan di Kubernetes . Dan ada repositori Kubernet sendiri, platform open source, layanan terkelola atau berbayar ...
Berikut adalah beberapa contoh penyimpanan cloud CNCF :
Tampaknya menyebarkan database di Kubernetes - Anda hanya perlu memilih solusi yang sesuai, kemas dalam wadah untuk bekerja pada disk lokal dan menyebarkannya ke cluster sebagai beban kerja berikutnya. Tetapi database memiliki kekhasan tersendiri, jadi berpikir bukanlah es.
Kontainer - mereka begitu berbatu sehingga mereka tidak mempertahankan negara mereka. Itu sebabnya mereka sangat mudah untuk memulai dan berhenti. Dan karena tidak ada apa pun untuk disimpan dan ditransfer, cluster tidak repot dengan operasi baca dan salin.
Anda harus menyimpan status dengan database. Jika database yang digunakan untuk cluster dalam wadah tidak bermigrasi di mana pun dan tidak memulai terlalu sering, fisika penyimpanan data ikut berperan. Idealnya, kontainer yang menggunakan data harus dalam perapian yang sama dengan database.
Dalam beberapa kasus, basis data, tentu saja, dapat digunakan untuk suatu wadah. Dalam lingkungan pengujian atau dalam tugas-tugas di mana ada sedikit data, basis data nyaman hidup dalam kelompok.
Produksi biasanya memerlukan penyimpanan eksternal.
Kubernet berkomunikasi dengan repositori melalui antarmuka bidang kontrol. Mereka menautkan Kubernetes ke penyimpanan eksternal. Penyimpanan eksternal yang melekat pada Kubernet disebut plugins volume. Dengan mereka, Anda dapat menyimpan dan memindahkan penyimpanan secara abstrak.
Plugin volume yang digunakan untuk dibuat , ditautkan, dikompilasi, dan dikirim menggunakan basis kode Kubernetes. Pengembang ini sangat terbatas dan memerlukan pemeliharaan tambahan: jika Anda ingin menambah repositori baru, silakan ubah basis kode Kubernetes.
Sekarang gunakan plugin volume ke kluster - Saya tidak mau. Dan Anda tidak perlu menggali basis kode. Terima kasih kepada CSI dan Flexvolume.
Penyimpanan Asli Kubernetes
Bagaimana Kubernet mengatasi masalah penyimpanan? Ada beberapa solusi: opsi singkat, penyimpanan persisten dalam volume persisten, kueri Klaim Volume Persisten, kelas penyimpanan, atau StatefulSets. Cari tahu, secara umum.
Persistent Volume (PV) adalah unit penyimpanan yang disiapkan oleh administrator. Mereka tidak bergantung pada perapian dan kehidupan singkat mereka.
Klaim Volume Persisten (PVC) adalah permintaan penyimpanan, mis. PV. Dengan PVC, Anda dapat mengikat penyimpanan ke sebuah simpul, dan simpul ini akan menggunakannya.
Anda dapat bekerja dengan penyimpanan secara statis atau dinamis.
Dengan pendekatan statis, administrator menyiapkan PV yang seharusnya dilayani terlebih dahulu, sebelum permintaan, dan PV ini secara manual terikat ke pod tertentu menggunakan PVC eksplisit.
Dalam praktiknya, PV yang didefinisikan secara khusus tidak kompatibel dengan struktur portabel Kubernetes - penyimpanan tergantung pada lingkungan, seperti AWS EBS atau drive permanen GCE. Untuk mengikat secara manual, Anda perlu menunjuk ke repositori tertentu di file YAML.
Pendekatan statis umumnya bertentangan dengan filosofi Kubernetes: CPU dan memori tidak dialokasikan sebelumnya dan tidak terikat pada polong atau wadah. Mereka dikeluarkan secara dinamis.
Untuk penyediaan dinamis, kami menggunakan kelas penyimpanan. Administrator cluster tidak perlu membuat PV terlebih dahulu. Ini menciptakan beberapa profil penyimpanan, seperti templat. Ketika pengembang membuat permintaan PVC, pada saat permintaan tersebut, salah satu pola ini dibuat dan dilampirkan ke perapian.
Jadi, dalam istilah yang paling umum, Kubernetes bekerja dengan penyimpanan eksternal. Ada banyak pilihan lain.
CSI - Antarmuka Penyimpanan Kontainer
Ada hal seperti itu - Antarmuka Penyimpanan Kontainer . CSI dibuat oleh kelompok kerja kubah CNCF, yang memutuskan untuk mendefinisikan antarmuka penyimpanan kontainer standar sehingga driver vault bekerja dengan orkestra apa pun.
Spesifikasi CSI sudah disesuaikan untuk Kubernetes, dan ada banyak plugin driver untuk penerapan di cluster Kubernetes. Anda harus mengakses repositori melalui driver volume yang sesuai dengan CSI - gunakan tipe volume csi di Kubernetes.
Dengan CSI, penyimpanan dapat dianggap sebagai beban kerja lain untuk kontainerisasi dan penyebaran ke kluster Kubernetes.
Untuk lebih jelasnya, dengarkan Jie Yu berbicara tentang CSI di podcast kami .
Proyek sumber terbuka
Alat dan proyek untuk teknologi cloud dengan cepat berlipat ganda, dan bagian yang adil dari proyek sumber terbuka - yang logis - menyelesaikan salah satu masalah produksi utama: bekerja dengan penyimpanan dalam arsitektur cloud.
Yang paling populer di antara mereka adalah Ceph dan Rook.
Ceph adalah kluster penyimpanan terdistribusi yang dikelola secara dinamis dengan penskalaan horizontal. Ceph menyediakan abstraksi logis untuk sumber daya penyimpanan. Ia tidak memiliki satu titik kegagalan, ia mengelola dirinya sendiri dan bekerja berdasarkan perangkat lunak. Ceph menyediakan antarmuka untuk menyimpan blok, objek, dan file secara bersamaan untuk satu cluster penyimpanan.
Ceph memiliki arsitektur yang sangat kompleks dengan RADOS, pustakawan, RADOSGW, RDB, algoritma CRUSH dan berbagai komponen (monitor, OSD, MDS). Mari kita tidak masuk jauh ke dalam arsitektur, cukup untuk memahami bahwa Ceph adalah cluster penyimpanan terdistribusi yang menyederhanakan skalabilitas, menghilangkan satu titik kegagalan tanpa mengorbankan kinerja dan menyediakan penyimpanan tunggal dengan akses ke objek, blok, dan file.
Secara alami, Ceph diadaptasi untuk cloud. Anda bisa menggunakan cluster Ceph dengan cara yang berbeda, misalnya, menggunakan Ansible atau ke cluster Kubernetes melalui CSI dan PVC.
Arsitektur Ceph
Rook adalah proyek lain yang menarik dan populer. Ini menggabungkan Kubernetes dengan komputasi dan Ceph dengan repositori menjadi satu cluster.
Rook adalah orkestrator penyimpanan cloud yang melengkapi Kubernetes. Mereka mengemas Ceph ke dalam wadah dengannya dan menggunakan logika manajemen kluster untuk operasi Ceph yang andal di Kubernetes. Rook mengotomatiskan penyebaran, bootstrap, tuning, penskalaan, penyeimbangan ulang - secara umum, semua yang dilakukan admin cluster.
Dengan Rook, cluster Ceph dapat digunakan dari yaml, seperti Kubernetes. Dalam file ini, administrator menguraikan apa yang dia butuhkan di cluster. Rook meluncurkan sebuah cluster dan mulai memantau secara aktif. Ini adalah sesuatu seperti operator atau pengontrol - ini memastikan bahwa semua persyaratan dari yaml terpenuhi. Rook berfungsi dengan siklus sinkronisasi - ia melihat keadaan dan mengambil tindakan jika ada penyimpangan.
Dia tidak memiliki kondisi permanen dan tidak perlu dikendalikan. Itu ada dalam semangat Kubernetes.
Rook, yang menggabungkan Ceph dan Kubernetes, adalah salah satu solusi penyimpanan cloud paling populer: 4.000 bintang di Github, 16,3 juta unduhan dan lebih dari seratus kontributor.
Proyek Rook telah diterima di CNCF, dan baru-baru ini berakhir di inkubator .
Bassam Tabara akan memberi tahu Anda lebih banyak tentang Rook di episode repositori Kubernetes kami .
Jika aplikasi memiliki masalah, Anda perlu mengetahui persyaratan dan membuat sistem atau mengambil alat yang diperlukan. Ini juga berlaku untuk penyimpanan cloud. Dan meskipun masalahnya bukan dari yang sederhana, alat dan pendekatan telah gagal. Teknologi cloud terus berkembang, dan solusi baru pasti akan menunggu kita.