Pada hari-hari ketika Kubernetes masih v1.0.0, plugin volume ada. Mereka diperlukan untuk terhubung ke sistem Kubernetes untuk menyimpan data kontainer persisten (permanen). Jumlah mereka kecil, dan di antara yang pertama ada penyedia penyimpanan seperti GCE PD, Ceph, AWS EBS dan lainnya.
Plug-in dikirimkan bersama dengan Kubernetes, yang untuknya mereka mendapatkan namanya - in-tree. Namun, banyak dari set plug-in yang ada tidak cukup. Para pengrajin menambahkan plugin sederhana ke inti Kubernet menggunakan patch, setelah itu mereka membangun Kubernet mereka sendiri dan meletakkannya di server mereka. Namun seiring waktu, pengembang Kubernetes menyadari bahwa
ikan itu tidak dapat dipecahkan. Orang-orang membutuhkan
joran . Dan dalam rilis Kubernetes v1.2.0, muncul ...
Plugin Flexvolume: pancing minimal
Pengembang Kubernetes menciptakan plugin FlexVolume, yang merupakan pengikat logis variabel dan metode untuk bekerja dengan driver Flexvolume pihak ketiga.
Mari kita berhenti dan melihat lebih dekat apa driver FlexVolume itu. Ini adalah
file yang dapat dieksekusi tertentu (
file biner, skrip Python, skrip Bash, dll.), Yang, ketika dieksekusi, mengambil argumen baris perintah dan mengembalikan pesan dengan bidang yang sebelumnya diketahui dalam format JSON. Dengan konvensi, argumen baris perintah pertama selalu menjadi metode, dan argumen lainnya adalah parameternya.
Skema koneksi CIFS Berbagi di OpenShift. Driver Flexvolume - Tepat di TengahSeperangkat metode minimum terlihat seperti ini:
flexvolume_driver mount # pod' # : { "status": "Success"/"Failure"/"Not supported", "message": " ", } flexvolume_driver unmount # pod' # : { "status": "Success"/"Failure"/"Not supported", "message": " ", } flexvolume_driver init # # : { "status": "Success"/"Failure"/"Not supported", "message": " ", // , attach/deatach "capabilities":{"attach": True/False} }
Menggunakan metode
attach dan
detach akan menentukan skenario yang menurutnya di masa depan kubelet akan bertindak ketika pengemudi dipanggil. Ada juga
expandfs dan
expandfs expandvolume khusus yang bertanggung jawab untuk mengubah ukuran volume secara dinamis.
Sebagai contoh perubahan yang
expandvolume metode
expandvolume , dan dengan itu kemampuan untuk melakukan pengubahan ukuran volume secara real time, Anda dapat memeriksa
permintaan tarik kami di Operator Rook Ceph.
Berikut adalah contoh implementasi driver Flexvolume untuk bekerja dengan NFS:
usage() { err "Invalid usage. Usage: " err "\t$0 init" err "\t$0 mount <mount dir> <json params>" err "\t$0 unmount <mount dir>" exit 1 } err() { echo -ne $* 1>&2 } log() { echo -ne $* >&1 } ismounted() { MOUNT=`findmnt -n ${MNTPATH} 2>/dev/null | cut -d' ' -f1` if [ "${MOUNT}" == "${MNTPATH}" ]; then echo "1" else echo "0" fi } domount() { MNTPATH=$1 NFS_SERVER=$(echo $2 | jq -r '.server') SHARE=$(echo $2 | jq -r '.share') if [ $(ismounted) -eq 1 ] ; then log '{"status": "Success"}' exit 0 fi mkdir -p ${MNTPATH} &> /dev/null mount -t nfs ${NFS_SERVER}:/${SHARE} ${MNTPATH} &> /dev/null if [ $? -ne 0 ]; then err "{ \"status\": \"Failure\", \"message\": \"Failed to mount ${NFS_SERVER}:${SHARE} at ${MNTPATH}\"}" exit 1 fi log '{"status": "Success"}' exit 0 } unmount() { MNTPATH=$1 if [ $(ismounted) -eq 0 ] ; then log '{"status": "Success"}' exit 0 fi umount ${MNTPATH} &> /dev/null if [ $? -ne 0 ]; then err "{ \"status\": \"Failed\", \"message\": \"Failed to unmount volume at ${MNTPATH}\"}" exit 1 fi log '{"status": "Success"}' exit 0 } op=$1 if [ "$op" = "init" ]; then log '{"status": "Success", "capabilities": {"attach": false}}' exit 0 fi if [ $# -lt 2 ]; then usage fi shift case "$op" in mount) domount $* ;; unmount) unmount $* ;; *) log '{"status": "Not supported"}' exit 0 esac exit 1
Jadi, setelah menyiapkan file yang dapat dieksekusi yang sebenarnya, Anda perlu
mengeluarkan driver di kluster Kubernetes . Pengemudi harus terletak di setiap node cluster sesuai dengan jalur yang telah ditentukan. Secara default telah dipilih:
/usr/libexec/kubernetes/kubelet-plugins/volume/exec/__~_/... tetapi menggunakan distribusi Kubernet yang berbeda (OpenShift, Rancher ...) jalurnya mungkin berbeda.
Masalah Flexvolume: bagaimana cara melemparkan pancing?
Menempatkan driver Flexvolume pada node cluster ternyata menjadi tugas yang tidak sepele. Setelah melakukan operasi secara manual, mudah untuk menghadapi situasi ketika node baru muncul di cluster: karena penambahan node baru, penskalaan horizontal otomatis, atau, lebih buruk lagi, mengganti node karena kegagalan fungsi. Dalam hal ini, tidak
mungkin untuk bekerja dengan penyimpanan pada node-node ini sampai Anda secara manual menambahkan driver Flexvolume ke mereka dengan cara yang sama.
Solusi untuk masalah ini adalah salah satu primitif Kubernetes -
DaemonSet . Ketika node baru muncul di cluster, secara otomatis akan mendapatkan pod dari DaemonSet kami, yang mana volume lokal dilampirkan di sepanjang jalan untuk menemukan driver Flexvolume. Setelah pembuatan berhasil, pod menyalin file yang diperlukan agar driver dapat bekerja pada disk.
Berikut adalah contoh DaemonSet untuk meletakkan plugin Flexvolume:
apiVersion: extensions/v1beta1 kind: DaemonSet metadata: name: flex-set spec: template: metadata: name: flex-deploy labels: app: flex-deploy spec: containers: - image: <deployment_image> name: flex-deploy securityContext: privileged: true volumeMounts: - mountPath: /flexmnt name: flexvolume-mount volumes: - name: flexvolume-mount hostPath: path: <host_driver_directory>
... dan contoh skrip Bash untuk meletakkan driver Flexvolume:
Penting untuk tidak lupa bahwa operasi penyalinan
tidak bersifat atomik . Sangat mungkin kubelet akan mulai menggunakan driver sebelum proses persiapannya selesai, yang akan menyebabkan kesalahan dalam sistem. Pendekatan yang benar adalah dengan menyalin file driver terlebih dahulu dengan nama yang berbeda, dan kemudian menggunakan operasi penggantian nama atom.
Skema bekerja dengan Ceph dalam pernyataan Rook: driver Flexvolume pada diagram ada di dalam agen RookMasalah berikutnya ketika menggunakan driver Flexvolume adalah bahwa untuk sebagian besar penyimpanan
, perangkat lunak yang diperlukan untuk ini harus diinstal pada node cluster (misalnya, paket ceph-common untuk Ceph). Awalnya, plugin Flexvolume tidak dirancang untuk mengimplementasikan sistem yang kompleks tersebut.
Solusi asli untuk masalah ini dapat dilihat dalam penerapan driver Flexvolume dari operator Rook:
Driver itu sendiri dirancang sebagai klien RPC. Soket IPC untuk komunikasi terletak di direktori yang sama dengan driver itu sendiri. Kami ingat bahwa untuk menyalin file driver sebaiknya menggunakan DaemonSet, yang menghubungkan direktori dengan driver sebagai volume. Setelah menyalin file driver rook yang diperlukan, pod ini tidak mati, tetapi terhubung ke soket IPC melalui volume yang terpasang sebagai server RPC yang lengkap. Paket ceph-common sudah diinstal di dalam wadah pod. Soket IPC memberikan keyakinan bahwa kubelet akan berkomunikasi dengan pod tertentu yang terletak di node yang sama. Semuanya cerdik itu sederhana! ..
Selamat tinggal, plugin kami yang penuh kasih sayang!
Pengembang Kubernetes telah menemukan bahwa jumlah plugin penyimpanan di dalam kernel adalah dua puluh. Dan perubahan di masing-masing dari mereka entah bagaimana melewati siklus rilis Kubernetes penuh.
Ternyata untuk menggunakan versi baru plugin untuk penyimpanan,
Anda perlu memperbarui seluruh cluster . Selain itu, Anda mungkin terkejut bahwa versi baru Kubernetes tiba-tiba menjadi tidak kompatibel dengan kernel Linux yang digunakan ... Dan karena itu, Anda menghapus air mata dan mengertakkan gigi Anda dan berkoordinasi dengan pihak berwenang dan pengguna waktu untuk memperbarui kernel Linux dan cluster Kubernetes. Dengan kemungkinan downtime dalam penyediaan layanan.
Situasinya lebih dari lucu, bukan? Menjadi jelas bagi seluruh masyarakat bahwa pendekatan itu tidak berhasil. Dengan keputusan yang kuat, pengembang Kubernetes mengumumkan bahwa plugin penyimpanan baru tidak akan lagi diterima ke dalam kernel. Untuk yang lainnya, seperti yang telah kita ketahui, dalam penerapan plugin Flexvolume sejumlah kekurangan terungkap ...
Sekali dan untuk semua, plugin yang ditambahkan terakhir untuk volume di Kubernetes, CSI, dipanggil untuk menutup masalah dengan gudang data yang persisten. Versi alpha-nya, lebih umum disebut sebagai Out-of-Tree CSI Volume Plugins, diumumkan di
Kubernetes 1.9 .
Container Storage Interface, atau CSI 3000 spinning!
Pertama-tama, saya ingin mencatat bahwa CSI bukan hanya plugin volume, tetapi
standar nyata
untuk membuat komponen khusus untuk bekerja dengan gudang data . Diasumsikan bahwa sistem orkestrasi wadah, seperti Kubernetes dan Mesos, harus "belajar" bagaimana bekerja dengan komponen yang diimplementasikan sesuai dengan standar ini. Dan sekarang Kubernetes sudah belajar.
Apakah perangkat plugin CSI di Kubernetes? Plugin CSI bekerja dengan driver khusus (
driver CSI ) yang ditulis oleh pengembang pihak ketiga. Pengandar CSI di Kubernetes setidaknya harus terdiri dari dua komponen (pod):
- Controller - mengelola penyimpanan persisten eksternal. Ini diimplementasikan sebagai server gRPC yang primitif
StatefulSet digunakan. - Node - bertanggung jawab untuk memasang toko persisten ke node cluster. Ini juga diimplementasikan sebagai server gRPC, tetapi primitif
DaemonSet digunakan untuk itu.
Alur Kerja Plugin Kubernetes CSIAnda dapat mempelajari beberapa detail CSI lainnya, misalnya, dari artikel “
Understanding the CSI ”,
terjemahan yang kami terbitkan setahun yang lalu.
Keuntungan dari implementasi semacam itu
- Untuk hal-hal dasar - misalnya, untuk mendaftarkan driver untuk sebuah simpul - pengembang Kubernetes telah mengimplementasikan serangkaian kontainer. Anda tidak perlu lagi membuat respons JSON dengan kemampuan sendiri, seperti yang dilakukan untuk plugin Flexvolume.
- Alih-alih "menyelipkan" node file yang dapat dieksekusi, kami sekarang meletakkan pod di cluster. Inilah yang awalnya kami harapkan dari Kubernetes: semua proses terjadi di dalam kontainer yang digunakan menggunakan primitif Kubernetes.
- Untuk mengimplementasikan driver yang kompleks, Anda tidak perlu lagi mengembangkan server RPC dan klien RPC. Klien untuk kami diimplementasikan oleh pengembang Kubernetes.
- Melewati argumen untuk bekerja dengan protokol gRPC jauh lebih mudah, fleksibel, dan lebih dapat diandalkan daripada meneruskannya melalui argumen baris perintah. Untuk memahami cara menambahkan dukungan untuk metrik penggunaan volume ke CSI dengan menambahkan metode gRPC standar, Anda dapat memeriksa permintaan tarik kami untuk driver vsphere-csi.
- Komunikasi berlangsung melalui soket IPC agar tidak bingung apakah pod kubelet mengirim permintaan atau tidak.
Apakah daftar ini mengingatkan Anda pada sesuatu? Kelebihan CSI adalah
solusi untuk masalah yang sangat tidak diperhitungkan saat mengembangkan plugin Flexvolume.
Kesimpulan
CSI sebagai standar untuk menerapkan plugin khusus untuk berinteraksi dengan gudang data telah diterima dengan sangat hangat oleh komunitas. Selain itu, karena kelebihan dan fleksibilitasnya, driver CSI dibuat bahkan untuk repositori seperti Ceph atau AWS EBS, plugin untuk bekerja dengan yang ditambahkan dalam versi pertama Kubernetes.
Pada awal 2019, plugin di dalam pohon
sudah tidak digunakan lagi . Direncanakan untuk terus mendukung plugin Flexvolume, tetapi tidak akan ada pengembangan fungsionalitas baru untuknya.
Kami sendiri sudah memiliki pengalaman menggunakan ceph-csi, vsphere-csi dan siap untuk menambah daftar ini! Sejauh ini, CSI berupaya dengan tugas yang diberikan padanya dengan keras, dan di sana kami menunggu dan melihat.
Jangan lupa bahwa semua yang baru adalah yang sudah dipikirkan ulang dengan baik!
PS
Baca juga di blog kami: