Persistent Volume | Kubernetes

Information in this document may be out of date
This document has an older update date than the original, so the information it contains may be out of date. If you're able to read English, see the English version for the most up-to-date information: Persistent Volumes
Dokumen ini menjelaskan kondisi terkini dari PersistentVolumes pada Kubernetes. Disarankan telah memiliki familiaritas dengan volume.
Mengelola penyimpanan adalah hal yang berbeda dengan mengelola komputasi. Sub-sistem PersistentVolume (PV) menyediakan API untuk para pengguna dan administrator yang mengabstraksi detail-detail tentang bagaimana penyimpanan disediakan dari bagaimana penyimpanan dikonsumsi. Untuk melakukan ini, kami mengenalkan dua sumber daya API baru: PersistentVolume (PV) dan PersistentVolumeClaim (PVC).
Sebuah PersistentVolume (PV) adalah suatu bagian dari penyimpanan pada klaster yang telah disediakan oleh seorang administrator. PV merupakan sebuah sumber daya pada klaster sama halnya dengan node yang juga merupakan sumber daya klaster. PV adalah volume plugin seperti Volumes, tetapi memiliki siklus hidup yang independen dari pod individual yang menggunakan PV tersebut. Objek API ini menangkap detail-detail implementasi dari penyimpanan, seperti NFS, iSCSI, atau sistem penyimpanan yang spesifik pada penyedia layanan cloud.
Sebuah PersistentVolumeClaim (PVC) merupakan permintaan penyimpanan oleh pengguna. PVC mirip dengan sebuah pod. Pod mengonsumsi sumber daya node dan PVC mengonsumsi sumber daya PV. Pods dapat meminta taraf-taraf spesifik dari sumber daya (CPU dan Memory). Klaim dapat meminta ukuran dan mode akses yang spesifik (seperti, dapat dipasang sekali sebagai read/write atau lain kali sebagai read-only).
Meskipun PersistentVolumeClaims mengizinkan pengguna untuk mengkonsumsi sumber daya penyimpanan abstrak, pada umumnya para pengguna membutuhkan PersistentVolumes dengan properti yang bermacam-macam, seperti performa, untuk mengatasi masalah yang berbeda. Para administrator klaster harus dapat menawarkan berbagai macam PersistentVolumes yang berbeda tidak hanya pada ukuran dan mode akses, tanpa memaparkan detail-detail bagaimana cara volume tersebut diimplementasikan kepada para pengguna. Untuk mengatasi hal ini maka dibutuhkan sumber daya StorageClass.
Silakan lihat panduan mendetail dengan contoh-contoh yang sudah berjalan.
PV adalah sumber daya dalam sebuah klaster. PVC adalah permintaan terhadap sumber daya tersebut dan juga berperan sebagai pemeriksaan klaim dari sumber daya yang diminta. Interaksi antara PV dan PVC mengikuti siklus hidup berikut ini:
Ada dua cara untuk menyediakan PV: secara statis atau dinamis.
Seorang administrator klaster membuat beberapa PV. PV yang telah dibuat membawa detail-detail dari penyimpanan yang sesungguhnya tersedia untuk digunakan oleh pengguna klaster. PV tersebut ada pada Kubernetes API dan siap untuk digunakan.
Ketika tidak ada PV statis yang dibuat oleh administrator yang sesuai dengan PersistentVolumeClaim (PVC) yang dibuat oleh pengguna, klaster akan mencoba untuk menyediakan volume khusus sesuai permintaan PVC. Penyediaan dinamis ini berbasis StorageClass: artinya PVC harus meminta sebuah storage class dan storage class tersebut harus sudah dibuat dan dikonfigurasi oleh administrator agar penyediaan dinamis bisa terjadi. Klaim yang meminta PV dengan storage class "" secara efektif telah menonaktifkan penyediaan dinamis.
Untuk mengaktifkan penyediaan storage dinamis berdasarkan storage class, administrator klaster harus mengaktifkan admission controller DefaultStorageClass pada API server. Hal ini dapat dilakukan, dengan cara memastikan DefaultStorageClass ada di antara urutan daftar value yang dibatasi koma untuk flag --enable-admission-plugins pada komponen API server. Untuk informasi lebih lanjut mengenai flag perintah pada API server, silakan cek dokumentasi, kube-apiserver.
Seorang pengguna membuat, atau telah membuat (dalam kasus penyediaan dinamis), sebuah PersistentVolumeClaim (PVC) dengan jumlah penyimpanan spesifik yang diminta dan dengan mode akses tertentu. Sebuah control loop pada master akan melihat adanya PVC baru, mencari PV yang cocok (jika memungkinkan), dan mengikat PVC dengan PV tersebut. Jika sebuah PV disediakan secara dinamis untuk sebuah PVC baru, loop tersebut akan selalu mengikat PV tersebut pada PVC yang baru dibuat itu. Jika tidak, pengguna akan selalu mendapatkan setidaknya apa yang dimintanya, tetapi volume tersebut mungkin lebih dari apa yang diminta sebelumnya. Setelah terikat, ikatan PersistentVolumeClaim (PVC) bersifat eksklusif, terlepas dari bagaimana caranya mereka bisa terikat. Sebuah ikatan PVC ke PV merupakan pemetaan satu ke satu.
Klaim akan berada dalam kondisi tidak terikat tanpa kepastian jika tidak ada volume yang cocok. Klaim akan terikat dengan volume yang cocok ketika ada volume yang cocok. Sebagai contoh, sebuah klaster yang sudah menyediakan banyak PV berukuran 50Gi tidak akan cocok dengan PVC yang meminta 100Gi. PVC hanya akan terikat ketika ada PV 100Gi yang ditambahkan ke klaster.
Pod menggunakan klaim sebagai volume. Klaster menginspeksi klaim untuk menemukan volume yang terikat dengan klaim tersebut dan memasangkan volume tersebut ke pada pod. Untuk volume yang mendukung banyak mode akses, pengguna yang menentukan mode yang diinginkan ketika menggunakan klaim sebagai volume dalam sebuah pod.
Ketika pengguna memiliki klaim dan klaim tersebut telah terikat, PV yang terikat menjadi hak penggunanya selama yang dibutuhkan. Pengguna menjadwalkan pod dan mengakses PV yang sudah diklaim dengan menambahkan persistentVolumeClaim pada blok volume pada Pod miliknya. Lihat pranala di bawah untuk detail-detail mengenai sintaks.
Tujuan dari Objek Penyimpanan dalam Perlindungan Penggunan adalah untuk memastikan Persistent Volume Claim (PVC) yang sedang aktif digunakan oleh sebuah pod dan Persistent Volume (PV) yang terikat pada PVC tersebut tidak dihapus dari sistem karena hal ini dapat menyebabkan kehilangan data.