Penyediaan Volume Dinamis
Penyediaan volume dinamis memungkinkan volume penyimpanan untuk dibuat sesuai permintaan (on-demand). Tanpa adanya penyediaan dinamis (dynamic provisioning), untuk membuat volume penyimpanan baru, admin klaster secara manual harus memanggil penyedia layanan cloud atau layanan penyimpanan, dan kemudian membuat objek PersistentVolume sebagai representasi di Kubernetes. Fitur penyediaan dinamis menghilangkan kebutuhan admin klaster untuk menyediakan penyimpanan sebelumnya (pre-provision). Dengan demikian, penyimpanan akan tersedia secara otomatis ketika diminta oleh pengguna.
- Latar Belakang
- Mengaktifkan Penyediaan Dinamis (Dynamic Provisioning)
- Menggunakan Penyediaan Dinamis
- Perilaku Default
- Kesadaran (Awareness) Topologi
Latar Belakang
Penyediaan volume dinamis diimplementasi berdasarkan objek API StorageClass dari
grup API storage.k8s.io
. Seorang admin klaster dapat mendefinisikan berbagai macam
objek StorageClass sesuai kebutuhan, masing-masing menentukan plugin volume (disebut
juga provisioner) yang menyediakan sebuah volume beserta kumpulan parameter untuk
diteruskan oleh provisioner ketika proses penyediaan.
Seorang klaster admin dapat mendefinisikan dan mengekspos berbagai templat penyimpanan (dari sistem penyimpanan yang sama maupun berbeda) di dalam klaster, masing-masing dengan kumpulan parameter tertentu. Desain ini memastikan bahwa pengguna tidak perlu khawatir betapa rumitnya mekanisme penyediaan penyimpanan, tapi tetap memiliki kemampuan untuk memilih berbagai macam pilihan penyimpanan.
Info lebih lanjut mengenai storage class dapat dilihat di sini.
Mengaktifkan Penyediaan Dinamis (Dynamic Provisioning)
Untuk mengaktifkan penyediaan dinamis, seorang admin klaster perlu untuk terlebih dahulu membuat (pre-create) satu atau beberapa objek StorageClass untuk pengguna. Objek StorageClass mendefinisikan provisioner mana yang seharusnya digunakan dan parameter apa yang seharusnya diberikan pada provisioner tersebut saat penyediaan dinamis dipanggil. Manifestasi berikut ini membuat sebuah StorageClass “slow” yang menyediakan persistent disk standar.
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: slow
provisioner: kubernetes.io/gce-pd
parameters:
type: pd-standard
Manifestasi berikut ini membuat sebuah StorageClass “fast” yang menyediakan SSD persistent disk.
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: fast
provisioner: kubernetes.io/gce-pd
parameters:
type: pd-ssd
Menggunakan Penyediaan Dinamis
Pengguna dapat melakukan permintaan untuk penyediaan penyimpanan dinamis dengan
memasukkan StorageClass di dalam PersistentVolumeClaim. Sebelum Kubernetes v1.6,
ini dapat dilakukan melalui anotasi volume.beta.kubernetes.io/storage-class
.
Hanya saja, anotasi ini sudah usang sejak v1.6. Pengguna sekarang dapat dan seharusnya
menggunakan field storageClassName
dari objek PersistentVolumeClaim. Nilai
dari field ini haruslah sesuai dengan nama StorageClass yang dikonfigurasi oleh
admin (lihat bagian di bawah).
Untuk memilih StorageClass “fast”, sebagai contoh, pengguna dapat membuat PersistentVolumeClaim seperti ini:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: claim1
spec:
accessModes:
- ReadWriteOnce
storageClassName: fast
resources:
requests:
storage: 30Gi
Klaim ini menghasilkan persistent disk SSD yang disediakan secara otomatis. Ketika klaim dihilangkan, volume akan musnah.
Perilaku Default
Penyediaan dinamis dapat diaktifkan pada setiap klaster supaya semua klaim dapat disediakan secara dinamis jika tidak ada StorageClass yang dispesifikasikan. Seorang klaster admin dapat mengaktifkan perilaku ini dengan cara:
- Menandai satu objek StorageClass sebagai default;
- Memastikan bahwa admission controller
DefaultStorageClass
telah aktif pada API server.
Seorang admin dapat menandai StorageClass yang spesifik sebagai default dengan menambahkan
anotasi storageclass.kubernetes.io/is-default-class
.
Ketika StorageClass default tersebut ada pada klaster dan pengguna membuat PersistentVolumeClaim
tanpa menspesifikasikan storageClassName
, admission controller DefaultStorageClass
secara
otomatis menambahkan field storageClassName
dengan StorageClass default.
Perhatikan bahwa hanya bisa ada satu default StorageClass pada sebuah klaster,
atau PersistentVolumeClaim tanpa menspesifikasikan storageClassName
secara eksplisit
tidak bisa terbuat.
Kesadaran (Awareness) Topologi
Pada klaster Multi-Zona, Pod dapat tersebar di banyak Zona pada sebuah Region. Penyimpanan dengan backend Zona-Tunggal seharusnya disediakan pada Zona-Zona dimana Pod dijalankan. Hal ini dapat dicapai dengan mengatur Mode Volume Binding.
Masukan
Apakah halaman ini berguna?
Thanks for the feedback. If you have a specific, answerable question about how to use Kubernetes, ask it on Stack Overflow. Open an issue in the GitHub repo if you want to report a problem or suggest an improvement.