Ada beberapa cara untuk mengonfigurasi penyimpanan data untuk aplikasi yang berjalan di cluster Kubernetes. Beberapa dari mereka sudah ketinggalan jaman, yang lain muncul baru-baru ini. Pada artikel ini, kita akan melihat konsep tiga opsi untuk menghubungkan sistem penyimpanan, termasuk yang terbaru - menghubungkan melalui Antarmuka Penyimpanan Kontainer.
Metode 1: Tentukan PV di manifes pod
Manifes tipikal yang menjelaskan sebuah pod di cluster Kubernetes:
Bagian manifes yang menjelaskan volume mana yang terhubung dan di mana disorot dalam warna.
Pada bagian volumeMount tunjukkan titik pemasangan (mountPath) - di direktori mana di dalam wadah volume permanen akan dipasang, serta nama volumenya.
Pada bagian x mencantumkan semua volume yang digunakan di pod. Tentukan nama setiap volume, serta jenisnya (dalam kasus kami: awsElasticBlockStore) dan parameter koneksi. Parameter mana yang tercantum dalam manifes bergantung pada jenis volume.
Volume yang sama dapat dipasang secara bersamaan di beberapa kontainer pod. Dengan cara ini, proses aplikasi yang berbeda dapat mengakses data yang sama.
Metode koneksi ini ditemukan sejak awal, ketika Kubernetes masih dalam masa pertumbuhan, dan saat ini metode tersebut sudah ketinggalan zaman.
Ada beberapa masalah saat menggunakannya:
- semua volume harus dibuat secara manual; Kubernetes tidak dapat membuat apa pun untuk kami;
- parameter akses untuk setiap volume bersifat unik, dan parameter tersebut harus ditentukan dalam manifes semua pod yang menggunakan volume tersebut;
- untuk mengubah sistem penyimpanan (misalnya, berpindah dari AWS ke Google Cloud), Anda perlu mengubah pengaturan dan jenis volume yang dipasang di semua manifes.
Semua ini sangat merepotkan, jadi pada kenyataannya metode ini hanya digunakan untuk menghubungkan beberapa jenis volume khusus: configMap, secret, blankDir, hostPath:
-
configMap dan secret adalah volume layanan yang memungkinkan Anda membuat volume dengan file dari manifes Kubernetes di dalam container.
-
kosongDir adalah volume sementara, dibuat hanya untuk seumur hidup pod. Nyaman digunakan untuk menguji atau menyimpan data sementara. Ketika sebuah pod dihapus, volume kosongDir juga terhapus dan semua data hilang.
-
hostPath - memungkinkan Anda memasang direktori apa pun di disk lokal server tempat aplikasi berjalan di dalam container dengan aplikasi tersebut, termasuk /etc/kubernetes. Ini adalah fitur yang tidak aman, sehingga kebijakan keamanan biasanya melarang penggunaan volume jenis ini. Jika tidak, aplikasi penyerang akan dapat memasang direktori HTC Kubernetes di dalam containernya dan mencuri semua sertifikat cluster. Biasanya, volume hostPath hanya diperbolehkan untuk digunakan oleh aplikasi sistem yang berjalan di namespace kube-system.
diberikan dalam dokumentasi.
Metode 2. Koneksi ke perapian SC/PVC/PV
Metode koneksi alternatif adalah konsep kelas Storage, PersistentVolumeClaim, PersistentVolume.
Kelas penyimpanan menyimpan parameter koneksi ke sistem penyimpanan data.
Klaim Volume Persisten menjelaskan persyaratan untuk apa yang dibutuhkan aplikasi.
PersistenVolume menyimpan parameter akses dan status volume.
Inti dari idenya: dalam manifes pod, mereka menunjukkan volume bertipe PersistentVolumeClaim dan menunjukkan nama entitas ini di parameter ClaimName.
Manifes PersistentVolumeClaim menjelaskan persyaratan volume data yang diperlukan aplikasi. Termasuk:
- ukuran disk;
- metode akses: ReadWriteOnce atau ReadWriteMany;
- tautan ke kelas Penyimpanan - di sistem penyimpanan data mana kita ingin membuat volume.
Manifes kelas Penyimpanan menyimpan jenis dan parameter koneksi ke sistem penyimpanan. Kubus membutuhkan mereka untuk memasang volume pada simpulnya.
Manifes PersistentVolume menunjukkan kelas Penyimpanan dan parameter akses untuk volume tertentu (ID volume, jalur, dll.).
Saat membuat PVC, Kubernetes melihat ukuran volume dan kelas Penyimpanan apa yang diperlukan, lalu memilih PersistentVolume gratis.
Jika PV tersebut tidak tersedia, Kubernetes dapat meluncurkan program khusus - Penyedia (namanya ditunjukkan di kelas Penyimpanan). Program ini terhubung ke sistem penyimpanan, membuat volume dengan ukuran yang diperlukan, menerima pengidentifikasi dan membuat manifes PersistentVolume di cluster Kubernetes, yang dikaitkan dengan PersistentVolumeClaim.
Semua abstraksi yang banyak ini memungkinkan Anda menghapus informasi tentang sistem penyimpanan mana yang digunakan aplikasi, dari tingkat manifes aplikasi hingga tingkat administrasi.
Semua parameter untuk menghubungkan ke sistem penyimpanan data terletak di kelas Penyimpanan, yang menjadi tanggung jawab administrator cluster. Yang perlu Anda lakukan saat berpindah dari AWS ke Google Cloud adalah mengubah nama kelas Storage menjadi PVC di manifes aplikasi. Volume Persistensi untuk penyimpanan data akan dibuat di cluster secara otomatis menggunakan program Penyedia.
Metode 3: Antarmuka Penyimpanan Kontainer
Semua kode yang berinteraksi dengan berbagai sistem penyimpanan merupakan bagian dari inti Kubernetes. Rilis perbaikan bug atau fungsionalitas baru terkait dengan rilis baru; kode harus diubah untuk semua versi Kubernetes yang didukung. Semua ini sulit untuk dipertahankan dan menambah fungsionalitas baru.
Untuk mengatasi masalah ini, pengembang dari Cloud Foundry, Kubernetes, Mesos dan Docker membuat Container Storage Interface (CSI) - antarmuka terpadu sederhana yang menggambarkan interaksi sistem manajemen container dan driver khusus (CSI Driver) yang bekerja dengan spesifik sistem penyimpanan. Semua kode untuk interaksi dengan sistem penyimpanan dipindahkan dari inti Kubernetes ke sistem terpisah.
.
Biasanya, Driver CSI terdiri dari dua komponen: Plugin Node dan plugin Pengontrol.
Plugin Node berjalan di setiap node dan bertanggung jawab untuk memasang volume dan melakukan operasi pada mereka. Plugin Pengontrol berinteraksi dengan sistem penyimpanan: membuat atau menghapus volume, memberikan hak akses, dll.
Untuk saat ini, driver lama tetap berada di kernel Kubernetes, namun sudah tidak disarankan lagi untuk digunakan dan setiap orang disarankan untuk menginstal Driver CSI khusus untuk sistem yang akan digunakannya.
Inovasi ini mungkin membuat takut mereka yang sudah terbiasa mengatur penyimpanan data melalui kelas Storage, namun nyatanya tidak ada hal buruk yang terjadi. Bagi programmer, tidak ada yang benar-benar berubah - mereka hanya bekerja dengan nama kelas Storage, dan akan terus melakukannya. Untuk administrator, instalasi diagram helm telah ditambahkan dan struktur pengaturan telah diubah. Jika sebelumnya pengaturannya dimasukkan langsung ke kelas Storage, sekarang harus diatur terlebih dahulu di helm chart, lalu di kelas Storage. Jika Anda memeriksanya, tidak ada hal buruk yang terjadi.
Mari kita ambil contoh untuk melihat manfaat yang bisa Anda peroleh dengan beralih menghubungkan sistem penyimpanan Ceph menggunakan driver CSI.
Saat bekerja dengan Ceph, plugin CSI menyediakan lebih banyak opsi untuk bekerja dengan sistem penyimpanan daripada driver bawaan.
- Pembuatan disk dinamis. Biasanya disk RBD hanya digunakan dalam mode RWO, tetapi CSI untuk Ceph mengizinkannya digunakan dalam mode RWX. Beberapa pod pada node yang berbeda dapat memasang disk RDB yang sama pada nodenya dan bekerja dengannya secara paralel. Agar adil, tidak semuanya begitu cerah - disk ini hanya dapat dihubungkan sebagai perangkat blok, yang berarti Anda harus menyesuaikan aplikasi untuk bekerja dengannya dalam mode akses ganda.
- Membuat snapshot. Di cluster Kubernetes, Anda dapat membuat manifes dengan persyaratan untuk membuat snapshot. Plugin CSI akan melihatnya dan mengambil snapshot dari disk. Berdasarkan hal tersebut, Anda dapat membuat cadangan atau salinan PersistentVolume.
- Meningkatkan ukuran disk pada penyimpanan dan PersistentVolume di cluster Kubernetes.
- Kuota. Driver CephFS yang dibangun di Kubernetes tidak mendukung kuota, tetapi plugin CSI baru dengan Ceph Nautilus terbaru dapat mengaktifkan kuota pada partisi CephFS.
- Metrik. Plugin CSI dapat memberi Prometheus berbagai metrik tentang volume mana yang terhubung, komunikasi apa yang sedang berlangsung, dll.
- Sadar topologi. Memungkinkan Anda menentukan dalam manifes bagaimana cluster didistribusikan secara geografis, dan menghindari menghubungkan sistem penyimpanan yang berlokasi di Amsterdam ke pod yang berjalan di London.
Cara menghubungkan Ceph ke cluster Kubernetes melalui CSI, lihat . Anda juga dapat berlangganan , yang akan diluncurkan pada 15 Oktober.
Penulis artikel: Sergey Bondarev, praktik arsitek di Southbridge, Administrator Kubernetes Bersertifikat, salah satu pengembang kubespray.
Sedikit Post Scriptum bukan untuk iklan, tapi untuk keuntungan...
PS Sergey Bondarev memimpin dua kursus intensif: diperbarui 28-30 September dan lanjutan 14-16 Oktober.
Sumber: www.habr.com